Findings · 2026-09-16 · By VSNARY | Emmanuel Orta · 0 views
Our crawl-waste check named a parameter called amp;plan. No site has one.
Nineteen parameter names in the corpus began with amp; because an href was split on & before its escaped ampersands were decoded. The counts were right the whole time. The names beside them were not.
On 16 September 2026 we read every crawl-waste record in the corpus to decide whether the section had earned a weight in the grade. It had. It had also been publishing parameter names that do not exist. Nineteen of the names it reported began with amp;: amp;utm_medium, amp;utm_campaign, amp;plan, amp;return, amp;aid. No site on the web has a query parameter called amp;plan. Our reader had manufactured them.
The cause is one line. An href in an HTML attribute carries its ampersands escaped, &, because a bare & starts an entity. The check read the attribute value, handed it to the URL parser, and split the query string on &. The first split lands correctly on &'s own ampersand and leaves amp; glued to the front of every parameter after the first. The parser never complained, because amp;plan=pro is a perfectly legal key-value pair.
Why nothing caught it #
The count was right. A link with ?a=1&b=2 is one link with a query string whether you split it well or badly, and the row the section scores from is the share of internal links carrying a query string, not the names of the parameters in them. So every number the section published was correct, and the one field that was wrong, the four most common parameter names printed under it, was the field a human reads to decide what to fix. A reader seeing amp;utm_medium would have gone looking for a parameter that was never there.
The unit tests passed because the fixtures were written by hand with bare ampersands, which is how a person types a URL and not how a page serves one. The same class of defect has appeared here before, in the other direction: a FAQ check that compared schema text against rendered text and missed five matches because ' in the HTML was never unescaped before the comparison. Escaping is the boundary between what a page carries and what a page means, and every reader that crosses it without decoding produces answers that look like data.
The fix, and what it changed #
Build 464 unescapes & and & in the attribute value before the URL is parsed. One site that had read hsLang, utm_source, amp;utm_medium, amp;utm_campaign on the previous build was rescanned the same hour and read hsLang, utm_source, utm_medium, utm_campaign. The counts on that record did not move: 133 of 183 internal links still carry a query string, and that figure was hand-checked from a separate fetch before the section could be trusted with it, 136 of 186 from a different vantage on the same page, the difference being what rendered.
Records scanned before 464 still carry the old names until they are rescanned. That is a property of a record: a stored reading describes the reader that produced it. The corpus re-measures on a schedule, so the names age out on their own, and no stored figure was rewritten, because a reading edited after the fact is not a reading.
What the calibration found, once the names were right #
The section was shipped reported-not-scored on 9 September, following the rule that a check earns a weight only after it has been read across the corpus. The read on 16 September covered 111 records, every scan since the section shipped. The table is the share of those 111 carrying each signal.
| Signal | Share of 111 measured sites | Reading |
|---|---|---|
| Internal links carrying a query string | 23% | discriminates; the 90th percentile is 3% of links, the worst site 73% |
| Uppercase in an internal path | 13% | discriminates |
| Declared sitemap URLs that redirect | 8% | a true defect on every site it fires on |
| utm_ on internal links | 7% | a true defect, rare |
| Apex and www both serving 200 | 6% | a true defect |
| Sitemap trailing slash used both ways | 5% | marginal |
| Sitemap URLs with uppercase, a query, or http | 6%, 2%, 1% | too rare to weight alone |
| Declared sitemap URLs that are gone | 2% | too rare to weight alone |
| Internal links to http:// | 3% | too rare to weight alone |
| Any signal | 46% | |
| Two or more | 18% |
Three tests decide whether a section may carry weight here: it must be measurable on most of the corpus, it must split the corpus rather than pass or fail everyone, and any reading that accuses a site must have been confirmed by hand on at least one real case. Crawl waste passes all three: 111 of 111 measured, a 46 to 54 split, and the largest accusation in the set, the site with 133 query-string links, checked against an independent fetch. What it will score is the three rows that discriminate and are true defects: query-string links above 5% of internal links, any declared URL that redirects, and both hosts serving. The rare rows stay reported. The weight lands in the next score-version bump together with two other sections that passed the same gate, so peers are re-scored once rather than three times.
Why the redirecting-sitemap row matters more than its 8% #
A declared URL that redirects is a fetch that returns nothing: the crawler spends a request learning the address it should have been given. It is also the row most often caused by something nobody considers a defect, a trailing-slash rule or an http to https upgrade applied after the sitemap generator ran. The sitemap audit guide covers the two-layer check that finds it. The apex-and-www row is the other one that hides in plain sight, and it is the defect this site carried for months with a correct canonical tag.
What this post does not claim #
It does not claim the shares above are stable; they are a reading of 111 records on one day and the live rates for the finding codes this section will emit are on the dataset page once it scores. It does not claim the count was ever wrong, because it was not. It claims that a field printed beside a correct number was wrong for a week, that it was wrong in a way no test written by a person typing URLs would find, and that the fix is a decode step at the one boundary every HTML reader has to cross.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.
The main product
Found this on your own site? We fix it for $749.
Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.
Questions this post answers
Were the crawl-waste numbers wrong?
No. The share of internal links carrying a query string is counted per link, and a link has a query string whether its parameters are split correctly or not. Only the printed parameter names were wrong, on records scanned before build 464.
Why did amp; appear in front of the names?
HTML escapes ampersands inside attributes as &. Splitting the raw attribute value on the ampersand cuts inside that escape and leaves amp; attached to every parameter after the first. Decoding the value before parsing removes it.
Were the old records corrected?
No. A stored reading describes the reader that produced it, and the corpus re-measures on a schedule, so the old names age out as sites are rescanned. Editing a past reading would make it something other than a reading.
Does crawl waste affect a grade now?
Not yet. It passed the calibration gate on 16 September 2026 and will carry weight in the next score-version bump, alongside two other sections that passed the same gate, so peers are re-scored once.
Related findings
Comments
Comments are read before they appear. Nothing is published automatically, and no account is needed.
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.