False-Positive Fixtures

0 Intentional Issues

Conditions that look like findings and are not. Every code on this page must come back NOT DETECTED; anything else is the crawler reporting a defect that does not exist.

Expect zero findings from this batch

Every other fixture on this site exists to make a finding appear. These exist to prove the crawler stays quiet when the condition it looks for is not actually a problem. Nothing here replaces an existing fixture — the positive cases for all nine codes are untouched, on /head-tag-gaps, /structured-data-valid, /media-library, /status-404 and the primary host's /llms.txt.

Four of the nine codes are isActive: falsein the API issue catalogue and emit nothing whatever a page does. That does not make their fixtures pointless: the values are still extracted into the crawler payload, so these pages define exactly what a reactivated check would read. It does mean a scan alone cannot distinguish "correctly silent" from "switched off", which is why the verification script exercises the detector functions directly.

Page-level fixtures (this host)

Valid Sitemap Link
/fp-link-rel-sitemap
#25 link_rel_sitemap — NOT DETECTED
Three <link rel="sitemap"> tags in one head: type=application/xml, type=text/xml, and no type at all. All three hrefs resolve to the real /sitemap.xml.
The retired check demanded type="application/xml" exactly, so the equally valid text/xml and the omitted attribute were reported as wrong on sites that had done nothing wrong.
Article With an Author Tag
/fp-meta-author
#20 meta_name_author — NOT DETECTED
An article page whose <meta name="author"> holds a real personal name that matches the visible byline. No markup in the value, no placeholder, no list.
The retired check reported the tag's ABSENCE. This is the harder direction: the tag is present and ordinary, so a content check has something it could still get wrong.
Valid Referrer Policy
/fp-meta-referrer
#22 meta_name_referrer — NOT DETECTED
<meta name="referrer" content="strict-origin-when-cross-origin"> — the token the specification recommends — declared once, in one place.
This was half of a double count: one correctly configured policy used to be reported here AND by #70 referrer_policy_header. Both must now be silent, which is what this page checks.
Austin Office
/fp-localbusiness-location
#74 localbusiness_schema_location — NOT DETECTED
A location page carrying an <address>, a telephone number and an opening-hours table — every prose signal the retired heuristic fired on — plus a complete, valid LocalBusiness JSON-LD block.
The retired check fired on body TEXT and guessed the page had forgotten its markup. The markup is there and it validates, so #71 organization_localbusiness_schema must stay silent too.
Product Reviews
/fp-product-review-fields
#154 product_schema_review_fields — NOT DETECTED
Four Products that each declare both aggregateRating and review: plain JSON-LD, one with no offers, an @graph whose review is an @id reference, and Microdata.
The check is opt-in, so this page only proves something on a scan with productReviewFields on. The positive control is /structured-data-valid, whose Product has offers and no rating or review.
Retired URLs Handled Correctly
/fp-moved-deleted-return
#42 moved_deleted_return — NOT DETECTED
/fp-retired-guide answers 301 to /fp-retired-guide-2026; /fp-legacy-still-live answers 200. The findings are 404/410 and TEMPORARY redirects — neither of these.
A live scan cannot prove this: the crawler passes historicalUrls: [], so the check returns early for every site. verify-false-positives.mjs calls the detector directly with these two URLs instead.

Site-level fixtures (the false-positive deployment)

These three read one file per origin, so their false-positive case cannot share a hostname with their positive case. Deploy with npm run deploy:false-positive and scan seo-test-site-false-positive.<subdomain>.workers.dev.

/sitemap.xml (false-positive deployment)
#37 image_sitemap_created — NOT DETECTED
The sitemap declares eight <image:image> entries for the files /media-library renders, each with a loc, a title and a caption.
The crawl still finds twelve images, so the check APPLIES and is not merely skipped. Only the sitemap side of the condition moves, which is what makes this a false-positive test.
/sitemap.xml (false-positive deployment)
#41 video_sitemap_created — NOT DETECTED
One <video:video> entry with thumbnail_loc, title, description, content_loc and an integer duration, for the <video> on /media-library.
Same shape as #37. The video embed is still there and still counted; it is simply declared now.
/llms.txt (false-positive deployment)
#309 llms_txt_coverage — NOT DETECTED
A well-formed llms.txt — an H1 title, a summary, ## sections — listing every page the crawl reaches, so compareCoverage() returns missingCount 0.
#309 fires when any crawled page is absent from the file and at least five pages were crawled. A complete index leaves it nothing to report, and #307 and #308 stay silent on that host as well.

How to verify

node scripts/verify-fixtures/verify-false-positives.mjs runs the real crawler modules against the local build and fails if any of these nine codes appears — #154 with its opt-in turned on, since it is off by default. It also asserts the positive fixtures on the primary host are still intact, because the cheapest way to make a false-positive test pass is to delete the condition it is testing.

The same codes, written the awkward way

Every fixture above declares its condition the OBVIOUS correct way. Real sites often do not — a sitemap behind an index, an llms.txt in the bare-URL dialect, a referrer policy in a CDN header, one @graph from a plugin — and each of those is a different path through the detector. /fp-edge-fixtures reproduces five of these codes in those forms. It adds cases; it replaces none of the ones on this page.

And again, the way a CMS writes them

Both batches above still describe a site whose sitemap is one tree at one conventional path and whose structured data comes from one generator. A site running a CMS, a media plugin and a theme has a media sitemap that only robots.txt announces, two index levels above the entries; a generated llms.txt with link titles, nested sub-lists and tables; and two JSON-LD blocks that do not know about each other. /fp-cms-fixtures reproduces four of these codes in those forms. It adds cases too; it replaces none of the ones on this page or on /fp-edge-fixtures.

And once more, in the bytes an internationalised site actually serves

All three batches above vary the shape of the document tree, and none of them varies the encoding: every sitemap is LF-terminated ASCII starting with <, every llms.txt is LF-terminated ASCII starting with #, and every media URL is an unescaped same-origin path. A site generated on Windows, serving localised URLs and hosting its media on a CDN, is in none of those states — and a UTF-8 byte-order mark is the cheapest way there is to make a valid file unreadable to a check that anchors at the start of it. /fp-intl-fixtures reproduces the same four codes with a BOM, CRLF endings, a stylesheet processing instruction, hreflang siblings between the media entries, an embed-only video, a Markdown-mirror llms.txt and a store locator whose businesses are two property hops down inside an ItemList. It adds cases too; it replaces none of the ones on this page, on /fp-edge-fixtures or on /fp-cms-fixtures.

Head and URL checks

Three live codes no batch above touches: a title the parser has to find (#56 missing_title_tag), a Search Console verification it has to recognise (#34 meta_name_google) and a canonical hostname it has to resolve (#9 www_vs_non). /fp-head-url-fixtures writes each in the forms minifiers, tag managers, legacy themes and load balancers produce. No new deployment is needed.

Other hubs

/fp-edge-fixtures (the edge-case false positives), /fp-cms-fixtures (the CMS-shaped false positives), /fp-intl-fixtures (the internationalised false positives), /crawl-audit-fixtures (third batch), /audit-fixtures (second batch) and /orphan-audit (orphan-page fixtures).