Is Your Site Marketing-Hygienic?

Goal

Give the page exactly one <h1> that states what it's about, so people and crawlers get a clear entry point into the content outline.

Issue

No <h1> found on the page.

How to implement

Add exactly one <h1> near the top of the page that states what the page is about in a few words.

Resources

Goal

Keep heading levels sequential (H1 → H2 → H3) so screen readers and crawlers can build an accurate document outline.

Result

Heading levels increase in order, without skipping a level.

Goal

Mark header, nav, main, and footer regions semantically so screen readers and agents can jump straight to the right part of the page.

Issue

Missing landmark(s): header, nav, main, footer.

How to implement

Add the missing semantic element(s) — header, nav, main, footer — or the matching ARIA role (banner/navigation/main/contentinfo).

Resources

Goal

Give every <img> an alt attribute — descriptive text for meaningful images, empty alt="" for purely decorative ones.

Result

No <img> elements on the page.

Goal

Write link text that describes the destination on its own, without relying on surrounding context — screen reader users often tab through links in a list.

Result

No generic ('click here'/'read more') or empty links found.

Goal

Give every form field a visible <label> tied to it (for/id or wrapping), and make validation errors reach screen readers — native browser validation, or aria-invalid plus an error message linked with aria-describedby or an aria-live/role=alert region.

Result

No form fields found on the page.

Goal

Every action (book, buy, send, subscribe) is a real <button> or <a href> with an accessible name, so screen readers and agents can tell what will happen — a clickable <div> or an icon-only button is invisible as an action.

Result

No buttons on the page; links carry the actions.

Goal

Menus and site navigation are plain <a href> links inside <nav>, present in the server HTML, so keyboard users can Tab through them and crawlers/agents that skip JavaScript can still discover every page.

Issue

No <nav> landmark found, so navigation cannot be identified.

How to implement

Render the menu as <nav><a href="/page">…</a></nav> in the server HTML; JavaScript may enhance it (dropdowns), but every destination must exist as a plain link.

Resources

Goal

Every link, button and form control must be focusable — reachable with the Tab key — because that is also how agents find what they can act on. Controls with tabindex="-1", links without an href and javascript: links are invisible to both.

Result

No links or controls removed from the keyboard order (no negative tabindex, no href-less or javascript: links).

Goal

Click the logo, put the mouse away and press Tab: every link — including drop-down and sub-menu items — must receive visible focus in a sensible order. Then open DevTools (F12) → Accessibility and check that each button and link shows a role, a name, enabled and focusable.

Result

Manual check — the scanner reads the HTML but cannot press Tab in a real browser.

Goal

Pass an automated accessibility audit run in a real browser: Lighthouse's accessibility category (axe-core rules) should score 90+ with no failing audits. Confirm with WAVE (wave.webaim.org) — the target there is an AIM score of 9 out of 10.

Issue

Lighthouse accessibility 96/100 with 1 failing audit(s): Document does not have a main landmark. (1).

How to implement

Open the Lighthouse/PageSpeed accessibility section for this page; each failing audit lists the exact elements. Fix colour contrast, ARIA attributes, names and focus order first, then re-run.

Resources

Goal

Identify the rendering mode and keep key content server-rendered or static (SSR/SSG). Many AI/LLM crawlers never execute JavaScript, so content that only appears after hydration is invisible to them.

Issue

Only ~156 characters of visible text in the server HTML.

How to implement

Move critical content into the server-rendered/static HTML (SSR/SSG) instead of injecting it client-side.

Resources

Goal

Don't make JavaScript the only way to understand or use the page: "Load more" and infinite scroll need real pagination links, forms need a <form> with an action and a submit button, interactive content needs its HTML in the page with JavaScript only as enhancement.

Result

No JavaScript-only pagination or forms found in the server HTML.

Goal

Keep total JavaScript under 100 KB gzipped — ideally 0–50 KB (hard ceiling ~170 KB). The average site ships ~700 KB of JavaScript in ~20 requests per page; every extra KB costs load time, carbon, and agent parsing effort.

Result

~1 KB of JS (transfer size, i.e. gzipped/brotli where the server compresses) across 1 sampled file(s).

Goal

Every third-party script (tag manager, analytics, pixels, chat widgets, overlays) should earn its place: each one adds JavaScript, delays interaction, and sends visitor data elsewhere. Keep the ones you act on; remove the rest.

Result

No third-party scripts in the initial HTML.

Goal

