Skip to content
regensbot
Audit a URL freeSign in
Search requirements auditor

Regensbot checks any URL against 138 requirements from Google's documentation and Search Central Live 2026. It tells you what to fix first and cites the source of every finding.

Audit a URL freeSee how it works

Illustration: a sphere of 138 keys, one per requirement, in 16 bands by area. A scan ring passes from pole to pole and each key takes the verdict of a demo audit of example.org.

URLAudit
Demo auditexample.orgComplete138/138
Fail
09
Warn
18
Manual
26
Pass
39
Skipped
46

Works in your AI assistant

  • Claude
  • ChatGPT
  • Claude Code
  • VS Code
  • Cursor
  • MCP Inspector

From one URL to a fix list

A demo audit of shop.example in five scenes. An assistant is asked to audit the URL. Regensbot fetches the page the way a crawler does: the HTML, response headers, robots.txt, the sitemap, canonicals, hreflang, JSON-LD and images. The 138 requirements in 16 areas resolve into verdicts: 66 are decided from one URL, and the other 72 name the source they need, such as a verified site, a crawl or server logs. One finding opens with its evidence, its fix and its sources. The report ends with a fix list, MUST failures first.

The film

Demo audit · shop.example

  1. (01) Ask

    Paste one URL into the assistant you already use.

  2. (02) Fetch

    Regensbot reads the page the way a crawler does.

  3. (03) Measure

    66 decided from one URL. The other 72 name what they need.

  4. (04) Cite

    Every finding shows its evidence, its fix and its source.

  5. (05) Report

    Then a fix list, MUST failures first.

Watch the filmMP4 · 12 s · no sound(opens in a new tab)
The 138

138 requirements. Sixteen areas.

One tile per requirement, one column per area. Every requirement has a level, a test and the sources it rests on.

