SEO Foundations for a New Website

Most of the decisions that determine whether a new website performs in search are made before a single word is optimised. They are made when someone decides what pages will exist, how they connect, what each one is for, and how the site will be built. By the time an SEO specialist is handed a finished site and asked to improve it, the expensive choices are already set in concrete.

This is a practical list of the foundations worth getting right on a new build. None of it is exotic. All of it is easier to do now than to retrofit in eight months.

Decide what each page is for

Before structure, before design, write one sentence per page: who arrives here, what they need to know, and what they do next. If you cannot write that sentence, the page probably should not exist, or two pages should be one.

This sounds like a content exercise rather than an SEO exercise. It is the most important SEO exercise you will do. Search engines are trying to work out which page best answers a specific query. If you have not decided that yourself, you are asking a crawler to guess on your behalf, and it will guess badly and inconsistently.

Make sure the site can be crawled and rendered

Everything else is theoretical if a search engine cannot reach and read your pages. The checks worth making before launch:

• Indexation controls. Staging sites are usually blocked. Make sure that block does not ship to production. A noindex tag left in place is the single most common launch disaster, and it is silent.
• robots.txt. It should permit crawling of the pages you want found, and point to your sitemap. It is not a security control and it is not a way to remove pages from an index.
• Rendering. If your content only exists after JavaScript executes, you are relying on a rendering step that is slower, less reliable and harder to debug. Server -rendered or static HTML removes an entire category of problems.
• Internal links. A page that is not linked from anywhere is a page you are hoping gets discovered. Every important page should be reachable from a real link in a reasonable number of steps.
• Canonicals. One canonical URL per page, self-referencing, absolute, and consistent with the version you actually serve — including the trailing slash and whether you use www.

Give every topic one owner page

If three pages address the same subject, you have not tripled your chances. You have split the signal, confused your internal linking and created a maintenance problem. Decide which page owns a topic, make it the best answer available, and point the others at it.

The corollary matters just as much: important topics need a page. If a question is worth asking, and the answer is worth money to you, it needs somewhere to live that is not paragraph four of a general services page.

Write titles and headings that answer the query

A title tag is a promise made on a results page. It has to be accurate, specific and written for a person deciding where to click. Padding it with keyword variants makes it worse at both jobs.

Inside the page, use one h1 that states what the page is about, and a heading structure that would still make sense if you read only the headings. That is not a stylistic preference — a logical heading order is how assistive technology navigates a page, and it happens to be how a crawler infers structure. The accessible version and the findable version are the same version.

If you are replacing a site, map the redirects first

Traffic losses after a redesign are rarely mysterious. Usually URLs changed, redirects were partial, and pages that used to answer a query stopped existing.

Before launch, export every existing URL. For each one, decide: does it survive with the same address, does it move to a new address, or does it go? Every move needs a permanent redirect to the closest equivalent — not a blanket redirect to the homepage, which tells a search engine the page is gone and the homepage is unrelated. Keep the map, check it after launch, and check it again a fortnight later.

Treat performance as a foundation, not a score

Fast sites are easier to crawl, easier to use and better at converting. Slow sites lose on all three. The point is not the score in a testing tool; it is that a real person on a real connection gets the content quickly and the layout does not jump around while they read.

The decisions that matter are architectural: how much JavaScript ships, how images are sized and served, whether fonts block rendering, and whether elements have dimensions before they load. Made during the build, these cost nothing. Retrofitted, they turn into a project. This is part of why we build websites and search foundations in the same engagement rather than in sequence.

Set up measurement before you launch

On launch day you want to know what happened, not start working out how to find out. Before the site goes live:

• Verify the property in Google Search Console and submit the sitemap.
• Confirm analytics is recording, on the production domain, without duplicating.
• Define the conversions that matter and check each one fires exactly once.
• Record a baseline — current rankings, traffic and conversions — so you can tell later whether the new site helped or merely coincided with a good quarter.

Measurement configured after the fact is measurement you cannot compare to anything.

The first month after launch

Launch is the start of the diagnostic period. In the first four weeks, watch indexation (are your pages actually in the index?), crawl errors, redirect behaviour and Core Web Vitals from real users rather than lab tests. Expect some volatility; do not respond to every daily movement, and do not make five changes at once, because then you will not know which one worked.

Nobody can promise a ranking, and you should be wary of anyone who does. What you can control is whether your pages are reachable, readable, well structured, genuinely useful and quick. That is what these foundations buy you: not a guarantee, but the removal of every avoidable reason to be overlooked.

If you are planning a build or a migration and want a second opinion on the structure before it is locked, our SEO and content team is usually in the room from the first workshop.