Re-audit workbook: siteimprove.com, the AEO Checker and the SEO Checker

Every Bing and MSN variant now returns 200 on both the homepage and /robots.txt. The RFC 9309 §2.3.1.3 consequence described in v1 — a 4xx on robots.txt read as "do not crawl" — no longer applies. ChatGPT and Copilot can reach the origin.

Yandex and Baidu remain blocked at the Cloudflare edge. The 403 carries Cloudflare's block-page signature rather than an origin response, so this is a WAF rule, not application logic. Commercially this is close to immaterial for a US/EU enterprise buyer, but it is worth knowing the rule is selective rather than removed wholesale — someone narrowed it rather than deleting it.

The served file is ten lines: a sitemap declaration and nine Disallow rules, all of which target UTM, gclid and fbclid parameter strings under User-agent: *. There is no AI-crawler section at all.

User-agent: *
Sitemap: https://www.siteimprove.com/sitemap.xml
Disallow: /*?utm_campaign=*Image*Editing*Aviary*
Disallow: /*?utm_source=*jobalert.ie*
Disallow: /*?utm_adgroup=*Software*AG*Exact*
Disallow: /*?utm_keyword=*pandadoc*
Disallow: /*?utm_   ·   /*&utm_   ·   /*?gclid=   ·   /*&gclid=   ·   /*?fbclid=

Functionally this is permissive, which is the right outcome. But three of those rules are campaign-specific artefacts — an Aviary image-editing campaign, an Irish job-alert source, a PandaDoc keyword — that read as accumulated debris rather than policy. For a vendor whose own free tool parses customers' robots.txt for AI-crawler directives, publishing a file with no AI-crawler section and four stale campaign rules is a missed opportunity to model the practice.

945 of the sitemap's 948 entries are on www.siteimprove.com. Of those, 758 were also reached by crawling links from the homepage. The remaining 187 exist in the sitemap but were not reached by following links from the homepage at default crawl settings.

Precision note (revised): the first draft called these "orphaned." That overstates what the crawl proves. "Not reached in a homepage-seeded crawl" is the exact claim — some of the 187 may be reachable through deep pagination the crawl did not exhaust (blog and press archives especially) rather than truly unlinked. Either way the practical consequence holds: they sit far from the homepage in the link graph and receive little internal authority. Confirming true orphans would need a log-file or full-pagination pass.

// sitemap ∩ crawl
sitemap <loc> total            948   (3 entries point at jp.siteimprove.com — cross-host)
in sitemap AND crawled          758
in sitemap, NOT crawled         187   ← no internal link path
crawled, NOT in sitemap         177

// the 187, by section
/blog                75      /hello               9
/press               61      /events              4
/de                  30      /on-demand-webinars  2
                             /toolkit             2

Pages this far from the homepage receive little internal authority, rank weakly, and are correspondingly less likely to surface as citations. The 61 press releases in this set matter specifically for the entity-freshness argument in v1 §05 — the April launch coverage is exactly the material that should be re-anchoring the brand entity, and it is poorly linked from the site's core.

The toolkit is the top-of-funnel lead engine and the AEO Checker is its flagship. The AEO Checker is correctly listed. Almost nothing else is.

// EN toolkit URLs missing from sitemap.xml
/toolkit/                                  ← the hub itself
/toolkit/seo-checker/
/toolkit/accessibility-checker/
/toolkit/color-contrast-checker/
/toolkit/ada-compliance-checker/          ← also meta robots: noindex
/toolkit/accessibility-statement-generator/
/toolkit/aeo-checker/                      ← present

// meanwhile, German equivalents ARE listed
/de/toolkit/ · /de/toolkit/accessibility-checker/ · /de/toolkit/seo-checker/
/de/toolkit/color-contrast-checker/ · /de/toolkit/accessibility-statement-generator/

/toolkit/ada-compliance-checker/ carries meta robots: noindex while a near-duplicate at /glossary/ada-compliance-checker/ is indexable and holds the stronger title ("Instant ADA Compliance Website Checker — Free WCAG 2.0 Test"). That may be deliberate consolidation onto the glossary URL. Combined with six sitemap omissions and the German pages being listed where the English are not, it reads more like drift than a decision — worth a five-minute confirmation with whoever owns the sitemap generator.

This is the v2 llms.txt observation with its actual rule identified. My first pass called this "dotted filenames"; that was wrong, and a wider probe set gives the real boundary. Two specific shapes return 200 OK on a missing resource. Every other shape 404s correctly.

// error handling by URL shape — 15 probes, browser UA, redirects followed
                                    first  final   bytes
/nonexistent-page-zzz/               404    404   593,457   correct
/nonexistent-zzz.json                301    404   593,457   correct
/nonexistent-zzz.xml / .yaml / .md   301    404   593,457   correct
/openapi.json                        301    404   593,457   correct

/llms.txt                            301    200       795   soft 404
/ai.txt · /nonexistent-zzz.txt       301    200       795   soft 404
/.well-known/agent-skills/           301    200       795   soft 404
/.well-known/mcp/manifest.json       301    200       795   soft 404
/.well-known/openid-configuration    301    200       795   soft 404
/.well-known/oauth-authorization-server  301  200   795   soft 404
/.well-known/security.txt            301    200       795   soft 404
/.well-known/zzz-does-not-exist      301    200       795   soft 404

// the 795-byte body served with 200 OK
<title>Resource Not Found</title>
<h1 class="fiendly-error-header">Resource Not Found</h1>   [sic]
<link rel="stylesheet" href="/Util/styles/errorpage.css">   Optimizely/Episerver stub

So the rule is not "extensions". It is the .txt extension plus the whole /.well-known/ prefix — the two namespaces that exist specifically so machines can discover capabilities. .json, .xml, .yaml and .md all behave correctly, which is why this survived earlier passes.

The consequence is not theoretical, and F-18 documents it happening. Any agent or scanner probing /.well-known/ for OAuth metadata, an MCP manifest, agent skills or security.txt receives 200 OK and an HTML page — the signature of a capability that exists. A security researcher looking for a disclosure contact at /.well-known/security.txt gets the same false positive.

Three fixes, in order: make /Util/Errors/Error404/ return a real 404 status; stop rewriting .txt and /.well-known/ requests into it; then publish an actual llms.txt. On that last point — there is still no evidence major AI vendors read llms.txt, and the v1 argument for shipping it was brand credibility rather than algorithmic lift. That argument has strengthened: an AEO vendor serving a fake 200 across the entire agent-discovery namespace is a worse look than serving nothing.

Unchanged across all three audits. /platform/seo/aeo-visibility/ carries only the template's WebSite/SearchAction: no Organization, no SoftwareApplication, no Product, no FAQPage. It runs 525 words of body copy and five H2s, no H3s.

Ahrefs measures it at 2 organic keywords and roughly 71 estimated monthly visits, none in the top three positions — against 6,435 keywords and 167,169 visits site-wide. The page carrying the entire category argument accounts for about 0.04% of organic traffic.

The fix is unusually cheap because the patterns already exist in the codebase: SoftwareApplication ships on /platform/, and FAQPage ships on three sibling pages. Neither requires new engineering.

Severity note (revised): downgraded from critical to warning. The page indexes and is reachable — it is significantly hampered, not broken, which is what "warning" means under this audit's rubric. Its strategic importance is high; its indexability severity is not critical, and the first draft conflated the two.

/toolkit/aeo-checker/ and /toolkit/seo-checker/ carry no FAQPage markup — yet both pages already contain question-shaped H3s written as FAQ content:

// seo-checker H3s — already FAQ-shaped, unmarked
"Why you should use an SEO Checker"
"What exactly does the Siteimprove SEO Checker do?"
"How to read your Siteimprove SEO Website Checker report"
"What to optimize with your SEO site checker"
"How to monitor SEO progress"

// aeo-checker H3s
"Do you have visibility into how AI engines perceive your brand?"
"Your existing SEO tools aren't built for this."

The content is written. The markup pattern is deployed two directories away. This is a content-entry task measured in hours.

The homepage Organization block is the single most machine-readable statement of what this company is. It is what feeds Google's Knowledge Graph and what an agent parses first for entity resolution. Here it is in full:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Siteimprove",
  "description": "Siteimprove's all-in-one platform amplifies digital marketing,
                  so you can maximize your reach and provide and an exceptional,
                  inclusive digital experience.",                    ← [sic]
  "url": "https://www.siteimprove.com",
  "sameAs": [ linkedin · wikipedia · facebook · twitter ]
}
no logo · no address · no contactPoint · no foundingDate · no SoftwareApplication link

Two problems, and the first is the more important one. The description is the old positioning. "All-in-one platform amplifies digital marketing" is not Agentic Content Intelligence, is not AEO, and is not the Siteimprove.ai unified platform. The v1 audit found the brand's stale identity anchored in model training data and correctly called that slow to shift. This is the same stale identity — but in a field they control, that they can change this afternoon, and that Google reads directly.

Second, the description contains a grammatical error — "provide and an exceptional" — shipped in structured data on the homepage of a content-quality vendor.

Rewriting this one string is the cheapest positioning fix available anywhere in this audit. Adding logo, address and contactPoint alongside it takes the same edit from a correction to a genuine entity upgrade.

Search engines discard hreflang annotations that are not mutually confirmed. A third of annotated URLs fail that test.

// hreflang issues, Screaming Frog issue analysis
Missing Return Links          346 URLs   (36.97%)   HIGH
Missing X-Default             887 URLs   (94.76%)
Noindex Return Links           49 URLs    (5.24%)   HIGH
Non-200 hreflang URLs           8 URLs    (0.85%)   HIGH

// the asymmetry, confirmed by hand
https://www.siteimprove.com/      hreflang: none declared   canonical: self
https://www.siteimprove.com/de/   hreflang: en, de          canonical: absent

The German homepage points at the English one; the English one declares no alternates at all, so the pair never confirms. The German page additionally ships no canonical tag while its English counterpart does — two different template behaviours for the same page type.

This compounds with the sitemap findings: the sitemap lists German toolkit pages the English equivalents are missing from, and includes three jp.siteimprove.com URLs in a sitemap hosted on www. The international configuration looks like it has been edited by several hands without a single owner.

Severity note (revised): downgraded from critical to warning. Non-reciprocal hreflang is discarded by search engines, which fall back to normal per-URL ranking — pages still index and rank, they just lose the locale-targeting benefit. Under this audit's rubric that is "indexes but hampered," not "cannot index / indexed wrong." Real, worth fixing, not critical.

Server response is fast and compression is on; the problem is what is being compressed.

// page weight, 936 pages
median HTML          613,123 B      mean 608,265 B      max 998,544 B
pages over 500 KB    932 of 936  (99.6%)
median bytes of HTML per word of content   525

// homepage composition (non-overlapping)
served decompressed        753,760 B      on the wire (gzip)   199,328 B
  inline <script>          356,750 B  (47.3%)
  inline <style>           286,590 B  (38.0%)   across 11 separate blocks
  plain markup + text      108,638 B  (14.4%)
  <link rel=stylesheet>    0          <script src>   0

// timing, 3 runs
ttfb 0.33 / 0.37 / 0.37 s      total 0.41 / 0.45 / 0.46 s

Every page ships its CSS and JS inline, so nothing is cached across navigations — a visitor moving through five pages downloads roughly 640 KB of identical CSS and JS five times. This is a transfer, caching and CWV problem (it compounds with the absent cache headers in F-10), and it is what the independent scan's "18% content ratio" flag is pointing at.

Scope note (revised): the first draft also framed this as an AI-retrieval problem. That is not well supported and has been dropped — the same independent scan found the homepage's extracted text fits an agent context budget at about 1K tokens, so a crawler recovers the content cleanly regardless of the raw byte weight. The weight hurts human page-load and caching, not machine reading.

// homepage response headers, browser UA
Strict-Transport-Security: max-age=63072000; includeSubDomains
X-Frame-Options: SAMEORIGIN      X-Content-Type-Options: nosniff
Content-Security-Policy: present (very long, see F-13)
Content-Encoding: gzip
Access-Control-Allow-Origin: *      ← on an HTML document
Request-Context: appId=cid-v1:76b77375-…   ← Azure App Insights app id
cf-cache-status: DYNAMIC
Cache-Control: absent   ETag: absent   Last-Modified: absent
Referrer-Policy: absent   Permissions-Policy: absent
Vary: absent

// site-wide
Missing Secure Referrer-Policy Header    3,280 URLs  (89.9%)
HTTP (non-HTTPS) URLs                    1
Protocol-Relative Resource Links         77

No Cache-Control, ETag or Last-Modified on HTML means cf-cache-status: DYNAMIC on every request and no conditional revalidation — every fetch, including every crawler fetch, hits origin. Access-Control-Allow-Origin: * on HTML documents is unusual and worth a deliberate confirmation rather than an assumption.

This is the most serious defect found in either tool, and it is new to this pass.

$ POST …/api/Aeo/CheckAiAccessibility
  {"domain":"this-domain-does-not-exist-9f3k2.com"}

result.status      "blocked"        ← identical verdict to a real WAF block
result.hasSitemap  true             ← for a domain with no DNS record
result.robots      all engines allowed ← robots.txt "permits" ChatGPT
result.error       null

diagnostics.userAgentChecks[*]
  status        null
  errorCode     "ENOTFOUND"
  errorMessage  "fetch failed"   ← the truth is captured, then discarded

The service knows the lookup failed and records it in diagnostics. The user-facing result throws that away and renders three false statements: that the site blocks AI crawlers, that it publishes a sitemap, and that its robots.txt admits every engine. A failed fetch is being treated as a negative result rather than as an absent result.

The failure mode matters commercially. A prospect who mistypes their domain — the single most common input error a free tool receives — is shown an alarming "blocked" verdict on a vendor's own instrument. That is a false positive generated by the tool of a company selling measurement trustworthiness in AI search.

Fix shape: propagate ENOTFOUND into result.error, introduce a fourth status (unreachable) distinct from blocked, and suppress the robots and hasSitemap assertions whenever the underlying fetch did not succeed.

The page markets "Core Web Vitals" scoring. The runtime predates the current set.

// LhAudits payload, decoded
lighthouseVersion   9.6.8
formFactor          mobile
emulated device     Moto G4          ← 2016 handset; Lighthouse moved to Moto G Power
categories          performance · accessibility · best-practices · seo · pwa
                                                          ↑ PWA category removed in Lighthouse 12
audits returned     18

// Core Web Vitals coverage
largest-contentful-paint            present
cumulative-layout-shift             present
first-contentful-paint              present
total-blocking-time                 present
interaction-to-next-paint           ABSENT
experimental-interaction-to-next-paint  ABSENT
max-potential-fid                   ABSENT

INP replaced FID as an official Core Web Vital in March 2024. This build emits no INP audit under either its stable or experimental key. A tool sold on SEO authority is therefore scoring "Core Web Vitals" while measuring a superseded set — and still reporting a PWA score Google has retired. Upgrading the Lighthouse runtime is the whole fix.

Within the same page: "The Siteimprove SEO checker crawls your site at scale" and "Run a single-page audit" / "baseline a single page or a key template". The API confirms the latter — one requestedUrl, one result. It also promises an "Action list with suggested owners (SEO, Content, Engineering)", which no field in the response supports.

The at-scale language belongs to the paid platform. Carrying it on the free tool's page sets an expectation the free tool cannot meet, which is the same seam as the AEO Checker, just narrower.

Two facts the peer set makes unavoidable, both of which correct the first draft of this section:

• Siteimprove is the most-cited accessibility vendor in the set — 3,419 total, versus 722 for Level Access and 430 for Deque. Nearly 3× its two closest competitors combined. The v1 audit's "structurally absent / 4% own-domain share" framing, which this workbook initially carried forward in spirit, is not supported by this pass's data.
• ChatGPT and Copilot are thin for Siteimprove — and for every accessibility vendor here. Copilot: Siteimprove 2, Deque 1, Level Access 4. ChatGPT: 32, 12, 4. The SEO-tooling brands, by contrast, post thousands on the same two engines (Copilot 3,271 and 1,328). Deque and Level Access were never Bing-blocked, so their equally-thin Bing-fed numbers cannot be a WAF-recovery artefact. The first draft's claim that "the gap is too large to be lag alone" had no peer baseline behind it and is withdrawn.

The defensible reading: the Bing-fed engines are an open category race where content volume and authority win, and no accessibility vendor has yet accumulated either at SEO-publisher scale. That is an opportunity framed correctly — an authority gap against the category, not a lingering access defect specific to Siteimprove.

Ranked by shared keywords, the nearest organic competitors are SEO tooling and SEO publishing, not accessibility governance.

// organic competitors, US, ranked by keyword overlap
semrush.com                2,171 common kw    3,685,655 traffic   DR 92
hubspot.com                  980              1,910,471           DR 93
ahrefs.com                   813              4,105,955           DR 91
moz.com                      645                560,505           DR 91
mtu.edu                      621                389,501           DR 81
aioseo.com                   616                 95,684           DR 83
neilpatel.com                608                346,882           DR 91
searchengineland.com         563                105,656           DR 91
digitalmarketinginstitute     520                153,293           DR 85
rankmath.com                 430                 77,554           DR 88
debugbear.com                336                 50,591           DR 76
conductor.com                245                122,087           DR 84
ada.gov                      213                187,096           DR 91

absent from the top 15: Level Access · Deque · AudioEye · accessiBe
                        UserWay · Silktide · Monsido/Acquia · TPGi

Caveat on the metric. Keyword-overlap competitors are, by construction, whoever ranks for similar terms — so a site whose traffic is SEO-education content will surface SEO publishers, and accessibility vendors (who publish little such content) would not appear regardless of how directly they compete commercially. So this table is not, by itself, evidence of a strategy error. It is evidence of where the traffic is, which is the load-bearing fact.

Three consequences follow from that fact. First, the content engine competes for these queries against firms with twenty to forty times its organic traffic. Second, generic SEO-education queries are the class most exposed to answer-engine substitution, so this traffic is the most cannibalisable on the site. Third — and now confirmed rather than inferred — F-20 shows ~85% of Siteimprove's AI citations come from Google AI Overviews pulling exactly this content. So the company's AI-citation lead over its accessibility peers rests on the pages least connected to what it sells and most likely to be answered without a click. The presence is real; its durability is the open question.

This is a positioning decision for the CMO, not an SEO task, and — because of the metric caveat above — it is the one finding in this workbook whose framing I would put to that conversation before acting on it.

Three separate measurement systems fail on the company's flagship lead-generation page, all with the same cause: hosts allow-listed in script-src but omitted from connect-src.

// console errors, /toolkit/aeo-checker/
BLOCKED stats.g.doubleclick.net/g/collect      GA4 measurement
BLOCKED bat.bing.net/actionp/0                 Microsoft Ads / Bing UET
BLOCKED j.clarity.ms/collect            (×3)   Microsoft Clarity

// the mismatch
script-src allows  bat.bing.com · www.clarity.ms · scripts.clarity.ms
connect-src allows googleads.g.doubleclick.net · region1.analytics.google.com
connect-src omits  bat.bing.net · j.clarity.ms · stats.g.doubleclick.net

The scripts load, then cannot transmit. Conversion and behaviour data for this page is therefore under-reported by an unknown margin — which means any decision made about the AEO Checker's performance is being made on incomplete data. Three hostnames added to connect-src resolves it.

Severity note (revised): downgraded from critical to warning. This is a measurement-data-loss bug with real business cost, but it does not affect indexability, retrieval, or user-facing correctness, so it does not meet this audit's critical bar. It is the highest-value warning in the hygiene section, and the "unknown margin" is a genuine limit — I can prove the requests are blocked, not how many conversions that hides.

// uncaught errors, /toolkit/aeo-checker/
TypeError: Cannot destructure property 'computePosition' of
           'window.FloatingUIDOM' as it is undefined.     at page:121
TypeError: Cannot set properties of null (setting 'id')   at page:2353

// debug statements shipped to production
console.log("not handling click")     homepage nav handler, with the comment
                                       "testing to not offset menu while working on new nav"
console.log("seo checkId: " + n.id)   checkerbundle.js — logs an internal GUID
console.log("Setscore Success:", n)

// other
HubSpot forms embed script included twice on the same page
Geologica-Bold.ttf preloaded but unused  — uncompressed font format, wasted on LCP path
11 duplicate DOM ids on /toolkit/seo-checker/, including id="checker-form" ×2

The duplicate ids deserve a line of their own: the SEO Checker page renders its form twice, producing eleven repeated id values. Duplicate ids break label[for] and ARIA references. On an accessibility vendor's own site, that is the kind of finding their own product would raise.

The two checkers submit to different systems entirely.

// AEO Checker  HubSpot embedded form, EU hublet, portal 146950224
// SEO Checker  Pardot form handler  hello.siteimprove.com/l/550552/2021-11-23/379tnmz
                 via marketingservices.siteimprove.com/Checker/SubmitForm/

Three issues follow from the legacy path in checker-form.js:

• The qualification gate is front-end only. The script blocks gmail.com and nineteen role prefixes (info, sales, support…) in JavaScript. The server-side validator disagrees: GET /api/utility/isMailValid/?email=info@… returns true. Anyone bypassing the page bypasses the gate.
• Lead capture fails silently. The AJAX error handler is literally error: function (data) { // TODO } followed by the same redirect as the success path. If the Pardot submission fails, the user sees their result and the lead is lost with no signal to anyone.
• The lead's email travels in a URL. Submission redirects to /toolkit/seo-checker/result/?website=…&email=… and the result page then calls GrabSeoNextgenResults/?url=…&email=…. Email addresses in query strings land in browser history, CDN logs and server access logs. The result page is correctly noindex, so this is not an indexing exposure — but for a company selling digital governance in an EU-first posture it is a data-handling pattern worth moving to a POST body.

Minor, but worth noting alongside: the public script carries a developer's name and email in its header comment, and the query parameter is misspelled reffererurl throughout.

This is the business consequence of F-05, caught in the wild rather than argued in principle.

The scanner probed the /.well-known/ namespace, received 200 OK on every path, and recorded three capabilities as present. All three are the same 795-byte "Resource Not Found" stub.

// what the scan reported
OAuth 2.0 support              Passed
  "OpenID Connect discovery endpoint found at https://siteimprove.com"
Agent instruction / when-to-use  Partial (67%)
  "Agent instruction file at /.well-known/agent-skills/ but no explicit
   when-to-use guidance"
MCP server / manifest            Partial (33%)
  "MCP endpoint found at /.well-known/mcp/manifest.json but response is
   not valid JSON"

// what is actually served at all three
HTTP 200 OK · text/html · 795 bytes · <title>Resource Not Found</title>

// control
/.well-known/zzz-does-not-exist  →  200 OK · 795 bytes  identical response

Siteimprove publishes no OpenID Connect discovery document, no agent-skills file and no MCP manifest. The scanner's "response is not valid JSON" note is it half-detecting its own false positive: the response is not valid JSON because it is an HTML error page.

Two things follow. The 61/100 is inflated — remove the false credit and it drops. And more consequentially: this is now a demonstrated pattern of an automated evaluator forming a wrong model of Siteimprove's capabilities directly from a server misconfiguration. Every agent, scanner and buyer-side evaluation tool probing that namespace will reach the same wrong conclusions, in either direction. For a company selling AI-visibility measurement, being systematically mis-measured by its own infrastructure is the finding to lead the remediation with.