CMS-Shaped False-Positive Fixtures
The same four issue codes as the two batches before it, declared the way a CMS with a media plugin and a theme declares them. Every one of them must come back NOT DETECTED.
Why a third batch
The plain batch declares each condition the obvious way and the edge-case batch declares it the awkward-but-valid way. Both 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 is not in that shape. Its media sitemap is a second root that only robots.txt announces, two index levels above the entries; its llms.txt is generated with link titles, nested sub-lists and tables; its JSON-LD arrives as two blocks that do not know about each other. Each of those is equally correct and each is a different code path.
Nothing here replaces anything. The fixtures in both earlier batches are untouched and still assert what they always did. If any code below is reported, the defect is in the scanner, not on this site — the fixture stays as it is and the finding is recorded as a false positive.
Page-level fixture (this host)
- Service Centres
/fp-cms-localbusiness-branches#74 localbusiness_schema_location — NOT DETECTED- Earlier batches
- /fp-localbusiness-location declares one LocalBusiness in one script; /fp-edge-localbusiness-graph declares two branches in one @graph.
- This batch
- TWO script blocks — a theme block and a plugin block — the second a bare top-level array. The same Organization is emitted by both, in agreement. Each service centre is typed ["Store","LocalBusiness"] with the subtype first, carries an address ARRAY of two complete PostalAddress objects (one typed as a one-element array), points at the publisher declared in the other block, and nests a returns counter as a department. The logo's width and height are strings with units.
- Why a detector could get it wrong
- A reader that took parsed['@type'] off an array block, counted Organization declarations instead of comparing them, resolved @id references within one script tag, searched the @type array for the literal "LocalBusiness", read address.streetAddress off an array, compared @type with === , or required numeric logo dimensions would report a page that is correct on every count.
Site-level fixtures (the fp-cms deployment)
These three read one resource per origin, so they need a host of their own — the same reason the two earlier batches have one each. Deploy with npm run deploy:fp-cms and scan seo-test-site-fp-cms.<subdomain>.workers.dev. Locally: SEO_FIXTURE_VARIANT=fp-cms npx next start -p 3981.
- #37 image_sitemap_created — NOT DETECTED
/media/seo-sitemap-media-1.xml and -2.xml, two index levels down- What is declared
- The media sitemap is a second root announced only by robots.txt, at /media/seo-sitemap-index.xml, which names a media INDEX, which names the two urlsets that carry the entries. One <image:loc> is CDATA with a raw '&', one image is on a cdn. host, one entry has its children in a non-canonical order, and both files repeat the same page <loc>.
- Why a detector could get it wrong
- The first candidate that answers on this host is /sitemap.xml — a valid pages-only urlset containing the string <image:image> exactly zero times. A check that read the sitemap it discovered first, or that followed one index level, sees no images and reports a site that has declared all of them.
- #41 video_sitemap_created — NOT DETECTED
the same two child files- What is declared
- Two videos. The first is declared with <video:player_loc> and NO <video:content_loc> — the extension asks for one of the two, and an embed-only video has no file URL. The second sits on a <url> that also carries images, and its <video:duration> is wrapped across indented lines.
- Why a detector could get it wrong
- A check requiring <video:content_loc>, or one that treated a media file as image-only, or one that read <video:duration> without trimming, drops a correctly declared video.
- #309 llms_txt_coverage — NOT DETECTED
/llms.txt- What is declared
- Complete, in the layouts a generated index uses: Markdown links carrying a title attribute, a nested sub-list, two links on one line, and a table under an '###' sub-heading. One page is listed twice — once with an upper-case host and a trailing slash. Two URLs must NOT be counted: one inside an indented '~~~' fence and one in prose.
- Why a detector could get it wrong
- A link pattern that stopped at the first quote reads the URL as 'url "Tooltip"'; an anchored '^- ' drops every indented child; a match where a matchAll belongs loses the second link on a line; a list-items-only reader never sees the table. Any one of them reports a listed page as missing.
Verifying it
npm run build npx next start -p 3977 # primary SEO_FIXTURE_VARIANT=fp-cms npx next start -p 3981 # this batch's host cd /d/xeopix-bundle/apps/crawler # so bare imports resolve node D:/seo-issue/scripts/verify-fixtures/verify-fp-cms-cases.mjs
A scan cannot be pointed at a local build — the crawler's assertPublicUrl refuses a localhost origin — so the script feeds the bytes this build serves into the real crawler modules: the same createPageContext, the same PAGE_LEVEL_GROUPS, the same fetchSitemapUrls, analyzeSitemap and checkLlmsTxtQuality.