Why we validate SEO in the build instead of relying on a checklist

A launch checklist can catch a lot of mistakes. It can remind somebody to check canonicals, page titles, robots rules, sitemaps, structured data, image alt text, and heading structure. The problem is that the site keeps changing after launch. A rule that matters on launch day usually still matters on release number forty-seven.

That is why we automate the repeatable parts.

Our SEO scripts are deliberately unglamorous

One production repo has a script that reads every article file and verifies required frontmatter fields. It checks for duplicate slugs. It validates dates. It confirms that article images use the expected local path format. It inspects route files to make sure metadata or generateMetadata exists. It verifies centralized canonical handling. It checks that preview noindex infrastructure exists.

Another site goes further after the production build. Its audit opens the generated prerender manifest, locates the actual HTML for every public route, and inspects what was produced. That second approach is powerful because it is testing the artifact, not merely the source code.

Source checks and output checks answer different questions

A source check can ask:

• Does this page export metadata?
• Is the SEO helper still present?
• Is the preview proxy still configured?
• Does the MDX file have a description?
• Is the slug duplicated?

An output check can ask:

• Did the page actually render one H1?
• Is the canonical the correct absolute URL?
• Did the Open Graph tags appear in the HTML?
• Is the public page accidentally marked noindex?
• Did the JSON-LD parse?
• Does an internal link point to a route that was not rendered?

Both layers are useful.

Why duplicate slugs deserve automation

Duplicate slugs are easy to create in a growing MDX library. Two filenames can normalize to the same URL. An editor can copy frontmatter and forget to change the explicit slug. The content may look fine in a code review because the files are different.

The router does not care that the files are different. It cares that both claim the same address. A ten-line map in a validation script can catch that every time.

Heading rules are another good example

A page should generally have one primary H1. That sounds like an editorial rule, but MDX can complicate it. The route template may already render the article title as an H1 while the imported content body also begins with an H1. One repo solves this in two layers.

The renderer normalizes body-level MDX H1 elements to H2, and the validation script verifies that the normalization remains in the article template. This is a better system than telling every writer, forever, "Remember that this editor looks like Markdown but please never use a single hash."

Canonicals should not depend on memory

When page metadata is created manually in every route, it is easy for one page to omit the canonical. A centralized metadata builder can generate it from the page path. The validation can then verify that routes expected to use that helper still use it.

This is a recurring pattern in our codebases: centralize the rule, then validate that the central system remains attached.

Build failures are cheaper than production fixes

Nobody enjoys a failed deployment because a metadata field is missing. That is still better than shipping the page, letting it get indexed, finding the issue in Search Console later, fixing it, redeploying, and waiting for recrawl. The earlier a failure is detected, the cheaper it usually is.

A build is a good place for errors that are deterministic and actionable.

We do not automate subjective SEO

A script cannot tell us whether the page deserves to rank. It cannot decide whether the service copy is persuasive, whether the local page has enough genuine substance, whether the article answered the question well, or whether the search intent is commercially useful.

Those are editorial and strategic judgments. We automate the things a machine can know reliably so human attention can stay on the things that require judgment.

The audit itself evolves

As we discover recurring failure modes, we can add checks. If social images keep pointing to the wrong host, test for it. If preview URLs keep becoming indexable, validate the header. If new content types need structured data, add a schema check for that route family.

This gives the site institutional memory. The lesson from a bug can become a permanent build rule instead of a note somebody eventually forgets.

Why this is part of our value

A technically strong site is not one that launched cleanly once. It is one where the release process makes it harder to regress. That is why our SEO work extends into code, build scripts, route architecture, and deployment behavior. We are not replacing SEO judgment with automation.

We are using automation to protect the technical floor underneath it.