OnPage.dev inside your AI assistant.

A 0 to 100 score for one page, the issues to fix first with why and how, AI readiness and the key facts: title, description, headings, words, speed and structured data. Client-side apps are scanned as rendered.

Up to 25 pages from the sitemap, or from the home page links when there is none, worked through step by step. Finds issues across the site, broken, orphan and duplicate pages, and powers link equity, internal links and edge rules.

Scans the next pages of a running audit on every call, so a whole site fits a free service. When it is complete you get the issues by code with the pages they affect, plus the average score.

Everything OnPage.dev measures on one page, by section: speed hints from the HTML, links and anchor texts, accessibility basics, image SEO, rich results and security headers. Use it when scan_page is not detailed enough.

Which AI crawlers may read the page per robots.txt (GPTBot, ClaudeBot, PerplexityBot, Google-Extended and more), whether llms.txt exists, 15 checks for being quoted in AI answers, and the page as a model reads it.

Takes the clicks, positions and revenue from your Search Console, GA4, Ahrefs or Semrush and ranks every fix by the traffic it can win. Also explains a drop: pass last period's clicks and decaying pages come first.

Your page next to up to 3 competitors that rank for the same search: score, AI readiness, words, headings, rich results and speed side by side, the facts only they give, and the fixes to catch up.

With citation counts from Ahrefs Brand Radar or a similar tool, scans the pages ChatGPT, Perplexity and Google AI cite and the ones they skip, and shows which checks the cited pages pass that yours do not.

Eight checks for one search term: title, meta description, H1, URL, the first 100 words, subheadings, image alt texts and keyword density, with a flag for stuffing over 3%. Each check comes with a tip.

Scans the pages that rank for a keyword and works out the page type Google rewards: guide, listicle, product, category, service page, forum or video. Then tells you whether your page matches, and what to change if not.

Groups your Search Console queries into topics and shows which page owns each one, where two pages compete for the same topic, which topics have no page yet, and which internal links to add.

Your assistant writes the sub-questions AI Mode and AI Overviews fan out for a topic. OnPage.dev rates each one answered, buried, partial or missing on your page and on up to 2 competitors, with the sections to add.

Internal PageRank and click depth from a site audit: pages the home page cannot reach, pages too many clicks deep, dead ends, strong pages that pass little on, and important pages that need more links.

A real browser on phone, tablet and desktop: is the H1 and call to action visible, does a cookie wall cover it. With screenshots. With screenshots, plus design checks such as low contrast and uneven spacing.

The page the way screen readers and browsing AI agents read it, from the accessibility tree: landmarks, the heading outline, and every link, button, image and field with the name it gets, including the ones announced as just "link".

How the structured data describes who and what the page is about, the way AI knowledge graphs read it: which entities there are, how they connect, dead profile links, and the JSON-LD that is missing.

Finds the passages on a page that best answer a question, the way AI answer engines pick text to quote, with their length and fit. Shows whether the answer is easy to lift out or buried in a long block.

Reading ease with the formula made for the page language, measured against the right target: the pages that rank for the keyword, or the norm for the page type. Lists the sentences that are hardest to read.

Every Open Graph and Twitter Card tag, and the share image itself: does it load, its real size in pixels, type and weight, against what Facebook, LinkedIn, X, WhatsApp and Slack need. Also a free REST API.

Opens the page in a real browser and captures the hits it really sends to Google: on a first visit, after accepting cookies and on a return visit. Finds double counting, tracking before consent, a banner that never updates Consent Mode and debug mode left on.

Core Web Vitals from real Chrome visitors, the field data Google uses: LCP, INP, CLS, FCP and TTFB on phone and desktop, with a pass or fail and the share of good visits. For the trend over time, use check_vitals_trend.

Reads your server access log lines and shows what Googlebot, Bingbot and AI crawlers really request: hits per bot, the errors and redirects they get, crawl budget lost on parameters, and sitemap pages Googlebot never visits.

A WCAG 2.1 AA report for the European Accessibility Act, every check mapped to its success criterion: language, alt texts, form labels, link names, headings and contrast, plus a list of what to test by hand.