Colour the tiles by
  1. SRV, Server, status codes and crawling, 11 requirements
    1. DEV-SRV-01, Must: Let verified Google crawlers through firewalls, CDNs and bot protection
    2. DEV-SRV-02, Avoid: Never serve bot challenges or error pages to crawlers with a 200 status
    3. DEV-SRV-03, Must: Answer planned maintenance and short outages with 503, for a day or two at most
    4. DEV-SRV-04, Must: Keep robots.txt reachable on every host: 200 with rules, or 404 if there are none
    5. DEV-SRV-05, Must: Rely only on the fields Google supports (user-agent, allow, disallow, sitemap) and keep robots.txt under 500 KiB
    6. DEV-SRV-06, Avoid: Do not put Content-Signal or other non-standard lines between user-agent lines
    7. DEV-SRV-07, Must: Answer crawlers over HTTP/1.1 (HTTP/2 optional); never run a crawlable host on HTTP/3 only
    8. DEV-SRV-08, Should: Support conditional requests with ETag or Last-Modified and answer 304 when nothing changed
    9. DEV-SRV-09, Avoid: Do not answer crawlers with 401, 402 or 403 on pages that should be in Search
    10. DEV-SRV-10, Must: Give a crawler its own robots.txt group only when needed, and make that group complete
    11. DEV-SRV-11, Avoid: Never use robots.txt to hide private paths; protect them with authentication
  2. URL, URLs, links and discovery, 11 requirements
    1. DEV-URL-01, Must: Make every navigational link an <a> element whose href holds a real URL
    2. DEV-URL-02, Avoid: Do not navigate with onclick handlers, javascript: URLs, routerLink without href or # pseudo-links
    3. DEV-URL-03, Must: Route single-page apps with the History API and real paths, not # fragments
    4. DEV-URL-04, Must: Link every indexable page from the normal navigation or a hub page
    5. DEV-URL-05, Should: Publish XML sitemaps listing only canonical, indexable URLs with accurate lastmod
    6. DEV-URL-06, Must: Give each page of a paginated series its own URL, its own canonical and an <a href> to the next page
    7. DEV-URL-07, Must: Back infinite scroll and load-more buttons with paginated URLs
    8. DEV-URL-08, Must: Keep faceted navigation out of the crawl with robots.txt rules or URL fragments
    9. DEV-URL-09, Should: If facet URLs must be crawlable, use & separators, a fixed filter order and 404 for empty results
    10. DEV-URL-10, Should: Group URLs into meaningful section paths and launch new content under sections Google already indexes well
    11. DEV-URL-11, Should: Compute the expected URL for every request and redirect variants to it
  3. REN, Rendering and JavaScript, 10 requirements
    1. DEV-REN-01, Should: Server-render the main content and everything indexing depends on (SSR, static generation or hybrid)
    2. DEV-REN-02, Must: Have all indexable content in the DOM after load, without clicks, typing or scrolling
    3. DEV-REN-03, Must: Lazy-load with native lazy loading or an IntersectionObserver, never with scroll events
    4. DEV-REN-04, Avoid: Do not block JavaScript, CSS or API endpoints that pages need for rendering in robots.txt
    5. DEV-REN-05, Avoid: Do not add, change or remove robots meta tags with JavaScript
    6. DEV-REN-06, Should: Make rendering robust: no slow API dependencies and no unresolved placeholders
    7. DEV-REN-07, Should: Keep prices, offer counts and other commercial data identical in raw and rendered HTML
    8. DEV-REN-08, Should: Feature-detect permission-based APIs and WebGL, and render the content without them
    9. DEV-REN-09, Should: Monitor JavaScript console errors and Content Security Policy violations on key templates
    10. DEV-REN-10, Should: Keep indexable content out of iframes, and check web components in the rendered HTML
  4. IDX, Indexing and snippet controls, 13 requirements
    1. DEV-IDX-01, Must: Use noindex to keep a page out of Search, and leave that URL crawlable
    2. DEV-IDX-02, Avoid: Do not use noindex, nofollow or crawl-delay to save crawl budget
    3. DEV-IDX-03, Should: Send robots rules for PDFs, images and other non-HTML files in the X-Robots-Tag header
    4. DEV-IDX-04, Should: Allow full snippets and large previews with max-snippet:-1 and max-image-preview:large
    5. DEV-IDX-05, Avoid: Do not add nosnippet or a short max-snippet unless you accept losing snippets and AI feature use
    6. DEV-IDX-06, Should: Prefer rel attributes on individual links to a page-level nofollow
    7. DEV-IDX-07, May: Use data-nosnippet on a span, div or section to keep one detail out of snippets
    8. DEV-IDX-08, May: Use unavailable_after on pages with a known end date
    9. DEV-IDX-09, Should: Leave notranslate and noimageindex out of templates unless translation or image indexing must be prevented
    10. DEV-IDX-10, May: Use the Search generative AI setting in Search Console only to take a property out of AI Overviews and AI Mode
    11. DEV-IDX-11, May: Use the Google-Extended robots.txt token to control Gemini training and grounding
    12. DEV-IDX-12, Should: On sites with explicit content, keep it on its own subdomain or domain and label it with rating markup
    13. DEV-IDX-13, Should: For an urgent removal, use the Removals tool in Search Console and also return 404 or noindex
  5. CAN, Canonicals, redirects and duplicates, 11 requirements
    1. DEV-CAN-01, Must: Use permanent server-side redirects (301 or 308) for moved URLs, straight to the final URL
    2. DEV-CAN-02, Must: Serve one host over HTTPS with a valid certificate and redirect every other origin to it
    3. DEV-CAN-03, Must: Put exactly one absolute rel=canonical in the server-rendered head of every indexable page
    4. DEV-CAN-04, Must: Point every canonical directly at a final URL that returns 200, is indexable and is linked
    5. DEV-CAN-05, Must: Make all canonical signals agree: redirects, rel=canonical, internal links, sitemaps and hreflang
    6. DEV-CAN-06, Avoid: Do not canonicalise one language version to another; connect them with hreflang
    7. DEV-CAN-07, Avoid: Never leave staging, preview or mirror copies of the site publicly crawlable
    8. DEV-CAN-08, Should: Make pages that share a URL pattern differ in their main content
    9. DEV-CAN-09, Should: Keep migration redirects in place long term and judge a move in Search Console, not with site: queries
    10. DEV-CAN-10, Must: Redirect an old URL only to a page with the same intent, and return 404 or 410 when there is none
    11. DEV-CAN-11, Avoid: Never route a crawlable URL's redirects through a URL that robots.txt blocks
  6. ERR, Error pages and soft 404s, 4 requirements
    1. DEV-ERR-01, Must: Return 404 or 410 for removed and non-existent URLs
    2. DEV-ERR-02, Must: Return a real 404 for unknown routes in single-page apps, or use a documented client-side fallback
    3. DEV-ERR-03, Avoid: Never serve error states, empty results or failed data loads with a 200 status
    4. DEV-ERR-04, Should: Keep temporarily out-of-stock product pages live with 200 and their current availability
  7. INT, International and multilingual sites, 12 requirements
    1. DEV-INT-01, Must: Give every language and country version its own URL
    2. DEV-INT-02, Avoid: Do not redirect visitors automatically by IP address or browser language
    3. DEV-INT-03, Must: Make hreflang complete: a self-reference, return links and fully qualified URLs
    4. DEV-INT-04, Must: Use valid hreflang codes: an ISO 639-1 language, an optional ISO 15924 script and an optional ISO 3166-1 Alpha-2 region
    5. DEV-INT-05, Should: Supply hreflang through one method only: HTML head, HTTP Link header or sitemap
    6. DEV-INT-06, Must: Build language and market selectors as <a href> links to each alternate URL
    7. DEV-INT-07, Should: Make each page's language unambiguous by translating the template with the main content
    8. DEV-INT-08, Should: Differentiate same-language country versions beyond boilerplate and mark them with region codes
    9. DEV-INT-09, May: Choose ccTLDs, subdomains or subdirectories by business needs, and never URL parameters
    10. DEV-INT-10, Should: Publish machine-translated language versions only after human review and localisation
    11. DEV-INT-11, Should: Write pages in the words, spellings and script the audience searches with, and never add synonym or variant lists
    12. DEV-INT-12, Should: Mark the text direction of right-to-left and mixed-script titles, product names and URLs
  8. HTM, Page structure and HTML, 7 requirements
    1. DEV-HTM-01, Should: Wrap each page's primary content in one clearly delimited main area
    2. DEV-HTM-02, Should: Place the words a page should rank for in its main content, not in footers or sidebars
    3. DEV-HTM-03, Must: Give every indexable page a unique, descriptive title element in the server HTML
    4. DEV-HTM-04, Should: Use semantic, accessible HTML: real buttons, labelled forms and a logical heading order
    5. DEV-HTM-05, Should: Write valid HTML and close every element
    6. DEV-HTM-06, Avoid: Never hide text from users, such as white-on-white or off-screen keyword blocks
    7. DEV-HTM-07, May: Use real heading, title and emphasis elements instead of styling alone
  9. SDA, Structured data, 15 requirements
    1. DEV-SDA-01, Should: Write structured data as JSON-LD by default
    2. DEV-SDA-02, Must: Mark up only content that is visible on the page and relevant to it
    3. DEV-SDA-03, Should: Choose the specific types Google documents for its features, and skip generic or irrelevant ones
    4. DEV-SDA-04, Should: Identify entities with unique identifiers: url, @id and stable IDs
    5. DEV-SDA-05, Should: Write dates in ISO 8601 and give every date-time a UTC offset
    6. DEV-SDA-06, Should: Emit each structured data entity once per page, and audit CMS plug-ins for duplicates
    7. DEV-SDA-07, Should: Describe only the page's main product in Product markup, not related-product carousels
    8. DEV-SDA-08, Should: Mark up merchant listings completely, with validity dates for sale prices
    9. DEV-SDA-09, Should: Declare return, shipping and loyalty policies once at organisation level
    10. DEV-SDA-10, Should: Put the same structured data on duplicate URLs as on the canonical
    11. DEV-SDA-11, Must: Validate markup in the Rich Results Test before it reaches templates, and monitor it after release
    12. DEV-SDA-12, May: Wire Google's SHACL validation rules into the build once they are published
    13. DEV-SDA-13, Should: Add Article markup with headline, images, dates and authors to every article template
    14. DEV-SDA-14, Avoid: Do not mark up self-serving review ratings of your own business
    15. DEV-SDA-15, Should: State the preferred site name with WebSite markup on the home page
  10. SHP, Shopping data (Merchant Center, product markup and Storebot), 4 requirements
    1. DEV-SHP-01, Should: Use Product markup for rich results and a Merchant Center feed for the Shopping tab, with identical values
    2. DEV-SHP-02, Should: Let Storebot-Google crawl product, cart and checkout pages, through robots.txt and bot protection
    3. DEV-SHP-03, Should: Send conversational product data in the Merchant Center feed: Q&A, product details, highlights and related products
    4. DEV-SHP-04, May: Treat product Q&A and specification markup in schema.org as an extra on top of the feed
  11. IMG, Images, 8 requirements
    1. DEV-IMG-01, Must: Put every image that should be found in an <img> element with a src attribute
    2. DEV-IMG-02, Must: Describe every meaningful image in its alt attribute
    3. DEV-IMG-03, Should: Place images next to text that explains them
    4. DEV-IMG-04, Should: List important images in an image sitemap
    5. DEV-IMG-05, Should: Serve modern, compact image formats with a widely supported file in the img src
    6. DEV-IMG-06, Should: Keep images out of Search with robots.txt or X-Robots-Tag, not with CSS tricks
    7. DEV-IMG-07, Should: Give every article a large, relevant lead image and declare it in og:image or markup
    8. DEV-IMG-08, May: Keep the IPTC and C2PA metadata that marks AI-generated images
  12. VID, Video, 6 requirements
    1. DEV-VID-01, Must: Embed each video in a video, iframe, embed or object element that loads without user action
    2. DEV-VID-02, Should: Give each important video its own watch page
    3. DEV-VID-03, Should: Describe videos with VideoObject markup and mark key moments with Clip or SeekToAction
    4. DEV-VID-04, Should: List videos in a video sitemap
    5. DEV-VID-05, May: Allow video previews with max-video-preview:-1
    6. DEV-VID-06, Should: Serve videos fast in a common container with standard codecs, and never block the files
  13. PRF, Performance and server capacity, 4 requirements
    1. DEV-PRF-01, Should: Keep connect time and time to first byte low and stable under crawler load
    2. DEV-PRF-02, Should: Make JavaScript-generated content render quickly
    3. DEV-PRF-03, May: Load per-session-billed third-party tools only after a user interaction
    4. DEV-PRF-04, Should: Keep each HTML response well under 2 MB and put the main content and JSON-LD early
  14. AIF, AI features (AI Overviews, AI Mode, Gemini), 6 requirements
    1. DEV-AIF-01, Must: Keep pages indexable and snippet-eligible, the whole technical requirement for AI features
    2. DEV-AIF-02, Should: Spend no effort on llms.txt, AI text files or AI-specific markup for Google
    3. DEV-AIF-03, Should: Structure content for readers instead of splitting it into small chunks for AI
    4. DEV-AIF-04, Should: Do not block the AI agents you want as visitors
    5. DEV-AIF-05, May: Set robots.txt policy per AI crawler by its own token, and know that user-triggered fetchers ignore it
    6. DEV-AIF-06, May: Try WebMCP to declare the actions a site offers to AI agents
  15. SPM, Spam policies and AI-generated content, 5 requirements
    1. DEV-SPM-01, Avoid: Never manipulate browser history so that Back does not return users to where they came from
    2. DEV-SPM-02, Avoid: Do not generate large sets of low-value pages from templates, feeds or LLM output
    3. DEV-SPM-03, Avoid: Never serve Googlebot different content from users, and do not build doorway pages
    4. DEV-SPM-04, Must: Keep the CMS and plug-ins patched and watch for injected pages and links
    5. DEV-SPM-05, Should: Publish AI-generated text, images and markup only after human review, and show only real authors
  16. MON, Testing and monitoring, 11 requirements
    1. DEV-MON-01, Must: Verify every production host in Search Console before launch
    2. DEV-MON-02, Must: Render every template in a headless browser before release and check it in URL Inspection right after
    3. DEV-MON-03, Should: Watch the Page indexing report and treat its not-indexed reasons as a work list
    4. DEV-MON-04, Should: Monitor Crawl stats and server logs for verified Googlebot traffic
    5. DEV-MON-05, Should: Run recurring rendering checks: raw versus rendered HTML, placeholders and console errors
    6. DEV-MON-06, Should: Audit canonical groups with a crawler on a schedule
    7. DEV-MON-07, May: Track AI feature visibility in the Generative AI performance report
    8. DEV-MON-08, Should: Set up the Search Console bulk data export to BigQuery on large sites
    9. DEV-MON-09, May: Add the brand's YouTube, Instagram, TikTok and X accounts to Search Console as platform properties
    10. DEV-MON-10, Should: Plan releases and fixes around Google's processing times, and judge results only after them
    11. DEV-MON-11, Should: Measure the time from publishing a URL to Googlebot's first crawl of it

