Your maintenance plan says “content updates included”. You send a request to add a new service page with a short form on it, and the reply is a quote. You thought that was a content update. The provider thinks it is a small build. Neither of you is being unreasonable, and yet both of you are now slightly annoyed.
What counts as a website content update is a frequent point of friction in maintenance arrangements, because the phrase sounds obvious and is not. This post sorts typical requests into what usually counts, what usually does not, and the grey zone in between. It also explains why providers draw the line where they do, and how to write requests so they are done right the first time.
What counts as a website content update, in practice
The working rule most providers use is this: a content update changes what an existing part of the site says or shows, without changing how that part is built. Swap words, swap pictures, swap numbers. The structure stays the same.
Usually counts
- Changing text on an existing page: a new paragraph, corrected spelling, an updated phone number.
- Replacing a photo or a logo with one you supply.
- Updating prices, opening hours, or a list of services in an existing section.
- Publishing a blog post or news item you have written, using the existing post layout.
- Adding or removing a team member from an existing team section.
- Uploading a new PDF, such as a brochure or menu, and linking it where the old one was.
- Adding a product to a store using an existing product type, with the details you provide.
- Changing a link in the menu or footer to point somewhere else.
Usually does not count
- A new page with a layout that does not exist elsewhere on the site.
- A new form, or new fields on an existing form that need to go somewhere new.
- A new type of section, such as a testimonials slider or a pricing table where there was none before.
- Writing or rewriting the text itself. That is copywriting.
- Editing, retouching or designing images.
- Translating the site, or adding a second language.
- Importing a large batch of products or posts from a spreadsheet.
- Restructuring the menu and page hierarchy across the site.
The grey zone
Some requests could reasonably go either way. These are worth asking about before you assume.
A new page that copies an existing one
If you already have five service pages built the same way and want a sixth with your own text and photo, many providers treat that as content, because they duplicate the page and swap the words. If the sixth needs something the others do not have, it becomes a build.
Small layout changes
Moving a section higher up the page, changing a button colour, swapping two columns. Quick in some page builders, fiddly in others, and occasionally risky on mobile layouts. Providers vary on these.
Seasonal banners and announcements
A holiday closure notice or a festival offer bar. If the site already has a place for announcements, it is content. If one has to be added, it is a small build that later becomes content.
Changes to legal pages
Publishing an updated privacy policy you supply is content. Deciding what it should say is not something a maintenance provider should do for you.
Content updates on an online store
Stores blur the line further, because so much of a store is content that behaves like data. A few common cases:
- Changing a price or a stock level on a few products is content. On many stores the owner does this daily without help.
- Adding a handful of products with photos and descriptions you supply is usually content, provided the products use options the store already has, such as existing sizes and colours.
- A new kind of product option, such as engraving text or a gift message, usually needs a plugin or configuration and is a build.
- Running a sale may be content if it is a coupon or a sale price in an existing setup, and a build if it needs a new banner system, a countdown or rules the store cannot already express.
- Changing shipping zones or tax settings is configuration rather than content, and mistakes cost real money at checkout, so expect a provider to treat it carefully.
Why providers draw the line where they do
From the outside, the line can look arbitrary. Adding a paragraph is included but adding a form is not, even though both take a few minutes? The real reason is risk, not time.
Changing words on a page cannot break anything else. Adding a form can: it needs to send to the right address, it needs spam protection, it may need to store entries, and it adds a thing that can stop working later and must then be maintained. A new section type has to work on every screen size. A bulk import can create hundreds of pages with mistakes in them. The cost of a request is less about how long it takes to do and more about what it adds to the list of things that can fail.
A provider who explains it this way, and quotes the risky requests openly, is doing you a favour. The alternative is a provider who says yes to everything inside the plan and quietly does it in a hurry.
How content changes in a maintenance plan are usually counted
There is no standard method, and it is worth asking which one your provider uses. The common approaches are:
- By request. Each email or ticket is one update, however many small edits it contains. Simple to understand, and it rewards batching changes together.
- By time. The plan includes a certain amount of time for content work each month. Fair for mixed requests, harder to predict.
- By page. Edits to one page count as one update. Works well for sites with many pages and occasional changes.
- Reasonable use. No stated limit, with an understanding that heavy use leads to a conversation. Flexible but vague.
Also ask whether unused allowance carries over to the next month. Often it does not, which matters if your changes come in bursts.
When you are comparing website update services from different providers, this can be the biggest real difference between two plans at a similar price, so get each answer in writing.
How to send a request that gets done right first time
Most back-and-forth on content changes comes from unclear requests. A good request has five parts:
- The exact page address. Copy it from the browser. “The services page” can mean three different pages.
- What is there now. Quote the current text, or attach a screenshot with the area circled.
- What it should become. Paste the final wording, already proofread. Do not send a draft with “something like this”.
- Any files, ready to use. Images at a sensible size and named clearly. The guide to preparing images for a website covers size and format.
- When it needs to be live. And whether it is tied to anything else, such as an ad campaign or an email going out.
Put several changes in one document, numbered, rather than sending them one message at a time. It is quicker for the provider, it is easier to check off, and under a by-request plan it costs you less.
A short example
“Page: the full address of your Pricing page. Section: the second price box, headed Standard. Change the price line from the old figure to the new one, and replace the third bullet with ‘Includes one revision round’. Live by Friday, as the new prices go out in our newsletter on Saturday.”
That request can be done in one pass and checked in seconds.
Content you might prefer to do yourself
For text changes, blog posts and photo swaps, many owners find it quicker to do it themselves, with a provider on hand for anything structural. That only works if the person doing it has their own login and some basic training, which is covered in the post on upkeep owners can safely take on.
If the bottleneck is not making the change but knowing what to write, that is a different problem. The guide to writing content for a website is a good place to start, and if you would rather have someone write it, that is a copywriting job rather than maintenance.
Agree the rules before the first request
The simplest way to avoid friction is to ask at the start: “Here are three changes I expect to make in the next few months. Which would be included, and which would you quote?” The answer tells you how the provider thinks, and gives you a reference point for every request that follows.
Our own plans include minor content changes, with a larger allowance on the higher tiers. The plan details show what each tier allows, so you can check your own typical requests against them, and you can ask how anything larger would be handled before you send it.
Next in this series: Static Website Maintenance: What an HTML Site Still Needs
