Technical SEO QA before launch

A clean launch should verify the technical signals that can accidentally block or confuse search engines.

Indexing controls

Check that production pages are indexable and preview or staging environments are not.

Canonicals

Confirm that public pages canonicalize to the correct production URLs.

Redirects

Old URLs that changed should resolve to the most relevant replacement without chains or loops.

Metadata

Titles and descriptions should be present, unique where appropriate, and consistent with the page content.

Sitemap

The sitemap should include the routes intended for indexing and exclude private or temporary routes.

Robots

Robots rules should allow the production site to be crawled and should reference the production sitemap.

Structured data

JSON-LD should parse correctly and match the visible content.

Rendering

Critical text and links should be present in rendered HTML. The page should not depend on a broken client-side request to expose its main content.

Mobile behavior

Navigation, forms, tap targets, layout, and text should work at narrow viewport sizes. The purpose of QA is not to guarantee rankings. It is to remove technical reasons the site would fail to compete.

We test the source and the generated artifact

One of our production sites uses a source-level SEO script before deployment. It verifies required article fields, duplicate slugs, dates, image-path conventions, metadata exports, canonical helper usage, preview noindex behavior, and the presence of required SEO infrastructure files. The connectrader site adds a second layer after next build. It reads the prerender manifest and opens the generated HTML for every public page.

Those two tests answer different questions. The source audit checks whether the architecture is wired correctly. The output audit checks whether the architecture produced the right document.

The generated-page audit is intentionally broad

For every public route, the current audit checks the document language, viewport metadata, H1 count, heading order, main landmark, unique title, unique description, canonical URL, robots state, Open Graph fields, Twitter fields, image alt attributes, JSON-LD parsing, expected schema types, and internal links. It also scans source files for referenced images that do not exist, checks CSS-served image budgets, validates robots.txt, and confirms sitemap date inputs.

That is not because every item is equally important to ranking. It is because they are all deterministic technical properties we do not want quietly regressing.

Internal links are checked against real rendered routes

A typo in an internal href can survive code review easily. The post-build audit normalizes internal paths and compares them with the routes in the prerender manifest. If a link points to a route the application did not render, the build can report it.

This is more reliable than waiting for a crawler or customer to discover the broken path later.

QA rules need to remain outcome-focused

Automated validation can become brittle if it checks incidental implementation details. We prefer rules that describe the result we care about. "Every public page has one canonical matching its public route" is a strong rule. "This route file contains an exact string at a particular line" is weaker unless that exact implementation is itself a required safeguard.

We maintain the audit like any other code.

The checklist still has a role

Human review remains necessary for search intent, copy quality, page usefulness, image relevance, local substance, and conversion behavior. A script cannot tell us whether a page deserves to rank. The automated layer removes technical uncertainty so the human layer can focus on judgment.

For the deeper reasoning, see Why we validate SEO in the build instead of relying on a checklist.