Hover, focus or tap a tile to read it. Open it for the why, the how and the test.

Arrow keys move between tiles. Enter opens the requirement.

The knowledge base behind the 138

requirements
138
areas
16
MUST requirements
37
claims in the knowledge base
2,228
Google documents cited
128

Pack v2.13.0Data through 2026-10-02Search Central Live Deep Dive Europe 2026

Browse all 138
Eight verdicts

It never guesses.

When one URL cannot decide, Regensbot says so, and says what it needs.

Every audit returns one finding for each of the 138 requirements. Each finding carries exactly one of eight verdicts.

Report order

Findings are sorted by verdict, fail and warn first. MUST and AVOID come first.

Fail
failClear evidence the requirement is broken.
Warn
warnA likely problem, or a SHOULD-level miss.
Pending confirmation
pending_confirmationRegensbot gathered the evidence and proposes a verdict. A person on your team confirms it.
Error
errorThe check could not run.
Manual
manualIt applies, but one URL cannot decide it.
Pass
passThe requirement is met.
Not applicable
not_applicableThe requirement does not apply to this page.
Skipped
skippedIt needs more than one URL can show. The finding names the source to connect.

How the 138 are covered

138covered

105 automatic, 29 assisted, 4 guided. Each one has a state, a guide and an evidence path.

