Technical SEO: pages search can find, read and load
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 I build the fix into templates and checks so it holds as the site grows.
The work, from discovery to use
Four places a useful page can lose its chance
- 01
Crawl
Can a crawler reach the page through real links and read its response?
- 02
Index
Is the right URL eligible to be stored, with duplicates and canonicals handled deliberately?
- 03
Render
Does the answer exist in the HTML, and does the rendered page keep it clear?
- 04
Experience
Can someone use it comfortably on a phone, without a slow or shifting page getting in the way?
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.
Any one of these can lose a reader. Below is where I did this work on real sites.
The technical work, project by project
- The checks behind every site
- Every check this site runs, the failure behind each one, and the bad input it is proven to catch.
- CheckMyTap
- A large catalog where reviews stopped being enough, and the build check that now stops known errors.
- The Crawler's Cookbook
- A source check that caught an overclaim, the correction, and a tighter check after it.
- How this site is built
- One URL registry that drives the pages, the sitemap and every redirect from the old site.
- Technical SEO: clarity for crawlers and people
- My post on what technical SEO is for, with the three questions every page should answer.
- Personal audit: where AI output fails
- The launch mistakes that turned rules into checks.
One small failure, one lasting fix
The same fact should not change from page to page
My old site called itself “four live sites” on some pages and “five live sites” on others. This one keeps that fact in a single data file. Every page that mentions it now says 10; a change in one place changes all of them.
data/sites.json10 public sitesWhy I fix the data source instead of the page
When something on a page is wrong, the fix goes in the data or the template that made it, so every page built from it is fixed at once.
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.
Three questions every page has to answer, and where this site answers them in code
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. | The build stops on any page without an entry, or an entry without a question. |
| 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. | The build stops on a page nothing links to, a link to a missing page, or a next-step link that disagrees with the map. |
| Why does it exist within the site? | The entry names who lands on the page and where they arrive from. | The build stops: a page with no reader written down doesn't ship. |
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 real page. That is 23 checks in all, and 20 of them first prove they still catch a planted mistake. How the link checks work
Where these checks fit in the way I work: how I think.
Every check, and the failure behind it