Quick check of the cookie setup from the HTML: which consent platform runs, whether Consent Mode v2 is set to denied before the tags load, and whether the v2 signals are there. For live hits, use check_ga4_tracking.

Product structured data checked for Google: name, image, price, currency and availability, identifiers like SKU and GTIN, shipping and returns, variants, and the fields merchant listings need. Missing values come with the fix.

For a question people search, finds the section that answers it on the pages that rank and on yours, and compares the format: a paragraph and its length, a list and its items, or a table. Then tells you how to rewrite yours.

Valid language and region codes, x-default and the self-reference on a multilingual page, then every language version: does it load, is it indexable, does it link back, and do the canonical and html lang match. Writes the corrected tag set.

The trust signals Google and AI models look for across the site: About, Contact, Privacy and Terms pages, email, phone and address, company and VAT numbers, Organization markup and social profiles, and on articles the author and dates.

For a business with a location: LocalBusiness markup with address, phone, opening hours and geo, whether name, address and phone match the pages, a Google Business Profile link, a map, and a page per location. Writes corrected JSON-LD.

Search Console URL Inspection results turned into causes, fixes and the next tool: noindex, robots.txt, a canonical Google ignores, crawled but not indexed. Fetch the rows with your own Search Console tool.

Groups the pages of a site audit by text similarity and shows which ones say almost the same thing, with their titles, words and canonicals. Per group the page to keep, and whether to merge with a 301, set a canonical or rewrite.

Classifies every query parameter in the site's links as tracking, session, search, sort, pagination or filter, and finds crawl traps: tracking in internal links, crawlable search results, filter combinations and pagination that canonicalises to page 1. Writes the robots.txt rules.

The fixes for every issue: as HTML to paste, as a pull request, applied in WordPress, or served at the edge by a Cloudflare Worker on any CMS.

Writes JSON-LD for Article, Product, FAQPage, Organization or BreadcrumbList from the page's own content and checks it against Google's rich result rules. Values it cannot read are marked TODO, so nothing is guessed.

A ready-to-upload llms.txt built from the sitemap and home page: the site name, a short summary, and the main pages grouped by section with their titles. Check it afterwards with validate_llms_txt.

Writes robots.txt rules for 13 AI crawlers from a policy you choose: allow all, AI search only, block training, or block all. Merged into the site's current robots.txt, so your existing rules stay in place.

For a migration or a restructure: matches old URLs to new ones by path and title with a confidence score, lists the ones to check by hand, and writes the rules for _redirects, nginx, Apache or Next.js.

Shows how a title and meta description appear in Google: the pixel width against the cut-off on desktop and mobile, and the truncated text a searcher would see. Iterate on variants until they fit.

A writing brief for a search term from the pages that rank for it: the subtopics and questions they cover, the facts and figures they give, the length and the schema they use, and what your page could add.

From a site audit, which existing pages should link to a page and with what anchor text, based on shared topics. Works for a new page too, by topic, so it gets links from the day it goes live.

From a site audit, one Cloudflare Worker rule per section: titles, descriptions, canonicals and social tags fixed on every matching page, with a preview. Only missing or out-of-range values change.

A Worker that serves GPTBot, ClaudeBot and PerplexityBot the rendered page from your own Cloudflare account, while visitors and Google get the normal one. It says so when a page does not need it.

Scans HTML that is not live yet: a local build, a template or a draft from your editor. The same score and issues as scan_page, so your agent can check its own work before anything is deployed.

An SEO diff between two versions of a page, for example before and after a code change: the score change, issues fixed and introduced, and regressions like a stray noindex or a lost canonical, flagged before merging.

Checks JSON-LD before you publish it: JSON syntax, @context and @type, full URLs, ISO dates, valid prices and currency codes, and Google's required and recommended fields for each rich result.

Checks a site's llms.txt against the llmstxt.org format: served as plain text, one H1 with the site name, a summary, sections with proper links, its size, and whether the links it lists actually load.

May Googlebot, GPTBot or ClaudeBot fetch this URL? Tests it against the live robots.txt with Google's own matching rules, and shows the exact user-agent group and rule that decides, so you know what to change.