Keep the total transferred weight of the page at or under ~270 KB for an A+ carbon rating (≤ ~530 KB still earns an A). For scale: static HTML ~0.1 MB loads in 0.3–0.8 s, a standard React app ~1.2 MB in 1.2–2.5 s, a heavy framework ~4.8 MB in 4–8 s — and conversion is about 3× higher at 1 s than at 5 s. Images are usually the biggest lever.

Result

~2 KB transferred — HTML 0 KB · CSS 0 KB · JS 1 KB · images 0 KB (0 sampled) · 2 requests referenced in the HTML (average site: ~20).

Goal

The server should start answering within ~800 ms (Google's "good" TTFB; ≤ 600 ms is better) and deliver the whole HTML well within the 1–5 seconds AI crawlers wait before giving up. Slow hosting, no page cache or a heavy theme/plugin stack delays everything after it — for visitors and crawlers alike.

Result

The page's HTML started arriving after ~13 ms (best of two requests from our server on a warm connection); the complete HTML took ~64 ms on a cold connection, the way a crawler meets it (AI crawlers time out after 1–5 s).

Goal

Serve HTML, CSS and JavaScript compressed (Brotli or gzip). It typically cuts text transfer by 70–80 % at no cost — what optimisation plugins call "zip".

Result

2/2 text resources served compressed (HTML: br).

Goal

Every page builder and every plugin that loads its own CSS/JS adds a layer between your content and the reader. Clean up before you add: fewer plugins, a light theme, no builder where the block editor or plain HTML will do.

Result

No page builder detected; not a WordPress page.

Goal

Pass Google's Core Web Vitals on mobile: Largest Contentful Paint ≤ 2.5 s, Interaction to Next Paint ≤ 200 ms (lab stand-in: Total Blocking Time ≤ 200 ms), Cumulative Layout Shift ≤ 0.1.

Result

LCP 1.2 s (field), INP 88 ms (field), CLS 0.000 (field) · Lighthouse performance 100/100. Source: Google PageSpeed Insights (mobile); "field" = real Chrome users, "lab" = one Lighthouse run.

Goal

JavaScript that loads but never runs on this page is pure cost. Lighthouse's "Reduce unused JavaScript" audit measures it; the target is under 50 KB of unused JavaScript (and under 100 KB of JavaScript in total).

Result

~0 KB of JavaScript could be removed according to Lighthouse (counts every script loaded during the run, including ones other scripts load later — so it can exceed the JS weight sampled from the HTML above).

Goal

Describe the page's main entity (who you are, what you offer) as JSON-LD so search engines and AI agents can read it as structured facts, not prose to interpret.

Issue

No <script type="application/ld+json"> found on the page.

How to implement

Add a JSON-LD block describing the page's main entity — Organization for a company, LocalBusiness if you have a physical location/service area, plus Product/Service/FAQPage/Article where relevant.

Resources

Goal

Keep every JSON-LD block syntactically valid — a single stray comma invalidates the whole block.

Result

All JSON-LD blocks are valid JSON.

Goal

Use a well-known schema.org @type (Organization, LocalBusiness, Product, Service, Article, FAQPage, etc.) so search engines and agents recognize what kind of thing this page describes.

Result

Found:

How to implement

Change or add a block whose @type is a standard schema.org entity relevant to the page, rather than a custom/unrecognized type.

Goal

Keep a single, consistent Organization/LocalBusiness record so crawlers and AI agents don't get contradictory facts about who you are.

Result

Organization/LocalBusiness data is consistent.

Goal

Every structured-data object on the page passes the official Schema Markup Validator (validator.schema.org) with no errors or warnings: valid types, valid property names, valid values.

Result

validator.schema.org did not answer during this scan (not scored) — open the validator with the link below.

Goal

Give each page structured data for a type Google can show as a rich result (Article, Product, FAQ, Breadcrumb, Local business, Event, Recipe, Video, Software app…) with the properties it requires. FAQ results are shown only for some sites in Google, but the markup still helps AI answers.

Issue

No structured data for a rich-result type (Article, Product, FAQ, Breadcrumb, Local business, Event…) on this page.

How to implement

Add the JSON-LD type that matches the page (Article for posts, Product for products, LocalBusiness/Service pages, FAQPage for Q&A, BreadcrumbList everywhere) with its required properties, and test it in Google's Rich Results Test.

Resources

Goal

Say who stands behind the page in a form machines can read — a Person/Organization in JSON-LD with a name and a url/email/sameAs, an author/publisher property, a <meta name="author">, or a rel="author" link. Claims without a named, reachable author get mentioned, not cited.

Issue

No machine-readable author or operator identity found (no Person/Organization JSON-LD with contact details, no author/publisher property, no meta author, no rel="author" link).

How to implement

Add a Person or Organization block (name + url, and sameAs links to your official profiles) to the page's JSON-LD, and reference it as author/publisher on Article/WebPage blocks.

Resources

Goal

Keep content current and say so: show when it was published or last updated (e.g. "Updated September 2026 · Author: Name") in a form machines can read (datePublished/dateModified in JSON-LD, a <time datetime> element, or article:modified_time), so agents can tell current content from stale content.

Issue

No publish or last-updated date found in JSON-LD, <time datetime>, or meta tags.

How to implement

Add dateModified (and datePublished) to the page's JSON-LD and show the same date visibly in a <time datetime="YYYY-MM-DD"> element.

Resources

Goal

Give every page a descriptive <title>, a meta description, a canonical URL, the page language, a viewport tag and Open Graph title/image — the metadata search engines, AI crawlers and link previews read first.

Issue

Metadata gaps: title is 14 characters (aim for 15–70); no meta description; no canonical link; no og:title/og:image for link previews.

How to implement

Fill the missing tags in the page template (most SEO plugins and frameworks expose all of them).

Resources

Goal

Show proof that you did the work: link an author/about page and case studies, references or client examples (with dates) from your pages. "We offer the best deal in town" — can you prove it? Without proof you get mentioned, not cited.

Issue

No link to an author/about page or case studies, references or client examples found on this page.

How to implement

Create (or link) an author page with your experience and profiles, and a case-study/references page with dated, specific client results; link both from the navigation or footer and from authority pages.

Resources

Goal

Ask honestly for each authority page: if this page did not exist, would it matter? It should only exist if its content exists only here. If it is a rewrite of what 16 other sites say, rethink it — AI crawlers look for the single best, unique answer.

Result

Manual check — uniqueness of content can't be judged by a scanner.

Goal

Serve every page over HTTPS, redirect http:// to https://, and load no images, scripts or styles over plain http — browsers, search engines and AI systems treat insecure pages as less trustworthy.

Issue

http:// does not redirect to https://.

How to implement

Install a TLS certificate (free with Let's Encrypt or your host/CDN), add a permanent 301 redirect from http:// to https://, and change every http:// resource URL to https:// (or a relative URL).

Resources

Goal

Every link on the page leads somewhere: broken links waste crawl budget, break agents' paths through your site and signal neglected content.

Result

No links to test.

Goal

Publish a robots.txt file so crawlers know what they may fetch before they fetch anything else.

Issue

No robots.txt found at https://example.com/robots.txt (status 404).

How to implement

Add a robots.txt file at the root of your domain (served at /robots.txt) with at least a default allow rule and a pointer to your sitemap.

Resources

Goal

Give crawlers a complete, structured list of your URLs instead of making them discover pages by following links alone.

Issue

No sitemap found via robots.txt or /sitemap.xml.

How to implement

Generate an XML sitemap listing your important pages, serve it at /sitemap.xml, and reference it from robots.txt.

Resources

Goal

Decide intentionally whether GPTBot, PerplexityBot, ClaudeBot, and similar AI crawlers can access your content, instead of leaving them on the default catch-all rule.

Issue

robots.txt states no AI policy: no named rules for AI/LLM crawlers and no Content-Signal line — they fall back to the default User-agent: * block.

How to implement

Add a named User-agent block for each AI crawler you want to allow or block, rather than relying on the wildcard block to cover them.

Resources

Goal

Search engines and AI crawlers may only use pages that are indexable: HTTP 200, no noindex in a robots meta tag or X-Robots-Tag header, and a canonical that points to the page itself.

Result

HTTP 200, no noindex, and the canonical (if any) points to this URL.

Goal

robots.txt must not block the crawlers that fetch pages for search and for users' questions (Googlebot, Bingbot, OAI-SearchBot, ChatGPT-User, PerplexityBot, Claude-SearchBot/User…). Blocking AI training crawlers is a legitimate policy choice; blocking search and assistant crawlers makes you invisible in AI answers.

Result

No search or assistant crawler is blocked from the site root. No training crawler is blocked either.

Goal

When robots.txt allows them, AI crawlers (GPTBot, ClaudeBot, PerplexityBot) must actually get the same page as a visitor, within the 1–5 seconds they wait — no firewall block, no challenge page, no empty shell.

Result

Requests identifying as GPTBot (12 ms), ClaudeBot (13 ms), PerplexityBot (10 ms) got the full page.

Goal

State a machine-readable policy on whether your content may be used for search indexing, AI-agent answers, and AI model training — separately.

Issue

No Content-Signal directive found — no stated policy on AI training vs. search vs. AI-input use of your content.

How to implement

Add a Content-Signal line to robots.txt stating your policy for search, ai-input, and ai-train separately.

Resources

Goal

Offer a short, curated Markdown index of your most important pages so LLMs and agents don't have to guess which pages matter.

Issue

No llms.txt found at the site root.

How to implement

Publish a llms.txt file at the site root: an H1 with your site/brand name, a one-paragraph summary, then a 'Key pages' list of Markdown links to your top pages.

Resources

Goal

Offer a clean Markdown version of the page — what AI agents prefer to read — at least for your top five authority pages: a <link rel="alternate" type="text/markdown">, content negotiation on Accept: text/markdown, or a .md twin.

Issue

No Markdown version of this page found (no rel=alternate link, no Accept: text/markdown negotiation, no .md twin).

How to implement

Generate a Markdown version of the page's main content (headings, copy, links; no navigation, scripts or ads) and link it with <link rel="alternate" type="text/markdown" href="…">. On WordPress a free markdown plugin can do this for every page; on Cloudflare, "Markdown for Agents" serves it via content negotiation.

Resources

Goal

Clear, extractable content gets you cited when people ask AI to compare and shortlist: what you offer, what it costs, answers to common questions (FAQs) and how to contact or book you — reachable straight from the navigation or on the page.

Issue

No navigation links found in the server HTML.

How to implement

Add plain navigation links to your services/products, your prices (or how pricing works) and your contact or booking page.

Resources

Goal

Structure content so each section covers one idea, answers its question early and is understandable on its own — that is good writing first, and it lets search and AI systems match a section to a question. Use subheadings, short paragraphs and lists; avoid "as mentioned above"; don't split text artificially. There is no ideal chunk size: a chunk ends where a thought is complete.

Result

Only ~25 words of main content — too little to judge structure.

Goal

Once a month, ask the main AI platforms (ChatGPT, Gemini, Claude, Perplexity, Copilot) the questions your clients ask. Check whether you are mentioned and cited, in an incognito window and logged in. If someone else is cited, study why and do a better job than they do.

Result

Manual check — the scanner can't see AI answers. Pair it with the vanish test and proof-of-work checks.

Goal

Estimate CO₂ per page view with the Sustainable Web Design model v4 and keep it at or below 0.095 g (A+); 0.186 g (A) is acceptable. The global median is about 0.36 g.

Result

~0.000 g CO₂/view (rating A+), estimated from ~2 KB transferred (HTML + sampled CSS/JS/images), Sustainable Web Design v4, green hosting applied. websitecarbon.com's calculator did not answer during this scan (HTTP 403).

Goal

Serve images compressed and at their display size, in WebP or AVIF, and lazy-load the ones below the fold. Images are usually the biggest lever on page weight and carbon.

Result

No images on the page.

Goal

Serve static assets with long cache lifetimes (Cache-Control max-age ≥ 1 day, ideally immutable) from a CDN close to the visitor, so repeat views and far-away visitors cost almost nothing.

Issue

Only 0/1 sampled CSS/JS/image files are cacheable for a day or more.

How to implement

Put the site behind a CDN (Cloudflare's free plan, or your host's built-in edge) and set Cache-Control: public, max-age=31536000, immutable on versioned CSS/JS/image files.

Resources

Goal

Host on infrastructure that runs on renewable energy or is verified green (The Green Web Foundation directory). It lowers the data-centre share of every page view's footprint.

Result

example.com is served by verified green hosting (Cloudflare).

Goal

Optional: publish an agent manifest at /.well-known/ (ai-agent.json pointing agents to your critical pages, or ai-plugin.json describing a callable API with name, description, auth and OpenAPI spec location).

Issue

No /.well-known/ai-agent.json or ai-plugin.json manifest found (optional, early-stage convention).

How to implement

If you expose an API agents could call on your behalf (booking, ordering, lookups), publish a manifest at /.well-known/ai-plugin.json describing the endpoint, auth, and an OpenAPI spec.

Goal

Publish a /.well-known/security.txt (RFC 9116) with a contact method — a small, standard trust signal that you're a real, reachable operator.

Issue

No /.well-known/security.txt found.

How to implement

Add a short security.txt with at least a Contact: line (email or URL).