Technical SEO Is a Build Decision, Not a Marketing Task

Technical SEO is usually handed to marketing after launch, as a checklist of fixes. By then the expensive decisions have been made, and most of them were made by engineers who were not thinking about search at all.

This is a short account of the parts that actually belong in the build, based on migrating sites and on running this one.

Can the page be read without running your app

The first question is whether your content exists in the HTML the server sends, or only after JavaScript has run in the browser.

Search engines can execute JavaScript, but it costs them, it is queued, and it is less reliable than reading markup directly. More importantly, it is not only search engines reading your pages any more: assistants and link previews fetch HTML and frequently do not run scripts at all. A page whose content appears only after a client-side fetch is invisible to a growing share of what reads the web.

This is an architecture decision, not a setting. Content that matters for discovery should be rendered on the server. Retrofitting that later usually means restructuring how data is fetched throughout the application, which is why it is worth deciding at the start.

Metadata that is generated, not maintained

Every page needs a title, a description and a canonical URL. The failure is rarely that teams do not know this; it is that these are added by hand, so new pages ship without them and old ones drift into duplicates.

The fix is structural: generate metadata from the same content that renders the page, so a page cannot exist without it. On this site every route builds its metadata through one shared helper and the sitemap is generated from the content files, which means a new page is listed and described correctly because there is no other way for it to be published.

Canonical URLs deserve particular care. Pick one form of your address, apex or www, with or without a trailing slash, and make everything else redirect to it in a single hop. Chains of redirects dilute what they pass along and slow every visitor who hits them.

What to do when URLs change

A rebuild usually changes URLs, and this is where sites quietly lose whatever standing they had accumulated.

The rule is to distinguish three cases honestly. A page that moved gets a permanent redirect to its real equivalent. A page that was deleted and has no equivalent should say so, and the right answer is Gone rather than Not Found, because Gone tells a crawler to stop coming back rather than to keep retrying. A page that never existed can simply be Not Found.

The tempting mistake is to redirect everything to the homepage. It feels tidy and it is treated as a soft error, because the destination plainly is not what was requested. When we moved this site we redirected what had a genuine equivalent and marked the retired demo content as Gone, which is the honest description of what happened to it.

Sitemaps and honest dates

A sitemap is a hint, not an instruction. Its value comes from being accurate, and the common failure is a last-modified date that updates to today on every build.

Once every page claims to have changed today, the dates carry no information and are discounted. A sitemap where dates reflect when content genuinely changed gives a crawler a reason to prioritise what is actually new. That is worth more than the fields people argue about, several of which are ignored entirely.

Structured data, where it fits

Structured data describes what a page is in a form machines can use: an article, an organisation, a job posting, a product. It does not improve ranking by itself, and claims that it does should be treated with suspicion.

What it does is make a page eligible for richer treatment and easier for assistants to summarise correctly. The important discipline is that it must describe what is actually on the page. Marking up a job posting that is not listed, or a rating nobody gave, is the kind of thing that attracts manual action rather than traffic.

Speed, honestly

Performance matters, but less dramatically than the industry around it suggests. Being fast enough that people do not leave is the real goal, and most of the gap between a slow site and an adequate one comes from a few familiar causes: oversized images, blocking third-party scripts, and layouts that move while loading.

Analytics and tag managers are worth auditing specifically, because they are added casually and are frequently the largest thing a visitor downloads. A single marketing script can cost more than every image on the page.

A short list for a team mid-build

1. Confirm your important content is in the server-rendered HTML.
2. Generate titles, descriptions and canonicals from content, so no page can ship without them.
3. Decide one canonical address form and redirect everything else in one hop.
4. Plan redirects and deletions before a migration, not after launch.
5. Generate the sitemap, with dates that mean something.
6. Add structured data only for what the page genuinely contains.
7. Audit third-party scripts before optimising your own code.

None of this guarantees anything about where you appear, and anyone promising otherwise is selling something. What it does is remove the technical reasons a page cannot be found or understood, which is the part engineering actually controls.

If you are mid-build and want these decisions checked while they are still cheap to change, send us the site and we will tell you what we would do differently. Our technical SEO page explains how we work on this.