Case Study: We Scored 42/100 on Our Own SEO Audit

What did the audit find?

Six findings: one critical indexability fault, one high-severity content gap, and four medium issues spanning sitemap quality, missing canonicals, thin pages and sparse internal linking. Health score 42/100.

Not on that list, because our own checker did not flag it as a scored issue, was the worst problem on the site. We only caught it by reading the raw crawl output.

What was the bug that mattered most?

Our robots.txt told Google the sitemap lived at http://localhost:3000/sitemap.xml. Every crawler that read it was pointed at a machine on a developer's desk. Effectively we had no sitemap at all.

The cause is worth explaining because it is not an SEO mistake - it is an engineering one with SEO consequences, which is the most common kind. In Next.js, environment variables prefixed NEXT_PUBLIC_ are inlined into the bundle at build time. Our robots.txt route read NEXT_PUBLIC_APP_URL to construct the sitemap location. On a developer machine that variable is http://localhost:3000. The value was baked into the production build.

Nothing about this is visible in a browser. The site looked perfect. Every page rendered, every link worked, and the one file whose entire purpose is to talk to crawlers was quietly lying to them.

The same root cause had already produced a second bug we had fixed days earlier, where OAuth callbacks and post-checkout redirects pointed at localhost in production. Same mechanism, different symptom.

What did we change?

Six technical fixes and one content build. The technical work took under an hour; the content - nine guides, roughly 9,000 words - was the bulk of the session.

1. 1Made the site origin a constant rather than a build-time variable, so no environment can leak into production metadata again.
2. 2Rebuilt the sitemap to list only canonical, indexable pages - the old one contained fragment URLs like /#pricing, which are not pages and teach crawlers to distrust the file.
3. 3Added self-referencing canonical tags across every page.
4. 4Excluded /dashboard and /progress from crawling in robots.txt rather than only noindexing them, so a young domain does not spend crawl budget on pages that can never rank.
5. 5Added sitewide robots directives, an Open Graph card and a favicon.
6. 6Built a nine-guide content cluster targeting the queries the site should own, interlinked with the homepage and footer.
7. 7Lengthened one page title that fell under the 25-character threshold.

What was the result?

100/100 with zero issues, verified by re-running the same audit against the live site in production. Crawled pages went from 2 to 8, and the sitemap from 5 entries to 11 real pages.

One honest caveat, because a case study without one is marketing. 100/100 is the technical and on-page half. It does not mean we rank - the domain is new and has very few referring domains, and no on-page work substitutes for authority. What it means is that nothing technical is standing between our content and the index, which is the precondition for everything else rather than a result in itself.

What is the transferable lesson?

The faults that cost the most are invisible in a browser and introduced by deployments, not by bad SEO decisions. That makes crawl frequency, not crawl depth, the variable that protects you.

We knew SEO well enough to build a product around it and still shipped a robots.txt pointing at localhost. Not through ignorance - through the ordinary mechanics of a build system doing exactly what it was configured to do. Expertise does not prevent this class of bug. Measurement does.

If our audit had been running nightly from the first deploy, that fault would have surfaced the next morning instead of surviving until we thought to check. That is the entire argument for continuous measurement over periodic auditing, and we are the case study for it.