SEO is a build decision, not a launch task.

Content architecture is decided before anything is designed

The single largest SEO decision on most small business sites is how many pages there are and what each one is about.

A business offering six services will often put all six on one page, as sections. It reads perfectly well. It also means there is exactly one page competing for six different searches, and it is specifically about none of them. Someone searching for one of those services lands on a general page and has to go looking.

Six pages, each genuinely about one service, each able to earn its own ranking and answer one intent completely, is a different site. Not a different stylesheet — a different site, with different navigation, different internal links and different content to write.

Changing this after launch is not an optimisation. It is a restructure, plus redirects, plus the content that was never written because the page did not exist.

URLs are permanent in a way people underestimate

A URL is a promise. Every link anyone ever makes to your page, every bookmark, every citation, and all the ranking history accumulated over years attaches to that exact string.

Which is why the throwaway decisions matter. Whether services live at /services/roof-repair or /page-id-47. Whether the blog sits at /resources or /blog. Whether categories are in the path at all.

Changing a URL later is survivable — you redirect the old one to the new one and most of the value carries across. But it is friction you inflict on yourself for no gain, and it accumulates. A site that has been restructured three times carries three generations of redirects, and every one of them is a small tax on every visit.

Internal linking is a structure, not a task

Search engines work out what a site is about partly from how its pages link to each other. Which pages are reachable, from where, and with what wording.

A site where every page is reachable only from the main navigation tells a flat story: here are nine equally important things. A site where the service pages link to relevant case studies, and the case studies link back to the services they demonstrate, and articles link to both, describes a set of relationships and priorities.

This cannot be sprinkled on at the end because the links have to be written into the copy to make sense. Retrofitted internal links read exactly like what they are — a paragraph with a phrase awkwardly turned into a link because somebody needed one there.

Semantic markup is a build-time property

How a page is marked up determines how much of it a machine can understand. This is decided by whoever builds the templates, once, for every page that will ever use them.

• One h1 per page describing that page, with h2 and h3 forming a real outline rather than being chosen for their font size.
• Navigation, main content and footers in the elements that mean those things, so the primary content is distinguishable from the furniture.
• Structured data describing what the business or page actually is — a LocalBusiness with opening hours, an Article with a publication date, an FAQ that can appear expanded in results.
• Images with alt text written for someone who cannot see them, which is also the only description a search engine gets.
• Canonical URLs, so the same content at two addresses does not compete with itself.

Performance is a consequence of architecture

Core Web Vitals are a ranking signal, and more importantly they are the difference between a visitor waiting and a visitor leaving. On a mid-range phone on a weak connection — which is where a great many local searches happen — this is the whole experience.

Speed is not a setting. It follows from what the site is built on, how images are handled, how much JavaScript ships, and whether pages are rendered ahead of time or assembled in the browser on arrival.

You can improve a slow site at the margins afterwards: compress the images, defer some scripts, add caching. What you cannot do afterwards is change what it was built on. That decision was made in week one, usually without anyone framing it as an SEO decision at all.

What retrofitting actually costs

When an existing site needs all of this, the work is not a pass over the settings. It is new page structure, new URLs with redirects from the old ones, template changes for the markup, content written for pages that did not previously exist, and usually a platform change to fix performance properly.

That is most of a rebuild, arrived at sideways and paid for twice. The same decisions cost nothing extra when made at the start, because somebody was going to decide the page structure and the URLs regardless. The only question is whether they were decided deliberately.

What to ask before the build starts

None of this requires being technical. It requires the questions being asked while the answers are still cheap:

• Which searches should bring people here, and does each one have a page that is genuinely about it?
• What are the URLs going to be, and are we happy to keep them for ten years?
• How does someone get from a service page to proof that we do it well, and back?
• Is the markup describing what things are, or only what they look like?
• What does this weigh on a phone, and will it still be fast when the content is real?

The part that comes at launch

Titles, meta descriptions, a sitemap, verifying the site with search tools — this is real work and it does belong at the end. It is simply the last five per cent, and it performs in proportion to the ninety-five per cent underneath it.

A well-structured, fast, properly marked-up site with mediocre meta descriptions will do fine. A slow, flat, one-page-for-everything site with perfect meta descriptions will not. The launch task cannot rescue the build decision, which is the entire reason to treat it as one.