A single URL decides 66 and says for the rest what it needs. The full split needs your sources connected: a verified site, a crawl, renders in your plan, Search Console, server logs and the CI action. Without one, the requirements that depend on it are guided.

What you connect
  • 105AutomaticRegensbot decides pass, fail or warn from data it fetches or you connect.
  • 29AssistedRegensbot gathers the evidence and proposes a verdict. A person confirms it.
  • 4GuidedRegensbot walks a person through a check in a tool it cannot read. Attested is never shown as pass.
Anatomy

Anatomy of a finding.

One requirement, six layers. Every finding brings its evidence, the test, the fix and the sources it rests on.

  1. Verdict, level, ID

    One of 8 verdicts, the requirement's level and its ID. The report sorts by these.

    FailMUSTDocumentedDEV-CAN-03

    Put exactly one absolute rel=canonical in the server-rendered head of every indexable page

    CAN · Canonicals, redirects and duplicates

  2. Evidence observed

    What the audit saw on this URL: status, headers, tags, values. No verdict without it.

    Evidence observedDemo data
    final_url
    https://shop.example/shoes
    status
    200 · text/html
    canonical
    headhttps://shop.example/shoes
    canonical
    head/shoes?sort=price

    2 different canonicals are declared; Google will likely ignore all of them.

  3. The test

    The check you can run yourself, so you never take a verdict on trust.

    Test

    A crawl finds no indexable page with zero or several canonicals, or with a relative or placeholder value; raw and rendered HTML carry the same canonical; URL Inspection shows the user-declared and Google-selected canonical as equal on key templates.

  4. How to fix

    What to change, taken straight from the requirement.

    How to fix

    Give every indexable page a self-referencing canonical, and point duplicates (tracking parameters, print views, sort orders) at the preferred URL. Use absolute URLs on the chosen origin. …

  5. Claims

    The statements behind it, each with a cite string: ID, session, how it was said, verification.

    Claims · 8
    • D2-C032How is HTML interpreted · shown on screen · confirmed
    • D2-C418Lightning session E: Managing Duplicates and Site Moves · Google's documentation · source
    • D2-C417Lightning session E: Managing Duplicates and Site Moves · said on stage · consistent

    +5 more

  6. Google pages

    The documentation the requirement rests on, by title and publisher.