Status codes and the full redirect chain for up to 20 URLs at once, and where each one ends up. Give the expected targets after a migration and every URL that lands somewhere else is flagged.

Scans a live page again and compares it with the previous scan: the score change, the issues that got fixed, new issues that appeared and the change in AI readiness. The proof that a deploy did what it should.

A small measurement script for your own browser tool, such as Claude in Chrome or Playwright, for staging sites, localhost and pages behind a login, where OnPage.dev cannot reach. No daily limit.

Runs the first-screen checks of render_page on the results from your own browser: is the H1 and call to action visible, pop-ups and cookie walls, tap targets, small text and what crawlers without JavaScript miss.

Finds the sitemap through robots.txt, follows the index and checks the format, the 50,000 URL limit, foreign hosts and lastmod dates that are all the same. Then checks a sample of URLs for redirects, errors, noindex and canonicals elsewhere, with corrected entries.

Custom extraction for up to 20 pages: a CSS selector, a regular expression or a JSON-LD path such as Product.offers.price. See which pages have the value, which miss it and how many distinct values there are, to verify a template fix at scale.

Google Sheets rows and a CSV link, a Slack message, one task per issue for Linear, Jira or Asana, and a checklist. Your agent sends it with the tools it already has.

Scans a page again and publishes a shareable proof page on onpage.dev with the score before and after, the issues fixed and the ones still open. Made for clients. Not indexed, and it expires after 90 days.

Records every fix that shipped with its old and new value, the date and how it went out. OnPage.dev then keeps it live, measure_impact saves the result per fix, and get_fix_log turns it into a client report.

Tells Bing, Yandex, Naver, Seznam and Yep that the fixed pages changed, so they recrawl within minutes instead of days. The first call sets up the key file to upload. For Google, use URL Inspection in Search Console.

A daily check for regressions, with a private RSS feed and optional Slack or Discord alerts. Watch a competitor and every change they make comes with the counter-move for your page.

Every change found on a watched page, newest first: the page going down or redirecting, a new noindex, blocked AI crawlers, a changed canonical or title, the score dropping, new and fixed issues, and the counter-moves for competitors.

Stops a watch and deletes its history, including the private RSS feed. Each connection can watch 3 pages at a time, so use it to swap a finished page for the next one you want to keep an eye on.

Every logged fix is checked about every 6 hours. When a deploy undoes one, the restore code goes to your webhook or, with the fix guard GitHub Action, into an issue in your repo.

Picks the home page and up to 10 key pages and checks them every day: score, AI readiness, issues with their codes, AI crawler access and Core Web Vitals per week. The history builds up for dashboards and client reports.

Search Console, GA4 or Ahrefs numbers from before and after, against pages you did not touch, so seasonality is not counted as your win. With a fix log, the result is saved per fix.

Two periods from Search Console, compared page by page: lost rankings, lower search demand, fewer clicks at the same position because of an AI Overview, or pages that dropped out. Ranked by lost clicks, with the next tool per cause.

Results on page 1 whose click-through rate is far below normal for their position, with the clicks a better title and description could win. Quick wins that need no ranking change, tested with check_snippet.

Queries at positions 8 to 20 with real impressions, grouped per page, with the clicks a move into the top 5 could win and the pages that compete for the same query. The fastest ranking wins first.

Core Web Vitals from real Chrome users, weekly for about 9 months, on phone and desktop. Give the date a speed fix went live and see the weeks before and after, and since when each metric passes.

How often AI assistants cited your pages before and after the fixes, per engine, against pages you did not change, so a general rise in AI traffic is not counted as your result.

The feed as clean tables: overview, pages, issues over time, open issues, vitals, AI access and fixes. Dates and full URLs, so they join with GA4 and Search Console or their BigQuery exports in Claude Dashboards.

A complete blueprint for a live dashboard in Claude: realtime visitors from your own GA4, traffic from Search Console, and SEO health, fixes, speed and AI visibility from OnPage.dev, with ready BigQuery SQL and the prompt.