A page listing the towns you cover is written once, at a moment when the business only travels so far. A job in a town that isn't listed changes that. The page hasn't caught up, and nothing on the site tells it to.

Why it happens without anyone noticing

Nobody sits down to update an areas-covered page after a single job further out. There's no prompt for it: the page doesn't check itself against the addresses on recent invoices, and there's no reason it would occur to you mid-job. The page just stays as it was written, quietly describing a smaller radius than the one you actually work in.

The practical effect is that a customer searching from a town you now cover, but that isn't listed, has no way of knowing you'd take the job. They read the list as a boundary, because that's what a list of towns is for. If their town isn't on it, the reasonable conclusion is that you don't go there.

What makes the page wrong isn't age, it's distance

A list written two years ago and still accurate is not a problem. The problem is a list that was accurate on the day it was written and has since fallen behind the actual work. That gap can open in months if the business takes on jobs outside its original patch, or it can stay closed for years if the working area hasn't changed at all. Age on its own tells you nothing; distance from the current pattern of work does.

A coverage area on a trade website usually starts as a rough guess: the towns nearest the base, or the places most jobs have come from so far. That guess gets typed in once, at the start, and rarely gets looked at again. The problem is that the area a business actually covers changes as the work changes, and the wording on the site does not change with it.

Describe what defines the area.

A radius from a postcode, a named region, or a type of job that determines how far you will travel all stay accurate as the business grows. A list of specific towns describes a snapshot: it is correct for exactly as long as the business does not take a job outside it, and wrong from the first day it does.

This matters because a customer searching for a tradesperson nearby is often looking at the area wording specifically, to check whether their own address is covered before they get in touch. If the wording describes a rule they can apply to their own postcode, it still answers the question months or years later. If it describes a list, they are checking their address against a list that was accurate once.

Keep the wording separate from the work of updating it

Whichever form the area wording takes, it needs someone to check it against how the business actually operates now, and change it when that has moved on. That is not a one-off task tied to when the site was built. It is a small, recurring one, and it sits alongside other pages that carry a date, such as scheme registrations, which is worth bearing in mind when deciding how the site as a whole gets kept current.

Some jobs sit just outside the usual run. A customer three towns over gets a recommendation, or a regular client moves house and asks you to follow. The honest answer to "do you cover this area" is often that it depends on the job, the day, and what else is booked in, and a website that only lists fixed towns has no way to say that.

Write the shape of the area

A radius from a base point, or a short list of the towns worked most often with a line that further jobs are considered on request, describes the same territory a strict list does without becoming wrong the first time a job falls outside it. This is a difference in how the coverage is described.

Say what decides it

Where the real answer depends on distance, the type of job, or timing, stating that directly gives the reader something to act on. A sentence like "jobs further out are taken depending on the work and the date" answers the question a rigid list cannot, because it tells the reader what to do next: ask.

None of this needs revisiting every time a job comes in from a new direction. It only needs revisiting when the pattern of where the work actually happens changes for good.