Rankdough learned this the expensive way: a content checklist filled in by the same model that wrote the page ticked “sources under every section” as complete for four months on pages that had none; the fix was a checker that runs outside the writer, reads the finished HTML and counts, and every position-1 page on dentaltourismalbania.com today was generated after it went in.
TL;DR
For four months a checklist filled in by the same model that wrote the page ticked “sources under every section” as complete on pages that had none. On 8 June 2026 I traced the cause to a parser that dropped hyperlink targets from Word briefs, so the writer received claims without URLs. The fix was a checker that runs outside the writer, reads the finished HTML and counts.
How this was researched
The work behind the numbers, so you can judge them for yourself.
EFFORT
Four months of checklists reviewed
We went back through four months of the system’s own checklists, traced the missing sources to a parser bug on 8 June 2026, and rebuilt the check outside the writer.
ORIGINALITY
From our build record
The failure and the fix come from our own content system, with dates.
SKILL
Run by an SEO, not a tool
Diagnosed and fixed by Roman Sadowski, who reads the finished pages the checker passes.
ACCURACY
What it doesn’t prove
The ranking gains in the same period can’t be put down to the checker alone. Other rules changed at the same time.
How does a checklist go green on a failing page?
The original design was reasonable on paper. After generating an article, the model received the rule list and the article, and returned a tick or cross per rule. Rules included: sources under every section, references list of four or more, no links in the TL;DR, five FAQs, word count within range.
It returned ticks. On 29 May I opened a page the checklist had passed and found no source line under any section.
The checklist said they were there. The model had evaluated its own intent rather than its output: it had been told to add sources, it believed it had, and it reported that belief.
Source: Rankdough content system build record, verification checklist review, 29 May 2026
This is not a quirk of one model. Any system where the producer certifies the product will drift toward reporting the instruction rather than the result, because the instruction is what it has in context. The output is what it needs to read, and reading output is a separate job.
What were the four failures behind one missing source line?
Finding why sources were missing took longer than building the checker, and each cause was invisible to the checklist.
- Invented URLs. Early builds cited plausible paths on real domains that did not exist. A checklist cannot tell a fabricated URL from a real one. A fetch can.
- The parser dropped hyperlinks. Research briefs were uploaded as Word files. The parser read the text nodes and ignored word/_rels/document.xml.rels, where Word keeps every link target. The writer got claims with no URLs and cited nothing. Found 8 June by comparing parser output against the source file.
- Preview and production ran different builds. A fix would show in the preview and not on the live edge function. “Fixed” was true in one environment and false in the other. Resolved on 15 June by stamping each function with a build marker and reading the marker from the boot log before trusting any result.
- Own-domain citations. When sources did appear, some pointed at the client’s own pages, because those URLs were in the brief. The checklist counted them. A reader would not.
| Cause | What the checklist saw | What caught it | Date fixed |
|---|---|---|---|
| Invented URLs | A citation present | Fetching every link | 6 May 2026 |
| Word parser dropped hyperlinks | Sources “added” | Reading parser output against the source file | 8 June 2026 |
| Preview and production on different builds | Fix “deployed” | Build marker in the boot log | 15 June 2026 |
| Own-domain citations | References counted | Domain check on every reference | 26 May 2026 |
Table 1. Four causes behind one missing source line, and the test that found each. Rankdough content system build record.
Four causes, one symptom, zero caught by self-report. Each needed its own test, and each test had to read something the writer had not written: the HTML, the HTTP response, the boot log, the domain of the link.
What does the independent checker test?
The checker runs after generation, against the finished HTML, with no access to the writer’s reasoning. It returns a pass, a flag with the failing sentence, or a fail that returns the article to generation. Current tests:
- Direct answer present in the first 80 words, containing a number or a verifiable claim
- At least two numerical elements in the opening and the TL;DR
- Five sourced data points in the article, three inside the first 30 percent
- Source line under every section except TL;DR, quick tips and overview
- References list of four or more external URLs, none on the client’s domain
- Every URL fetched; broken links removed
- Hedge lint: “typically”, “usually”, “varies”, “depends” allowed only in a sentence with a number
- Non-commodity test per section: a number, a failure mode, a category distinction, or a contrarian claim
- Table guard: four or more real rows, one numeric column, no placeholder rows
- FAQ contract: exactly five questions, direct first sentence, no “it depends”
- Structure: one answer paragraph plus three bullets per section, no links in the TL;DR, exactly one inline link per section from the allow list
- Value promise fulfilled, checked point by point against the brief
This list was compiled from the compliance guard and prompt assembler rules as deployed on 15 June 2026.
After the checker, a separate flow read goes through the whole article as a reader would and returns flags with fix actions, one per section. That pass exists because a page can satisfy every countable rule and still not hold together.
Why did every rule have to become countable?
A checker that reads output can only test what can be counted. That constraint reshaped the rules.
“Use tables where helpful” became “one table per 600 to 1,000 words, four rows minimum”. “Cite your sources” became “a source line under every section and four references”.
“Be specific” became “five data points, three in the first 30 percent”. “Avoid hedging” became a word list with a numeric condition.
The side effect was that the rules got better. A rule precise enough for a script to test is precise enough for a writer to follow, and for a client to audit. Vague rules are where quality quietly leaks.
What changed once the writer stopped grading itself?
The references rule was specified on 30 January and held from 8 June. The pages generated after that date are the ones that now hold positions 1 and 2 on dentaltourismalbania.com: “when can you eat after tooth extraction” at position 2 in the United Kingdom above NHS and Bupa, “can I put orajel on my tooth extraction” and “can I drink water with my retainer in” at position 1 in the United States. Each carries a source under the section that makes the claim.
Across the site, keywords in the top 3 went from 18 in March to 593 in July. Rankdough does not attribute all of that to the checker; the answer-first rule and the data-point floor landed in the same window. What I can say is that no page generated before the checker holds a position-1 ranking on that site today, and every position-1 page was generated after it.
How do you apply this without a content system?
- Separate the roles. Whoever writes the page does not sign it off, whether that is a person or a model. Rankdough applies that rule to its own output and to every client page it reviews.
- Check the artefact, not the intention. Open the published HTML, not the draft, not the brief.
- Make the checklist countable. If a rule cannot be scored pass or fail by someone who did not write the page, rewrite the rule.
- Fetch every link. Fabricated and dead references look identical in a document and different in a browser.
- Verify the environment. If a fix is “deployed”, confirm the live version carries it before reporting it fixed.
FAQ
Why does a self-filled checklist fail?
The producer evaluates its instruction rather than its output. It was told to add sources, it believes it did, and it reports that belief. Only a reader of the finished page can report what is there.
What does the independent checker read?
The finished HTML only, plus live fetches of every link and the build marker of the function that produced the page. It has no access to the brief or the writer’s reasoning.
How long did it take to get sources reliable?
Specified 30 January 2026, held from 8 June. Fourteen builds, four separate causes, each invisible to the original checklist.
Does the checker slow production?
It returns failing pages to generation, which costs a second pass on the articles that fail; Rankdough has not yet published the failure rate. It removes the much larger cost of publishing pages that fail quietly for months.
Is a human still involved?
Yes. After the countable checks, a flow read goes through the whole article and flags anything that satisfies the rules but does not hold together. Rules catch omissions; a reader catches incoherence.
