Malformed Fixtures
3 Intentional IssuesConfigurations that are present and structurally invalid. Where /false-positive-fixtures proves the crawler stays quiet on correct data, these prove it is reading the structure and not just looking for the right words.
Why present-and-wrong is a third case
The primary host declares no image sitemap entries and the false-positive host declares valid ones. A detector that simply searched the document for the string image:image would agree with both of them. Only a document where the markup is there and the data is not can tell the two behaviours apart, and that is every fixture on this page.
Two of the five expected results below are NOT DETECTED. Those are documented gaps in live detection logic, not fixtures that failed. They are asserted in the verification script so that the day either check is tightened, the assertion fails and the fixture is promoted rather than silently drifting.
Page fixtures
- Portland Office — invalid location markup DETECTED
/invalid-localbusiness-location#71 organization_localbusiness_schemaThree declared LocalBusiness-family schemas whose location data is missing, unstructured, or of the wrong type: no address at all, address as a plain string, and address typed Place with none of streetAddress, addressLocality or postalCode. The requested code #74 localbusiness_schema_location is retired with no emit path; #71 is what owns a declared LocalBusiness that fails validation.
- Empty referrer policy DETECTED
/invalid-meta-referrer-empty#70 referrer_policy_headerThe tag is present and its content attribute is empty. The extractor reads .attr("content")?.trim() || null, so an empty value collapses to the same null as an absent tag — an empty policy is not a policy. The requested code #22 meta_name_referrer is retired with no emit path.
- Invalid referrer policy token NOT DETECTED
/invalid-meta-referrer-token#70 referrer_policy_headercontent="no-referrer-when-downgrad" — one character short of a real token, so a browser ignores it entirely. The check is a truthiness test on the string with no token list, so it accepts it. A documented gap, asserted rather than assumed.
Site-level resources — the malformed deployment
Deliberately not linked as anchors: the crawler fetches both at the origin root, and they answer differently depending on which deployment serves them. Build and deploy this variant with npm run deploy:malformed, or run it locally with SEO_FIXTURE_VARIANT=malformed npx next start.
- /sitemap.xml (malformed deployment) DETECTED#37 image_sitemap_created
Every <image:image> block is present and carries no readable <image:loc>: one uses <image:url>, one leaves <image:loc> empty, one declares only title and caption, and one hoists <image:loc> out to be a sibling rather than a child. extractImageEntries() filters on Boolean(imageUrl), so all four are dropped and the sitemap declares zero images while being full of image markup.
- /sitemap.xml (malformed deployment) DETECTED#41 video_sitemap_created
The video entries are written as <video:videoObject>, which the video extension does not define. The selector is 'video\:video, video' and matches neither, so nothing is seen.
- /llms.txt (malformed deployment) DETECTED#309 llms_txt_coverage
The file names every page the crawl reaches — the same list the false-positive host links — but writes almost all of them as HTML <a> tags, as bare URLs in prose, and as "[Label] (url)" with a space the Markdown pattern does not allow. Three real Markdown links keep the check running; without them checkLlmsTxtQuality returns early on sameSite.length === 0 and coverage never runs at all.
Standalone documents
Two cases cannot share an origin with the fixtures above: a single videoEntries.length > 0 or imageEntries.length > 0 silences its check for the whole host. They are served as plain documents under public/and parsed directly by the verification script with the crawler's own parseSitemapXml() — the same technique verify-false-positives.mjs already uses for #42, whose detector likewise has no live emit path. They are not linked as anchors and are not paths checkXmlSitemapExistence()probes, so no scan reads either one as this site's sitemap.
/malformed-fixtures/video-empty-entry.xmlNOT DETECTED#41 video_sitemap_createdA correctly named, correctly namespaced <video:video> with none of its four required children. extractVideoEntries() returns one object per element and never filters, so it counts as a declared video and silences #41. The gap the malformed host cannot show, because putting this entry in that sitemap would silence #41 for the whole origin.
/malformed-fixtures/image-loc-only.xmlNOT DETECTED#37 image_sitemap_created<image:image> blocks declaring <image:loc> and nothing else. Title and caption are optional to Google and ungraded by the extractor, so this must validate — the guard against a check tightened past what the format actually requires.
The two requested codes that cannot be produced
meta_name_referrer (#22) and localbusiness_schema_location (#74) are both isActive: false in the API issue catalogue and have no emit path in the crawler — #22 has a comment where its check used to be, and #74 was retired when structured data stopped being reported on absence and started being reported only when a schema is declared and wrong. No fixture can make either appear.
The two page fixtures above are written against the live successors that own those conditions today: #70 for referrer policy, which reads the meta tag as well as the HTTP header, and #71 for a declared LocalBusiness that fails validation. Both retired codes are asserted ABSENT in the verification script as well, so neither page can start depending on a revival without the assertion noticing.
The other two batches
/false-positive-fixtures is the same conditions written correctly, where every expected result is silence. /crawl-audit-fixtures is the positive batch, where the condition is absent. Nothing on this page replaces anything on either of them.