DEV-CAN-03Read the requirement in full
Three ways in

Three ways in. One core.

The CLI, the agent and the MCP server run the same auditor against the same 138 requirements, with the same citations. Pick the one that fits how you work.

terminal — regensbot audit

Demo data

$ regensbot audit https://example.com/

# Regensbot audit: https://example.com/

Pack v2.13.0, data through 2026-10-02. 138 findings, one per requirement.

fail 3  · warn 7  · pending_confirmation 0  · error 0  · manual 26  · pass 48  · not_applicable 8  · skipped 46

## fail · MUST · DEV-ERR-01 Return 404 or 410 for removed and non-existent URLs

- Status: documented

- Evidence: GET /regensbot-probe-7f3a answered 200 with "Page not found" in <main>

- Fix: Answer unknown paths, deleted items without a close replacement and invalid parameters with 404 or 410 and a helpful error page (search box, main categories).

- Cites: [D1-C073, docs, Google, https://developers.google.com/crawling/docs/troubleshooting/http-status-codes]

## fail · MUST · DEV-CAN-03 Put exactly one absolute rel=canonical in the server-rendered head of every indexable page

- Evidence: 2 rel=canonical in <head>: https://example.com/ and https://example.com/?ref=home

- Cites: [D2-C418, docs, Google, https://developers.google.com/search/blog/2013/04/5-common-mistakes-with-relcanonical]

## warn · SHOULD · DEV-IDX-04 Allow full snippets and large previews with max-snippet:-1 and max-image-preview:large

- Evidence: robots meta is "index, follow"; no max-image-preview

- Cites: [D2-C086, docs, Google, https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag]

## manual · MUST · DEV-SDA-02 Mark up only content that is visible on the page and relevant to it

- Test: For each template, the Rich Results Test output matches what the page visibly shows, and the Manual actions report in Search Console is empty.

… 134 more findings

… 135 more findings

Six clients. One URL.

Clients with MCP sign-in need only the URL: you sign in, choose an organisation and allow the connection. Every other client sends an API key from the dashboard. Both work at the same time.

https://app.regensbot.de/mcp
Step-by-step setup

25 MCP tools in 6 groups

Each audit with audit_url counts against your plan.

Audit05

Run an audit and read its findings.

  • 01audit_url
  • 02get_audit
  • 03get_finding
  • 04list_recent_audits
  • 05get_usage

Knowledge base05

Look up requirements, claims and their evidence.

  • 06get_requirement
  • 07list_requirements
  • 08search_knowledge_base
  • 09get_claims
  • 10get_claim_evidence

Sites and checklist06

Your verified sites, their checklist and their evidence.

  • 11list_sites
  • 12get_site
  • 13get_checklist
  • 14get_check_guide
  • 15get_coverage
  • 16request_upload_link

Workflows05

Drills, removals, site moves and re-checks after a fix.

  • 17start_maintenance_drill
  • 18open_removal_incident
  • 19register_migration
  • 20mark_fixed
  • 21get_job

Crawl03

Crawl a verified site and read its site-level findings.

  • 22start_site_crawl
  • 23get_crawl_status
  • 24get_site_findings

Server logs01

Verified crawler traffic from your server logs.

  • 25get_crawler_traffic
Every tool, explained
What you connect

From one URL to all 138.

One URL decides 66 of the 138 requirements. Each source you connect decides more: verify your site, crawl it, render it, connect Google and your server logs, and run the GitHub Action on your releases.

  • Automatic

    Regensbot decides pass, fail or warn from data it fetches or you connect.

  • Assisted

    Regensbot gathers the evidence and proposes a verdict. A person confirms it.

  • Guided

    Regensbot walks a person through a check in a tool it cannot read. Attested is never shown as pass.

  • Says what it needs

    One URL cannot decide these. The finding names the source to connect.

Coverage of the 138 requirements

  1. Audit a URL

    Step 0: One URL

    HTTP · HTML · robots.txt · sitemaps · PageSpeed

    An audit reads the response, the headers, the HTML, robots.txt, the sitemaps, the structured data and llms.txt, and adds PageSpeed Insights.

    It decides 66 of the 138. For each of the others, the finding says which source it needs and links to that setup step.

    • 66 automatic
    • 72 name what they need
  2. Verify your site

    Step 1: Your verified site

    Verification · checklist · evidence · workflows

    Verify the site by a DNS TXT record, a meta tag or a file, or through Search Console.

    From here all 138 are covered: each one has a state, a guide, an evidence upload and reminders before it is due.

    Workflows run maintenance drills, urgent removals and site moves, and re-check after each fix.

    • 66 automatic
    • 13 assisted
    • 59 guided
  3. Start a crawl

    Step 2: Site crawl and Claude as judge

    Crawler · assistant judge · CMS version

    A polite crawl, sitemap first, finds orphans, canonical clusters and near-duplicates.

    Claude judges content as an assistant: it proposes a verdict with exact quotes and never fails a page on its own.

    Regensbot detects the CMS and checks WordPress core and plug-ins against published vulnerabilities.

    • 75 automatic
    • 20 assisted
    • 43 guided
  4. Renders in your plan

    Step 3: Rendering in headless Chromium

    Isolated render service · render diff · axe

    Headless Chromium renders your templates on an isolated render service. Raw and rendered HTML run through the same parsers.

    It scrolls, clicks and tests Back like a visitor, and runs axe for accessibility.

    The largest single step: 22 more requirements become automatic.

    • 97 automatic
    • 21 assisted
    • 20 guided
  5. Connect Google

    Step 4: Google connections

    Search Console · Merchant Center · BigQuery export

    One consent screen for read-only Search Console access. Merchant Center only for shops, BigQuery only if you use the bulk export.

    URL Inspection samples and Search Analytics add Google's own view to crawl and render findings.

    • 101 automatic
    • 24 assisted
    • 13 guided
  6. Connect your logs

    Step 5: Server logs and verified Googlebot

    regensbot logs push · Logpush or S3 · IP and DNS checks

    regensbot logs push keeps only lines from Google's and published agents' IP ranges, so no visitor IP leaves your systems.

    Regensbot verifies Googlebot itself, by IP and DNS. Alerts fire on 5xx, 429 and robots.txt errors.

    • 105 automatic
    • 27 assisted
    • 6 guided
  7. Install the Action

    Step 6: Release pipeline

    GitHub Action · regensbot ci · release records

    A GitHub Action renders your staging templates on every release, runs the structured-data checks and axe, and fails the build on hard errors.

    Each release record schedules re-checks after Google's processing window.

    All 138 covered: 105 automatic, 29 assisted, 4 guided.

    • 105 automatic
    • 29 assisted
    • 4 guided

The full 105 automatic, 29 assisted and 4 guided needs the sources connected. Without one, the requirements that depend on it are guided, and the coverage table says which source to connect.

The 4 that stay guided: DEV-IDX-10, DEV-MON-07 and DEV-MON-09 live in Search Console screens that no API exposes; for DEV-SDA-12, a weekly watch turns it into a CI check once Google publishes structured-data validation rules.

The full 105 automatic, 29 assisted and 4 guided needs the sources connected. Without one, the requirements that depend on it are guided, and the coverage table says which source to connect.

The 4 that stay guided: DEV-IDX-10, DEV-MON-07 and DEV-MON-09 live in Search Console screens that no API exposes; for DEV-SDA-12, a weekly watch turns it into a CI check once Google publishes structured-data validation rules.

Security

Built like infrastructure.

Regensbot holds your credentials, reads the data you connect and fetches other people's websites. All of it is locked down: secrets kept only as HMACs, Search Console read-only, logs filtered on your servers, and a fetcher and a renderer that refuse private networks.

Sign-in

OAuth 2.1, with consent every time.

Assistants that support MCP sign-in open a Regensbot page: you sign in, choose an organisation and allow the connection. Consent is asked on every authorization. Every other client connects with an API key.

Consent screen, simplified · Demo data

Secrets

Stored only as HMACs.

API keys, OAuth tokens and sessions are kept only as HMACs. A key is shown once; after that Regensbot knows its hash and its last four characters. A revoked key stops working on the next request.

Keyrb_live_••••••••••••••••Yt3Q
HMAC-SHA256 · shown once
Stored9c41e07ab3d2f816…c4a19bf03e

Demo data

Passwords

Argon2id, checked against breaches.

Passwords are hashed with Argon2id and checked against known breaches with a k-anonymity range query. A password reset ends every session and every OAuth grant.

Hash
argon2id
Breach check
k-anonymity range query
Reset
ends all sessions and grants

Isolation

Your audits stay yours.

Each organisation sees only its own audits and sites: every query filters on the organisation. Every API key and every OAuth grant belongs to exactly one organisation.

Fetcher

Public addresses only.

Only http and https URLs to public addresses are fetched. A name that resolves to a private address is refused, and so is a redirect that leads to one.

Default budget per audit

120requests

120seconds

  • http · httpspublic addressfetched
  • Loopback127.0.0.0/8::1× refused
  • Private10.0.0.0/8172.16.0.0/12192.168.0.0/16fc00::/7× refused
  • Link-local169.254.0.0/16fe80::/10× refused
  • Metadata169.254.169.254× refused
  • NAT6464:ff9b::/96× refused

RegensbotBot

It says who it is.

Regensbot fetches as RegensbotBot, and the /bot page explains what it does. Checks that must see what Googlebot is served send Googlebot's user agent, and the evidence says so. A robots.txt group for RegensbotBot that disallows / opts your site out.

User agent

RegensbotBot/1.0 (+https://app.regensbot.de/bot)

app.regensbot.de/bot

Opt out · robots.txt

User-agent: RegensbotBot
Disallow: /

Politeness

Gentle with every site.

6audits of one site an hour, per organisation

30for all organisations together

A site that answers 429 or 503 is left alone, for every customer, as long as its Retry-After asks, up to an hour.

Sites and Google

Proven ownership, limited Google access.

A site is yours once a DNS TXT record, a meta tag, a file or your Search Console ownership proves it, and the proof is checked again before every recurring job. Connecting Google asks for read-only Search Console access; Merchant Center and BigQuery are requested only when you use them. Refresh tokens are sealed at rest and revoked when you disconnect.

DNS TXTmeta tagfileSearch Console

Scope webmasters.readonlytokens sealed

Rendering

A browser on its own machine.

Pages are rendered in headless Chromium on a separate render service: its own VM, with no database and none of your keys or tokens. Each render starts in a fresh browser context, and all its traffic goes through an egress proxy that checks every address, so a page cannot reach a private network either.

Machine
own VM, no database
Receives
the URL and the limits
Secrets
none
Egress
proxy, every address checked

Server logs

Visitor IPs stay with you.

regensbot logs push filters your logs on your own machine: it keeps only lines from the IP ranges that Google and AI agents publish, so no visitor IP leaves your systems. Regensbot verifies each crawler, keeps daily aggregates and deletes the raw upload once it is parsed, within 24 hours at most.

  1. 01Your serveraccess logs
  2. 02regensbot logs pushkeeps Google and agent IP ranges
  3. 03Regensbotverified crawlers, daily aggregates

Evidence

Every file, hashed.

Screenshots and exports you upload as evidence are stored with their sha256 hash and the type read from their bytes, and served only through short-lived signed links. Uploads go through a single-use link in the dashboard: file contents never travel through MCP.

sha256signed linksnever through MCP

GDPR

Export and erasure on request.

Your data is exported as JSON (Art. 15 and 20) or erased (Art. 17): keys and grants revoked, billing cancelled, deleted after 30 days. IP addresses are kept only as /24 or /48 prefixes. Audits and crawls keep their findings, not page bodies; a rendered page is kept only as evidence for a failing finding, until it is purged.

Art. 15Art. 17Art. 20/24 · /48

Billing

Payments through Stripe.

Checkout, invoices and the customer portal run on Stripe. A plan changes only after Regensbot reads the subscription back from Stripe; a returning payment page grants nothing by itself.

Company

Made in Regensburg.

A product of Ibram & Dawwa GmbH in Regensburg, Germany.

ibramdawwa.de
Pricing

Measured in audits.

Every plan runs the same audit: 138 findings, each with its source. Plans differ in how much of your site Regensbot reads for you: audits, sites, crawls, renders and monitors, and how long the history stays.

Each meter compares a limit with the largest plan.

Free

See what one audit finds on your own site.

€0 / month

No subscription

Start free
Audits a month
10
Sites
1
Pages per crawl
100
Crawls a month
1
Rendered audits a month
Not included
Monitors per site
Not included
Seats
1
History
7 days
Recommended

Pro

For anyone who audits every release.

€19 / month

Or €184 a year: 2 months free

Choose Pro
Audits a month
300
Sites
5
Pages per crawl
2,000
Crawls a month
10
Rendered audits a month
100
Monitors per site
5
Seats
1
History
90 days

Agency

For agencies running many client sites.

€99 / month

Or €890 a year: 3 months free

Choose Agency
Audits a month
2,000
Sites
50
Pages per crawl
25,000
Crawls a month
60
Rendered audits a month
1,000
Monitors per site
20
Seats
5
History
365 days

Done for you

Deep audit

Our team goes through every page, link and template of your site, under a written data agreement.

  • Signed AVV (Art. 28 GDPR) and confidentiality agreement
  • All 138 requirements, per template
  • Report and walkthrough with your team

Quote after a scoping call

Request a deep auditHow it works

Every plan: the full audit with 138 findings and their sources, the checklist for all 138 on a verified site, and all 25 MCP tools within the plan's limits.

Each meter compares a limit with the largest plan.

Prices in EUR, net of VAT.

Deep audit · done for you

Every page. Every link. By hand.

Regensbot checks your site with the sources you connect. In a deep audit, our team does the work with you: people with real access go through every page, link, template and data source, under a written data agreement signed before anyone logs in.

Request a deep audit

Quote after a scoping call

Schematic: one URL expands into the whole site, template by template, page by page and link by link, with a redirect, a canonical cluster, an hreflang pair and an orphan page marked.

Process

  1. 01

    Scoping call

    We talk through the site, its templates and markets, and the access you can grant. You get a quote for exactly that scope.

  2. 02

    Written agreement, then access

    You sign a data processing agreement and a confidentiality agreement. Only then do you grant access, read-only wherever the tool allows.

  3. 03

    Deep analysis and handover

    We go through every page and every link, apply all 138 requirements per template and hand over the report in a walkthrough with your team.

Scope

The site

  • Every page and every link: the internal link graph
  • Redirects, canonicals and hreflang clusters
  • Orphan pages no link reaches
  • Every template, raw and rendered
  • Structured data on every template

With the access you grant

  • Search Console
  • Server or CDN logs
  • Merchant Center
  • CMS or staging

Against the requirements

  • All 138 requirements, applied per template
  • Every finding with its evidence and its sources

Data agreement

Signed before anyone logs in.

Before anyone touches anything, we sign a written agreement with you: a data processing agreement under Art. 28 GDPR (AVV) and a confidentiality agreement.

It names

  1. Exactly what we access
  2. How it is stored
  3. When access ends and the data is deleted

Read-only access wherever the tool allows it.

Deliverable

One report. Every finding sourced.

A prioritized report in the format Regensbot uses: every finding carries its evidence, the fix and its sources. Then a walkthrough with your team.

Quote after a scoping call

Request a deep auditHow the deep audit works
FAQ

Questions, answered.

Short answers to what teams ask first. Each requirement page goes deeper, with the claims and Google documents behind it.

01What is Regensbot?
Regensbot checks your pages against the 138 requirements of the developer kit in the Search Central Live Deep Dive Europe 2026 knowledge base, built from Google's documentation and the event's talks. It tells you what to fix first and cites the source of every finding. Audit one URL from your terminal, ask the Claude agent, or connect your AI assistant over MCP. For a whole site, verify it and add crawls, renders, Search Console, server logs and the GitHub Action.
02Is Regensbot affiliated with Google?
No. Regensbot is an independent product of Ibram & Dawwa GmbH in Regensburg and is not affiliated with or endorsed by Google. Its requirements rest on Google's public documentation and on what was said at Search Central Live, and every finding links its sources so you can check them yourself.
03How many of the 138 does Regensbot check?
All 138, once your sources are connected. An audit of one URL returns a finding for each requirement, decides 66 from the URL alone and says for every other one what it needs. Verify your site and each of the 138 gets a state, a guide and a place for evidence. With a crawl, renders, Search Console, server logs and the CI action connected, 105 are decided automatically, 29 are assisted (Regensbot proposes a verdict, a person confirms it) and 4 are guided (a person checks a screen Regensbot cannot read and attests it). A requirement whose source is missing falls back to guided, and the coverage table names the source to connect.
04Does it work with JavaScript-heavy sites?
Yes. On a verified site, every audit also queues a render in headless Chromium on an isolated render service. audit_url answers with the findings from the server HTML and a run ID, and get_audit adds the rendered findings once the render is done. Renders come with the paid plans: 100 a month on Pro, 1,000 on Agency.
05Do I need Search Console?
No. An audit of one URL needs nothing but the URL. Connect Search Console and Regensbot reads Search Analytics, URL Inspection and your sitemaps for the site's properties, and Merchant Center for a shop. Search Console access is read-only, and Merchant Center and BigQuery are only requested when you use them.
06Which AI assistants work with it?
Claude, ChatGPT, Claude Code, VS Code, Cursor, and MCP Inspector. Other clients that speak MCP work too. Most sign in with your Regensbot account in the browser. Cursor connects with an API key from your dashboard.
07What is MCP?
The Model Context Protocol is an open standard that lets an AI assistant use tools on a server. Regensbot's server at app.regensbot.de/mcp offers 25 tools: your assistant runs audits, reads findings, looks up any requirement or claim, reads a site's checklist, starts crawls and reads verified crawler traffic.
08What happens to my data?
Each organisation sees only its own audits and sites, and the history is kept for as long as its plan says. Passwords are hashed with argon2id, API keys and tokens are stored only as HMACs, and IP addresses are shortened to a /24 or /48 prefix. Search Console access is read-only, and regensbot logs push filters your server logs before upload, so visitor IPs stay on your systems. You can ask for an export of your data or its deletion under the GDPR.
09Which languages does Regensbot speak?
The website and the app are in German and English. The requirement texts come from the knowledge base and stay in English, next to their original sources.
10What does the free plan include?
10 audits a month, up to 5 an hour and 1 at a time, 5 different sites a day, 1 API key and 7 days of audit history. It also includes 1 verified site, with 1 crawl a month of up to 100 pages, and 50 MB of evidence storage. It runs the same audit as every other plan; renders, monitors, URL Inspection calls, items judged by Claude, and log uploads come with the paid plans.
11Can your team audit the whole site by hand?
Yes. The team behind Regensbot at Ibram & Dawwa runs a manual deep audit of every page and link, with the access you grant. Before any access, we sign a written agreement: a data processing agreement under Art. 28 GDPR plus a confidentiality agreement. It names what we access, how it is stored and when it is deleted. You get a quote after a scoping call.About the deep audit
Start

A dial of 138 ticks in 16 groups, one tick per requirement and one group per area, lighting up clockwise.

Ship it
by the book.

Every URL. 138 requirements. Every finding with its source.

Audit your first URL free

Or connect Claude Code

claude mcp add --transport http regensbot https://app.regensbot.de/mcp