Technical SEO foundations every new website should have before launch

Technical SEO has a peculiar economics: almost everything on this list is cheap to do during a build and expensive to retrofit. Which is why so much of it gets skipped, and why so many sites launch with a ceiling already installed.

None of what follows will make a bad site rank. What it does is remove the reasons a good site cannot. Think of it as clearing obstacles rather than adding advantages.

Make sure the site can be crawled and indexed at all

The most expensive SEO mistake in the world is a noindex tag left on from staging. It costs nothing to check and it happens on real launches every week.

• Confirm production has no noindex meta tag or X-Robots-Tag header.
• Confirm robots.txt allows what you want crawled and blocks what you do not.
• Make sure the staging environment is blocked — ideally behind authentication, not just a robots directive.
• Check that important content is in the HTML response, not only rendered by client-side JavaScript.

That last point causes more quiet damage than the rest combined. If your content only exists after JavaScript executes, you are relying on a second rendering pass that may be slower, incomplete, or skipped.

Get the URL structure right before anything is published

URLs are the hardest thing to change later, because changing them means redirects, and redirects accumulate into chains.

• Lowercase, hyphenated, readable, and stable.
• Structure reflecting genuine hierarchy — but shallow rather than deep for its own sake.
• No session IDs, no tracking parameters in canonical URLs.
• One canonical form: pick www or not, pick trailing slash or not, and redirect the other.
• HTTPS everywhere, with HTTP redirecting to it.

Canonical tags on every indexable page

A self-referencing canonical on every page is the default you want. It costs nothing and it resolves a large class of duplicate-content ambiguity before it starts.

Where you have genuine duplicates — filtered listings, print views, parameter variants — point them at the canonical version deliberately rather than leaving search engines to guess.

Real title tags and descriptions, written not generated

Every page needs a unique title and description. Templating them from a database field produces technically unique, practically useless results.

Write them for the significant pages by hand. For large catalogues, template them with enough variables that the output is still distinguishable and still reads like a sentence.

Structured data, where it genuinely applies

Schema is useful when it describes something real about the page: an organisation, a product, a breadcrumb trail, an article, an FAQ that is actually visible on the page.

It is not useful as decoration, and inventing ratings or reviews in structured data is both against guidelines and the kind of shortcut that is hard to walk back. Mark up what is true.

Treat Core Web Vitals as a build requirement

Performance is much cheaper to design in than to optimise afterwards, because most of the cost is architectural rather than a matter of compression settings.

• LCP: identify the largest element on each template and make it load first. Usually a hero image — so serve it in a modern format, at the right size, and do not lazy-load it.
• CLS: reserve space for every image, embed and ad. Set width and height or aspect-ratio. Layout that jumps while someone is reading is a design failure, not a metric.
• INP: keep the main thread free. Most interaction delay is third-party scripts doing work nobody asked for.
• Budget your third-party scripts explicitly. Each one is a permanent tax.

Images

Images are usually the largest thing on the page and the easiest win.

• Serve modern formats — AVIF and WebP with a fallback.
• Multiple sizes with srcset and a sensible sizes attribute. Do not send a 2000px image to a 400px card.
• Lazy-load below the fold, never the hero.
• Explicit dimensions on everything.
• Descriptive alt text on meaningful images, empty alt on decorative ones. Both matter; keyword-stuffing alt text helps neither.

Sitemaps and internal linking

An XML sitemap should contain exactly the URLs you want indexed — canonical, 200-status, indexable. A sitemap full of redirects and 404s is a signal about your site's quality, not just an inconvenience.

Internal linking matters more than most people assume. It is how importance is communicated, and a page with no internal links pointing at it is telling search engines something you probably did not intend.

Set up measurement before you need it

Analytics and Search Console should be verified and collecting before launch, not after you notice something is wrong.

Establish the baseline on day one. Without it, every future question about whether something changed is unanswerable.

If anything is replacing an existing site

Then this is not a launch, it is a migration, and the rules are different and stricter. Every old URL needs a decision and a redirect. We wrote that up separately in the migration checklist, and it is the single highest-risk part of any relaunch.

The pre-launch list

Our SEO service page covers the ongoing work that follows, and website development covers how these foundations get built in rather than bolted on.