How I keep my sites accurate
I start with who a page is for, then add a check for every mistake that got through.
Why so many checks: my own audit
DNever ship a wrong factOne of six principles in my SEO method; its mascot is Umbreon
Most of my time goes to deciding what deserves to exist. The checks buy time for that by catching the mistakes I shouldn't have to find twice.
See how it worksThe checks that catch mistakes before readers do
Each step below began with a way a live page could fail. The answer is a repeatable check, followed by my own review where judgment matters.
-
A page starts with a question someone asked
What can go wrong: A page can rank and still leave the person searching without an answer.
I name the reader, their question and the useful next step before writing the page. Then I check that the next step really goes there.
See how one unanswered fan question became a page -
The path through the site works
What can go wrong: An old address or an internal link can quietly strand someone after a site changes.
Every page and internal link is checked against what actually exists. Old addresses are mapped before the move; whether each destination is the right answer still needs my review.
See the work those paths lead to -
The page works on a phone
What can go wrong: A desktop layout can hide an answer, force sideways scrolling or make a button too small to tap.
Every page is opened at phone width. Automated checks catch overflow, low contrast and cramped targets; I still read the screen myself to judge the answer.
Read the plain-English explanation -
My words stay my words
What can go wrong: A copied quote can change by a word and still look authentic.
Lines I published before are compared with their original text. A changed line stops publication until I check it, and so does a take written in my voice that I never said.
Read the personal story -
A shared page makes sense before the click
What can go wrong: The title, image or description in a message can promise a different page from the one that opens.
Each page gets a share image tied to its current title, plus its own description and a path back through the site. I review the small preview by eye.
Browse the writing -
An unfinished page stays unfinished
What can go wrong: A draft can look complete to the publishing system while its claims or wording still need a person.
Every page needs a review record tied to the exact words on it before it can publish, and a page whose words change afterward is flagged for another look. A stub, placeholder copy or a leftover noindex stops the build. A clean check still can't say whether a page's story is good, so I read the live pages myself.
What shipped, and what happened after
The numbers need a second look too
Across my own sites, I compare search visibility, visits and changes over complete periods. A rising line by itself does not tell me what worked. I note what changed, where the number came from and when it was measured.
That is how a surprising result becomes a useful decision, including when the answer is that an idea did not work.
Partial months can make ordinary changes look dramatic.
A number is useful only when I can tell where and when it came from.
I can measure what happened. Why it happened may still be a hypothesis.
Times I was wrong, and how I caught it
Each of my sites with a recorded miss gets a row, oldest site first, with the miss marked on the step of my system where it happened. Open a row for how I caught it, what was actually wrong, the fix and what stops it now, drawn as a row from my game: a hollow block is something still open, and a miss with nothing open collapses to a line with the day it cleared. Some were my site's data, some my content, and some just my judgment.
Of three misses, none sat at steps 1 to 3, where I research the reader, map the site and design the page. Two came at step 4, writing with sources, and one at step 5, building with checks.
| Step 1: Research the person, not the keyword | Step 2: Map the architecture before any design | Step 3: Design for the moment they arrive | Step 4: Write it in my own voice, with sources | Step 5: Write the standard first, then build to it with AI | Step 6: Measure, then decide again | Step 7: Learn from the miss, and fix the system | |
|---|---|---|---|---|---|---|---|
| CheckMyTap | Missed at step 5 | ||||||
| WireRef | Missed at step 4 | ||||||
| Fan reference | Missed at step 4 |
| Site | Step | The miss |
|---|---|---|
| CheckMyTap | Step 5: Write the standard first, then build to it with AI | My water-quality catalog shrank in Google: 1.6K pages indexed, then 218 |
| WireRef | Step 4: Write it in my own voice, with sources | A WireRef page said a wire carried 200 amps. It carries 180. |
| Fan reference | Step 4: Write it in my own voice, with sources | I made a release-date answer sound more certain than its sources |
My water-quality catalog shrank in Google: 1.6K pages indexed, then 218
- How I caught it Search Console's indexing report, which I read every month, so I watched the slide build month by month.
- What was actually wrong Repeated reviews weren't enough to keep every claim safe on a catalog that size. I can measure the decline; the numbers alone don't explain it, and I won't pretend they do.
- The fix A content-integrity sweep, then a build check that stops the site from publishing a known kind of error.
- What stops it now Now a page that breaks the rule doesn't go live. The next step, holding everything when the check itself crashes, is written and not shipped yet.
A WireRef page said a wire carried 200 amps. It carries 180.
- How I caught it A traffic review. I was reading the pages people actually landed on, and the number didn't match the code table the site is built on.
- What was actually wrong The 200 came from a different rule, the wire size the code allows for a whole-home service, borrowed when a lookup came up empty. Right number, wrong table, and on an electrical site that's a safety problem.
- The fix The page, and every page with the same pattern, now uses the right table and labels service sizes as service sizes.
- What stops it now A check now compares every ampacity claim on the site with the code table. It was proven to fail on the old pages before it shipped.
I made a release-date answer sound more certain than its sources
- How I caught it A later source check of the forthcoming book page, the one fans read most.
- What was actually wrong One claim went further than the sources did, on a page built to separate what's confirmed from what's rumored.
- The fix Corrected in my files on August 2. The fix sat on a branch until August 17, when it reached the live page, and the tighter check went live August 29.
- What stops it now A tighter check around the page. A dated page now has to stay as careful as its sources.
More times I was wrong, newest first
-
WireRef's chart page stated the wiring code backwards
Cleared : found the cause, fixed, and a check now stops it coming back. - How I caught it While fact-checking this site. A second AI pass flagged a line about the code; I loaded the live page myself and found the chart page had the rule the wrong way round and left out the breaker limits for small wires.
- What was actually wrong For circuits of 100 amps or less, the code's default is the 60°C column unless the equipment is rated 75°C. The page said the opposite, and its table showed 14-gauge copper at 20 amps without saying the breaker tops out at 15. Every other page on the site had it right, which is exactly why a page-by-page review never caught it.
- The fix Fixed and live the same day.
- What stops it now A new rule in the site's safety checks failed 11 times on the old page and passes on the new one, so this can't come back without the build stopping.
-
I wrote my rules of thumb as if they were industry standards
Found the cause and fixed. Still open: a check that stops it coming back. - How I caught it An accuracy pass that traced every number on this site back to a source. My search intent posts had thresholds, like how many options a comparison page needs, with no source behind them.
- What was actually wrong They were my working rules from building pages, presented as facts, and a reader couldn't tell a working rule from a standard.
- The fix Each post now says plainly that its numbers are my own rules of thumb, with no published standard behind them. The advice itself stayed.
- What stops it now Numbers in new writing get the same test: a source, or a label that says it's my judgment.
-
My published SEO framework didn't match how I actually work
Found the cause and fixed. Still open: a check that stops it coming back. - How I caught it I pulled 2.2K of my own messages about how I build sites and sorted them. The patterns didn't fit the fifteen neat pieces I'd published.
- What was actually wrong The fifteen pieces were published before they were tested against the work they described.
- The fix Six pillars, built from those messages, are replacing the fifteen pieces.
- What stops it now A framework gets tested against work on my own sites before it's published, the same as a page.
Mistakes that changed the way I work
In March 2026 I ranked the mistakes from my first launches. Here is that list, next to what I do differently now. Some still depend on a person noticing the problem; I say so.
Of the 9 mistakes I ranked, 4 are now caught before a page publishes, 1 is partly covered, and 4 still need a person to read the page.
Caught before publicationPartly coveredNeeds human review
| Mistake | State |
|---|---|
| Mistake 1 | Needs human review |
| Mistake 2 | Needs human review |
| Mistake 3 | Needs human review |
| Mistake 4 | Caught before publication |
| Mistake 5 | Caught before publication |
| Mistake 6 | Caught before publication |
| Mistake 7 | Needs human review |
| Mistake 8 | Caught before publication |
| Mistake 9 | Partly covered |
| What went wrong | What I do here | How far that gets me |
|---|---|---|
1 Fabricated source data published as fact. |
A source and date sit beside each published result. That helps me trace it, but I still have to compare a claim with its original source before approving it. | Needs human review |
2 Safety-critical specs sourced from secondary sites. |
When a page depends on technical specifications, I still have to verify the original source. This site cannot do that judgment for me. | Needs human review |
3 Incomplete data presented as complete. |
A complete-looking page can still leave out an important exception. I review the answer and its limits before calling it ready. | Needs human review |
4 Broken indexation signals at launch. |
Pages need one clear address and a path that search engines can follow. I check both before publication, then inspect live search results after the move. | Caught before publication |
5 Orphan pages and broken navigation shipped on day one. |
Every page needs a route in from another page, and every link has to land on a page that exists. | Caught before publication |
6 No validation layer in the build system. |
The site checks its links, visible pages, words and phone layouts before a change can reach the live site. A person still decides whether the result is good. | Caught before publication |
7 Broken search features shipped on launch. Twice. |
The site search indexes only the main answer on each page, so the menu, Bella and the footer never make unrelated pages match the same query. | Needs human review |
8 Mobile usability was not entirely verified before launch. |
Every page is opened at phone width before publication. I still read the rendered screen to judge the order and the answer. | Caught before publication |
9 No separation between data and templates. |
Shared numbers come from one source instead of being retyped across pages. That reduces drift; it does not prove the source itself is correct. | Partly covered |
Every number on this page, with its source and date
The rule this page is about, applied to the page itself.
- The ways a page can fail, above
- 6, each tied to one of the 83 checks that run on every change, counted from the check scripts themselves, as recorded for this page on .
- Times I was wrong, above
- 6, from my own records, the newest dated .
- The March 2026 audit
- 9 mistakes ranked: 4 caught before a page publishes, 1 partly, and 4 that still need a person to read the page. Mapping checked .
- The Quack Report read-through
- 161 pages, six readers, about 80 stale sentences, 36 checks passing: , from that site's own change log.
- Every other number here
- Sits in a section that carries its date: each mistake above has the month it happened, each audit row the audit's date.
A number I can't source or date doesn't go on this page. A section above that shows one with neither stops the site from publishing.
Seven steps to build it, in order
The six pillars on my SEO system say how I work; these steps say the order I build in. Each one has to be right before the next starts, because a mistake in the structure costs a sentence to fix early and a rebuild to fix late. Pick a step to see what it took on this site.
- Step 1Research the person, not the keyword
- Step 2Map the architecture before any design
- Step 3Design for the moment they arrive
- Step 4Write it in my own voice, with sources
- Step 5Write the standard first, then build to it with AI
- Step 6Measure, then decide again
- Step 7Learn from the miss, and fix the system
Step 1
Research the person, not the keyword
Before anything gets built, I find out who is actually searching, what they're trying to do, and what nobody has answered well yet.
On this site, as of My own Search Console showed that 22 of the 25 Google clicks with a visible search behind them came from people searching my name, and when I searched my name on Google on October 11, 2026, my homepage didn't show up at all. So the reader came first: someone deciding whether my work holds up, who wants to know who I am and whether I'm good. I also studied 18 sites run by SEOs I respect, and read every page of my old site.
Before I move onI can name the reader, their question and what they'd do next.
Step 2
Map the architecture before any design
Every page gets a reader, a question and a next step, and every page has a parent, siblings and a way onward. The structure is decided while it's still cheap to change.
On this site, as of Before a single page was designed, I mapped all 80 pages this way, grouped the writing into eight topics from my old site, and gave each of 158 old addresses a new home, so nothing anyone had linked to would break.
Before I move onNo page exists without a reason, and no page is a dead end.
Step 3
Design for the moment they arrive
Phone first, story first. The first screen answers the question the reader came with, and the design has one language, where every color means the same thing everywhere.
On this site, as of Every page here is designed from a 390-pixel phone up, and is checked at five screen sizes before it can go live.
Before I move onSomeone on a phone gets the answer without scrolling.
Step 4
Write it in my own voice, with sources
The words have to sound like a person who did the work, and every fact has to hold up when someone, or an AI answer, checks it.
On this site, as of When the site quotes me, it's my own words. Every number has a source and a date, and the hard numbers come from my own sites.
Before I move onEvery claim can be traced to where it came from.
Step 5
Write the standard first, then build to it with AI
I write the standard down first: what must be true and what has to be checked. Then I use AI for the research, the data work and the repetitive building to that standard, and I check what comes back. I run two AI tools against each other's work, and I make the final call on every finding.
On this site, as of This site runs 83 checks every time it changes, and nothing goes live until all of them pass. That frees my time for the parts no check can do: what to build, how it should feel, and what to say.
Before I move onNothing goes live that a check could have caught.
Step 6
Measure, then decide again
After something ships, the data says whether it worked. I compare complete periods, label what's measured versus what I think it means, and change course when the data says so.
On this site, as of The receipts on this site are real captures: Search Console and Bing screenshots, Clarity heatmaps and phone captures of the live pages, and the decision log lines up each big change with what happened after it.
Before I move onI know what changed, and I can say whether it worked.
Step 7
Learn from the miss, and fix the system
When something goes wrong, I don't just fix the page. I find out why it happened and change the system, so that mistake can't happen again anywhere.
On this site, as of Each check this site runs is there to stop a specific mistake: a misquote, a broken link, a page that fails on a phone. Several began as mistakes I actually made. The first version of this site passed every one and still wasn't good enough, so the critique became the checklist.
Before I move onThe fix changes the system. A promise to be more careful doesn't count.
At my full-time job, I make these decisions with more pages and more teams involved: how I work there.
How a mistake makes the system better
Everyone makes mistakes. The useful question is whether the same one can happen twice, so after I fix the page, I go after whatever let the mistake through. Five of mine, told like the wins:
- CheckMyTap: On a site with a page for every city, careful reviews still let errors through. What I changed: I added a check that reads every page before it publishes and stops the whole site when it finds a known kind of error. Found the cause, fixed, and a check now stops it coming back. Still open: making the site refuse to publish when that check itself breaks.
- An independent fan reference: A pop-up kept getting in readers' way on phones. My first fix made it disappear faster, and I assumed that solved it. What I changed: Tap data from Microsoft Clarity said otherwise: its close button was still the most-tapped thing on the page, 495 of 2.6K phone taps from Aug 8 to Sep 6, 2026. The cause was how often it appeared, so I fixed that and added a check that re-creates the old bug on every build. Cleared : found the cause, fixed, and a check now stops it coming back.
- This site: a misquote: I retyped one of my own old lines from memory and got a word wrong. What I changed: Lines quoted from me now come straight from what I published, never retyped. Cleared : found the cause, fixed, and a check now stops it coming back.
- This site: version one: The first version passed every check, and it still wasn't good enough. What I changed: The critique became a written checklist, and every page gets rebuilt against it, one at a time, judged on a phone. Found the cause and fixed. Still open: a check that stops it coming back.
- An independent fan reference: I logged a new page as a decision in July. It was finished, but it sat on a branch that was never merged, and Google never showed it once. What I changed: Now a decision only counts as shipped once the page is live and I've loaded it to check. Found the cause. Still open: the fix and a check that stops it coming back.
What the checks can't tell me
It cannot tell whether an industry example is fair to a client, whether a number's cause is known, or whether the first screen says something a reader remembers. I still have to read the page, verify its sources and ask what it leaves out.
On , six readers went through all 161 pages of The Quack Report and found about 80 stale sentences while 36 checks were green, by that site's own change log. The checks had read the data and never looked at the finished pages. I added one that reads the rendered copy, but the human read is what found the gap. That site's story shows what was at stake.
That is why I show the misses alongside the wins.
The audit that started this
The first useful step was writing down what I had gotten wrong. The second was finding out which mistakes I could stop repeating.
Read the personal audit