I check whether a crawler can find the page, whether the right version gets indexed, whether the answer survives rendering, and whether it works on a phone. Then the fix goes into templates and checks so it holds as the site grows. A page that fails any of the four never gets its chance, whatever the answer on it says.
What every page on this site has to pass before it goes live
A fix made by hand on one generated page is undone the next time the site builds, and the same mistake stays live on every other page made from that template. At a few hundred pages, hand fixes stop being maintainable at all.
Fix source files, never generated output.
The JSON data and templates are the truth. The HTML pages are the output. Every fix happens upstream so it propagates everywhere.
Can a crawler reach the page through real links and read its response?
Is the right URL eligible to be stored, with duplicates and canonicals handled deliberately?
Does the answer exist in the HTML, and does the rendered page keep it clear?
Can someone use it comfortably on a phone, without a slow or shifting page getting in the way?
Why the first two come first, in Google's words: Google primarily finds pages through links from other pages it already crawled.
And: Indexing isn't guaranteed; not every page that Google processes will be indexed.
So a page no link reaches, or one Google found and left out, is where I start. Sources: Google's SEO Starter Guide, updated December 10, 2025; Google's guide to how Search works, updated December 18, 2025.
On a site with thousands of templated pages, each of those four gets harder in its own way: how I think about technical SEO on complex websites.
In my unnamed data-reference case, a prepublish audit held a change while older output remained live. The case shows why I verify the release as well as the build.
From my full-time work, the method
A resource center that grew up outside the main site's search setup
Guides, articles and downloads pile up for years, often on their own platform or folder. The main site gets the crawl and index basics; the resource center often doesn't, so search engines find its pages slowly and can index more than one version of the same one.
What I gave the developers
Why: a developer acts on an instruction. "Canonicals are missing" is a diagnosis, and it waits in a backlog. An instruction with the exact tag, the template it goes in and a way to test it gets shipped. And fixing the template fixes every page built from it.
My old site stated the same simple fact two different ways on different pages. This one keeps facts like that in a single data file that every page reads. My job title is one: the pages that show it, from the homepage to every post's byline, read Senior SEO Manager from that file, so a change in one place changes all of them.
The site
CheckMyTap: 1.8K URLs in the sitemap, 583 of them discovered by Google and not indexed
My plan had called for about 30 deep pages. Six weeks later the catalog had outrun it, and the index was telling me so.
What I did
Set 200 thin pages to noindex, which cut the sitemap to 1.6K, and rebuilt the site at the commits before and after to prove the counts. The lesson went into a build check that stops the site from publishing a known kind of error.
Bing went from 560 to 1.4K indexed CheckMyTap pages in April 2026 alone. Bing Webmaster Tools, index counts, through Oct 4, 2026. Google went the other way, and the case study says what I can and can't explain about that.
The CheckMyTap story, including the dropAfter an Oregon game, The Quack Report kept advertising a game that had already ended. It stayed that way for nine days. The daily check found the stale page each time, but the workflow reported success.
tee. The workflow read tee's success instead of the check's failure, so nobody got the warning.The repair traces the whole path from source data to the live page: the check now reads the same files that get published, and a failure holds the release. The Quack Report case study shows the site around that decision.
The real purpose of technical SEO is clarity.
| The question, from my post | Where this site answers it | What happens when it's missing |
|---|---|---|
| What is this page about? | Every page has a written entry: the question it answers. | That page doesn't go live, and neither does an entry with no question in it. |
| How does it relate to other pages? | The same entry names the page above it, the pages beside it and the one page a reader should go to next. | A page nothing links to, a link to a missing page or a next step that disagrees with the map never goes live. |
| Why does it exist within the site? | The entry names who lands on the page and where they arrive from. | A page with no reader written down doesn't go live. |
Checked every time the site changes: every page needs a reader, a question and a next step, and every internal link has to land on a page that exists. Those are two of the 83 checks that run on every change, and 74 of the 83 first prove they still catch a planted mistake. How the link checks work
Here's what a crawler gets from this site, counted on the finished pages rather than taken from what I meant to build.
| Part | What a crawler gets | What keeps it true |
|---|---|---|
| Crawl | 78 pages in the sitemap, each with the date its content last changed. | One list of addresses builds every page, so nothing on the list goes missing. |
| Crawl | 135 old addresses send a 301 straight to their new page, and 23 retired ones answer with the 404 page. No chains. | Every redirect has to land on a real page in one hop before a release goes out. |
| Index | The canonical tag on 78 of 78 pages points to the page itself. | Set once, in the template every page uses, from the page's own address. |
| Index | Structured data naming the site and me (WebSite, Person) on every page, and an Article on each of the 39 posts and case studies. | Counted on the finished pages, never assumed from the template. |
| Render | The first-screen answer is in the HTML on 78 of 78 pages, so it's there with JavaScript off. | Every page is also loaded with JavaScript off before a release; one that loses its answer stops it. |
| Experience | At most 200 KB of CSS, 88 KB of JavaScript and 220 KB of HTML on any page. | A page over any of the three fails the release check. |
| Experience | 2 font files, served from this site. No font requests go anywhere else. | Every character on the site is one the fonts can draw, so you never see an empty box. |
| Experience | 2 outside scripts, both analytics (www.clarity.ms, www.googletagmanager.com), and neither loads when a browser sends Global Privacy Control. | Those two are the whole list; a third can't sneak in with an update. |
From this build, last changed . The checks themselves: every check, and the failure behind it.
The rule this page is about, applied to the sheet above.
That's the whole method in one section: a fact that could drift gets a check the day it ships, and the check keeps running from then on.
Each pillar of my system is an Eevee evolution, picked for its best stat. This page is pillar F, turn every lesson into a system.
Its best stat is Sp. Atk, and its whole move set is about freezing things in place. That is what every check on this page does: a lesson becomes a rule the build enforces, so it never has to be learned twice.
Base stats from PokeAPI, read October 14, 2026. Every Eevee evolution totals 525, so none is stronger, only built for a different job.
All six evolutions, and the pillar each one runsThe newest post on this, if you'd rather read than look
Why a page isn't showing up in search When a page doesn't show up in Google, I find out how far it got, from known to shown, and change what that step needs, with my own site's relaunch as the example.Where these checks fit in the way I work: how I think.
What every page on this site has to pass before it goes liveThis page was last updated