Should a small website change take weeks?
No. A copy edit, an image swap, or a new team member on the about page is same-week work, often same-day. Structural changes, new page types, and design work legitimately take longer, and mixing the two categories up is how slow vendors defend themselves. When a two-line text change takes three weeks, the delay is your position in the vendor's queue, a change process with too many hops, or a site only a developer can touch. All three are diagnosable from your own email history, and all three are fixable.
What it usually means
Slow small changes usually mean one of three things, and they have different fixes. First, the vendor is over-subscribed and you're not a priority account: your requests are real work to them, just work that waits. Second, the process is the problem: every request routes through an account manager, a ticket system, and a developer, so a five-minute edit carries three days of handoffs and each handoff adds a queue. Third, and most structural, the site is built so only a developer can change it, which converts every request into billable work and makes the queue the business model.
The innocent explanation is real and common: plenty of good vendors simply run hot, and a slow month isn't a pattern. The diagnosis below separates a bad quarter from a bad arrangement, which is why it works from your own records rather than from impressions.
The third case deserves the most attention because it doesn't improve when the vendor hires. If your marketing team can't change a headline without a ticket, the constraint is the build, not the workload, and every future vendor inherits it until the build changes.
What it costs while it stays this way
The direct cost is the one on the invoices: agency rates for typing. The larger cost is the changes that stop being requested. When every edit costs a ticket and a wait, teams unconsciously raise their threshold for what is worth asking, and the site starts drifting behind the business: the certification you earned in March is missing in August, the discontinued service is still listed, the person who left is still on the team page. Staleness isn't one big failure; it's a hundred small requests that never felt worth the friction.
In our study of 55,000+ US B2B websites, 49% of established companies' sites were visibly dated, with the median last redesign more than seven years back. That number is what request-friction compounds into: not a broken site, a fossilized one, maintained just enough to stay up and never enough to stay current.
There's also a sales-cycle cost with a clock on it. When a prospect asks about a capability and the page still contradicts what your team told them, the site is actively working against the deal, and a three-week turnaround means three weeks of every active deal seeing the old answer.
How to confirm it yourself
- Time your last three requests from your own email. Search your sent mail for the last three change requests. For each, record what you asked for, the date you asked, and the date it shipped. Separate genuinely structural work from edits. Three small edits averaging two weeks or more is a pattern; one slow request in a busy month is not.
- Ask the vendor to walk you through the path of a request. Literally ask: after I hit send, what happens? Count the handoffs between the person who receives the request and the person who makes the change. In practice each hop costs about a day; three or more hops for a text edit is a process problem regardless of anyone's workload.
- Test the self-serve path with one trivial edit. Ask what your own team could change today without the vendor, then try it: fix a typo, swap a photo. If the honest answer is nothing, or the CMS login you're given can't actually do it, the site was built to keep changes billable, whether or not anyone intended that.
- Read the contract for response versus completion. Many agreements promise a response time, not a completion time. Responding to a ticket within one business day and shipping the change in three weeks can both be true, and the agreement is only promising the first. Find which one your turnaround language actually commits to.
- Check what a change costs, not just how long it takes. Pull the last invoice that included content edits and compute the effective hourly rate for the work delivered. Typing billed at strategy rates is its own answer to whether the arrangement fits.
What the vendor's answers actually mean
Raise turnaround with a vendor and the same few replies come back. Each has a legitimate version and a tell.
“We batch changes for efficiency.”
Batching is efficient for the vendor. For you it means your edit waits behind every other client's edits. Reasonable for structural work; as a policy for two-line copy changes it means your urgency is priced at zero.
“That's scheduled for our next sprint.”
Sprint language means you're inside their production calendar. Fine for features. A text edit that needs a sprint is a process built for projects being applied to maintenance, and it will never get faster on its own.
“Small changes can destabilize the site.”
On a well-built site, a copy change can't take the site down. If this is true of your site, it's an argument about the build, and it's an expensive thing to be told with a straight face.
“You have full access to make changes yourselves.”
Test it, today, with the trivial edit above. Access that exists but can't be used by a non-developer is a defense, not a capability.
What actually fixes it
A working arrangement has two lanes. Routine content belongs to your team, in a CMS your marketing people can actually operate, with the vendor nowhere in the loop; this is what a CMS is for, and vendors who set clients up this way aren't rare. Structural and design work goes to the vendor with turnaround classes agreed in writing: small, medium, large, each with a shipping expectation rather than a response expectation.
If the diagnosis pointed at the queue or the process, the fix is the conversation and the two-lane agreement, and a capable vendor will take it well; it costs them the typing revenue and saves them the resentment. If the diagnosis pointed at the build, no process fixes it: a site only a developer can edit stays slow under every vendor, and that's a rebuild conversation. The honest framing for that decision is redesign vs. rebuild, and the age of the constraint is usually technical debt doing what it does.
Whichever lane a change belongs to, insist the classification happens when the request is made, not after it has waited. A request that sits for ten days and is then declared structural got the worst of both lanes.
The message to send
This resets the process without accusing anyone of anything. It also produces, in the reply, a written record of what the vendor believes the arrangement is.
Hi [name],
We want to tighten up how website changes flow. Two asks. First, can you confirm what our team can safely edit ourselves in the CMS, and set up a walkthrough if access needs to change? We would like routine copy and image updates to be self-serve on our side.
Second, for work that genuinely needs your team, can we agree turnaround expectations in writing: small edits within [3] business days, larger scoped work with a date attached when it's accepted?
Can we have both settled by [date two weeks out]?
Common questions
What is a reasonable turnaround for website changes?
For content edits through a vendor: one to three business days. Same day if your team has working CMS access, which is the better arrangement. A new page on existing designs: about a week. New functionality or design: scoped work with an agreed date. Anything routinely slower than this on plain edits is a queue problem or a build problem, not a complexity problem.
Why does my agency charge for every small change?
Either the site technically requires a developer for changes that should not need one, or per-change billing is the revenue model. The first is fixable with a better build, the second with a better arrangement. The test question is what your team could do themselves if the site allowed it; the reaction to that question is usually informative.
Isn't a maintenance retainer supposed to cover this?
Read what yours actually promises. Many maintenance retainers cover updates, backups, and uptime, and quietly exclude content work or cap it at an hour or two. If you're paying a retainer and also waiting weeks for edits, one of the two is mispriced, and the contract will tell you which.
Our site is custom-built. Is slow just the price of custom?
No. Custom code and an editable CMS aren't opposites; a well-built custom site gives your team more control over content, not less, because the build decides what is editable. Custom is only slow when it was built without the editing experience in mind, which is a choice, not a property of custom work.
How do we ask for faster turnaround without souring the relationship?
Frame it as process, not performance: two lanes, self-serve for routine edits, written turnaround classes for real work. Good vendors accept readily because the typing was never the work they wanted. A vendor who bristles at the framing is telling you the queue was the product.