OnPage.dev MCP server

Most SEO tools give you a report. OnPage.dev gives your assistant something to do: write the fix, check it before you publish, and confirm it worked. It also checks what AI search sees, not only Google: which AI crawlers may read your site, whether your content is ready to be quoted, and whether you have an llms.txt.

You:        Fix the SEO on our pricing page and keep going until it scores 90 or more.

Assistant:  scan_page            46/100  no meta description, no H1, title 14 characters
            get_fix_pack         title, description and canonical, written from the page
            schema · generate    Product JSON-LD, 2 values to fill in
            (edits pricing.html)
            scan_page · html     92/100  before deploying, all errors gone
            scan_page · rescan   94/100  live, +48 since the first scan

            Done. 46 to 94. Two prices in the JSON-LD still need your real values.

New

• Drafts and post updates in WordPress. The content autopilot now ends in wp-admin: new posts arrive as drafts, updates show what changes, one click to approve, undo any time. Plugin 1.1.

• Content in your site's own voice. Content autopilot: content modes voice, calendar and draft plus the content_autopilot prompt: your agent writes, OnPage.dev learns how the site writes, plans a dated calendar, checks each draft for voice, unsourced figures and SEO before you approve, and learns from measured results which formats work on your site.

• Approve fixes in WordPress, one click. Your agent sends the fixes to the free OnPage.dev WordPress plugin. You see old and new value per field, approve, and undo any time. Through Yoast SEO, Rank Math or its own tags. OnPage.dev never logs in.

• Ask about your traffic, no CSV exports. Finds the day traffic broke and the Google update that ran then, from Google's own status dashboard. Plus lost and split queries, the questions AI answers, and Google against Bing, from the Search Console, GA4 and Bing rows your assistant already reads.

• Checks every deploy preview. Holds a Vercel, Netlify or Cloudflare preview against production before you merge: lost titles and canonicals, noindex, broken pages. In chat or as a GitHub Action that comments on the pull request.

They bring the data. OnPage.dev closes the loop.

The SEO MCP servers from Ahrefs, Semrush, SE Ranking and DataForSEO are built for data: what ranks, who links, what people search. Then the real work starts. OnPage.dev does that part, inside the same chat, and uses their numbers to decide what to fix first.

An example of the two kinds of answer. Prices, plans and the full comparison: onpage.dev/compare. Built by an SEO specialist with 24 years of experience; the scoring method is public at onpage.dev/methodology.

Related MCP server: aeo-graph-engine

The whole loop, inside your AI agent

Most SEO tools stop at a report. OnPage.dev gives an agent every step, and each step is a tool it can call:

Four weeks later...

You:        Did the fixes on /pricing and /features work?

Assistant:  (Search Console)     clicks for 28 days before and after 8 September
            measure · impact     changed pages +70%, unchanged pages +3%
                                 → +66% lift; /features +357% after the stray noindex was removed

measure · impact subtracts the trend of the pages you did not change, so seasonality and Google updates are not counted as your result. It is honest about what it shows: a comparison of two periods, not proof.

From finding to done

Most SEO tools stop at a report. OnPage.dev hands the plan to the tools your team already works in, so fixes get assigned and shipped. share · export turns a page scan or a whole site audit into:

• Google Sheets: one row per finding with priority, page, issue, fix, code and status. Every export comes with a private CSV link, so =IMPORTDATA("https://onpage.dev/export/….csv") loads it into a sheet with no connector at all.

• Slack, Teams or Discord: a ready summary with the fixes that matter most, posted by the agent's Slack tool or straight to an incoming webhook.

• Linear, Jira, Asana, Trello or GitHub Issues: one task per issue, grouped across pages, with priority, labels and how to fix it.

• Notion or Confluence: a Markdown checklist.

You:        Audit example.com, put every fix in a Google Sheet and post the summary in #seo.

Assistant:  site_audit · start   25 pages, 41 findings
            share · export       sheet link, Slack message, 12 tasks
            (Google Sheets)      rows added to "SEO fixes"
            (Slack)              posted to #seo

OnPage.dev never logs in to Slack, Google or your task board: the agent sends the plan with the tools the user already connected, or you paste one formula. Scan results and audits end with a hint, so agents offer the export on their own.

Seen by every reader

Google reads your HTML. Visitors see one screen on a phone. Screen readers, and AI agents that browse for people, read the accessibility tree. OnPage.dev checks all three in a real browser.

layout · render loads the page on a phone, tablet and desktop and checks the first screen: is the H1 and the call to action visible without scrolling, does a cookie wall or pop-up cover it, are tap targets big enough, what shifts while loading. It loads the page again with JavaScript off to show what GPTBot and ClaudeBot miss, and checks whether the first screen delivers what the Google snippet promises. With screenshots.

It also checks design and readability, the details that make a page look professional and easy to read:

• Text with too little contrast, measured against its real background (WCAG AA: 4.5:1, or 3:1 for large text), with the colours to fix.

• The exact element that makes the page scroll sideways on a phone, and by how many pixels.

• Mixed button styles: how many corner styles and heights the buttons use.

• Uneven spacing between sections.

accessibility · screen_reader reads the page the way a screen reader announces it:

heading level 1, Running shoes for flat feet
link, Women
link                         ← announced without a name
button                       ← announced without a name
image, Trail shoe in grey mesh, side view
link, Read more              ← vague, and weak anchor text

It flags links and buttons without a name, vague link text, form fields without a label, a missing main landmark, skipped headings and visible text hidden from readers. Accessibility is not a direct Google ranking factor, but alt text, link text, headings and text that is not hidden are exactly what search engines, AI answer engines and browsing agents read. Even carefully built sites miss this, including sites built with AI coding assistants. In a real scan of a well-built news site that passed every other check, including Lighthouse, the screen reader view still caught links announced as just "link" in nine different card layouts across the site: each thumbnail image linked to its article but gave a screen reader no name to read.

Have your own browser tool (Claude in Chrome, Playwright)? layout · probe gives a small measurement script and layout · analyze analyses its results: no daily limit, and it works on staging, localhost and pages behind a login.

Real-user speed

Lab tests guess. web_vitals · now shows what real Chrome visitors got over the last 28 days, from the Chrome UX Report: the field data Google uses for ranking.

You:        Is our homepage fast enough for Google?

Assistant:  web_vitals · now     Phone: passed · Desktop: passed
                                 LCP  1.4 s   good   93% of visits good
                                 INP  197 ms  good   75% of visits good, 8% poor
                                 CLS  0.00    good   95% of visits good

• LCP, INP and CLS, plus FCP and time to first byte, on phone and desktop, each rated good, needs improvement or poor.

• Pass or fail on the Core Web Vitals assessment, and the share of visits that were good, needs work or poor.

• Pages with too little traffic fall back to the whole site, and the tool says so.

• What to fix for every metric that is not good. The same card is in every scan on onpage.dev.

Uses the SEO data you already have

Already connected Google Search Console, GA4, Ahrefs or Semrush to your assistant? OnPage.dev tells the assistant to pull their numbers in, then prioritize_fixes ranks every fix by the traffic it can win. Nothing connected? It ranks by severity, as before. You do not set anything up.

You:        Audit example.com and tell me what to fix first.

Assistant:  site_audit · start   10 pages, average 81
            (Ahrefs) top pages   clicks, positions, keywords, referring domains
            prioritize_fixes     ranked by traffic impact

            1. /pricing is noindex but gets 900 visits a month. Fix this first.
            2. /results ranks #6 for "league table" (5,600 searches a month).
               Add the term to the H1 to push into the top 3, ~330 extra clicks.
            3. /guide shows up 20,000 times at position 3 but gets 0.2% clicks.
               Rewrite the title and description, test them with check_snippet.

How it works: an MCP server cannot read other connectors, and should not. OnPage.dev's results and instructions ask the assistant to fetch the numbers from any SEO data tool it has, and the assistant passes them to prioritize_fixes. The numbers are used for that answer only and never stored. OnPage.dev never logs in to those services.

Spikes, drops and the Google update behind them

Search Console, GA4 and Bing in one chat, no CSV exports. Ask about your traffic and the agent passes the daily rows to find_opportunities with mode: "anomalies":

You:        Did anything odd happen to our traffic this quarter?

Assistant:  (Search Console)  daily clicks, 90 days, by page
            find_opportunities · anomalies

            Drop 25 to 27 Sep: -59% (90 clicks, normal about 220)
            Google: September 2026 spam update (Ranking, 24 Sep to 8 Oct)
            /pricing   12 clicks, normal about 80

• Each day is compared with the 28 days before it, per weekday, so a normal weekend dip is not an alarm.

• Google core updates, spam updates and Search incidents are read live from the Google Search Status Dashboard. traffic_drop takes a drop_date and checks the same list.

• mode: "ai_queries" finds the questions, comparisons and long conversational queries in your Search Console or Bing rows, per page, and flags pages that rank but lose the click to an AI answer.

And what AI already cites

With Ahrefs Brand Radar (or any source of AI citation counts) connected, ai_visibility · citations puts the pages ChatGPT, Perplexity, Gemini and Google AI cite next to the ones they skip. OnPage.dev scans every page and shows which checks the cited pages pass and the others fail, the averages side by side (AI readiness, words, facts per 100 words, outside sources, entity graph issues), and what each skipped page should change. It is honest about the limits: a correlation over a few pages, not proof of cause.

What prioritize_fixes looks for: blockers on pages with traffic, low click-through for the position, keywords in striking distance (position 4 to 15), top queries missing from the title or H1, and pages with strong backlinks that score badly.

With GA4 conversions (key events) or revenue per page, it ranks by money instead of clicks: a pricing page that converts comes before a busy blog post that does not.

A rank tracker that knows what matters

No keyword lists to maintain. Each run (daily or weekly, from a Claude routine or a dashboard refresh), the assistant passes your Search Console rows and, if connected, your Ahrefs Rank Tracker or Semrush Position Tracking rows to track_rankings. OnPage.dev merges Search Console's average with the tracker's exact position and picks what to follow by itself:

• Work you did: the queries of every page in your fix log, with the day it changed

• Money keywords: pages with GA4 conversions or revenue, commercial or transactional intent, your own list

• Near wins: positions 4 to 20 with real demand

• Top 3 to defend, plus everything you already track in Ahrefs or Semrush

You:        How did our rankings do this week?

Assistant:  (Search Console) + (Ahrefs Rank Tracker)
            track_rankings      run 6, 214 keywords followed

            Needs attention: "buy boots" off page 1 (8 → 15) [money]
                             "buy boots" now ranks with /blog/boots instead of /boots
                             → diagnose_cannibalization
            Wins:            "trail shoes" onto page 1 (13 → 5) [money]
            Work done:       /trail (title, 1 Oct): 9 queries, average +6 places

Every run lists new top 3 and page 1 entries, keywords lost, big movers, a different page ranking (a cannibalization signal), vanished queries and AI Overviews appearing, with the next tool for each, and can post to Slack or Discord. It keeps the first run and the last 90.

Which of your pages wins the keyword

Two pages of yours chase the same keyword and the wrong one ranks. check_keyword · cannibalization reads the page that should rank and the pages that outrank it, live, and puts them side by side on every on-page signal, then says what to change:

You:        Our blog post outranks the product page for "trail running shoes". Why?

Assistant:  (Search Console) rows   blog post at #4, product page at #14
            diagnose_cannibalization

            | Signal          | Product page | Blog post   |
            | Title           | partial      | exact @0    |
            | H1              | –            | exact       |
            | H2 / H3         | 0 / 1        | 3 / 2       |
            | Body mentions   | 2 (0.3%)     | 11 (1.4%)   |
            | Bold / italic   | 0 / 0        | 4 / 1       |
            | Alt / file names| 0 / 0        | 3 / 2       |

            1. Strengthen the product page: exact keyword at the start of the title, in the H1 and an H2.
            2. Tone down the blog post: keyword out of its title, H1 around its own angle, stop bolding it.
            3. Link from the blog post to the product page with "trail running shoes" as the anchor.

It counts the keyword in the title (and how early), URL, meta description, H1, H2 and H3, the body text and the first 100 words, bold and italics, image alt texts and file names, checks canonical and noindex, and maps which of the pages link to each other with the keyword as anchor. When two pages say nearly the same, it proposes a merge with a 301 instead. content · topics finds the competing pages across a whole site first.

Disavow without the risk, and manual actions cleaned up

A wrong disavow file can cost more rankings than the spam ever did. backlinks · disavow takes your backlink data (Ahrefs is_spam, Semrush toxic markers or a CSV) and only puts clear spam in disavow.txt: domains marked as spam, or spam anchors on sites with no authority and no traffic. Anything with authority goes on a list for a person to decide, and without a manual action or real negative SEO it tells you not to upload the file at all.

Got a manual action? explain_google · manual_action covers every type in Google's documentation (unnatural links, thin content, cloaking, structured data, site reputation abuse and more): what Google means, the cleanup steps in order, the tools that check them, what to keep as proof, and a reconsideration request draft with a TODO for everything you actually did.

Bring your own crawl

site_audit · start reads up to 25 pages. Already crawled the site with Screaming Frog, Ahrefs Site Audit, Semrush or Sitebulb? site_audit · import takes up to 500 page rows and the internal links, and returns an audit_id that every audit tool understands: site_audit · continue, internal_links · equity, internal_links · suggest, edge_worker · rules, technical · parameters and share · export.

You:        Here is our Screaming Frog export. What should we fix first?

Assistant:  site_audit · import   480 pages, 6,912 internal links
            site_audit · continue  meta description missing on 118 pages, 9 broken pages
            internal_links · equity  /pricing is 5 clicks deep with 2 links in
            edge_worker · rules   one rule fixes the descriptions on all /blog pages

Only the columns you send are checked, so a crawl without a description column never reports 480 missing descriptions. The rows live for one hour, long enough to work through the audit. After that only a compact snapshot (address, status, score, title, canonical, noindex and issue names per page) stays for 90 days, so site_audit · compare can show what changed next time.

What changed since the last audit

Every finished site audit, crawled or imported, leaves a small snapshot for 90 days. After the next release, run the audit again and site_audit · compare shows what moved:

You:        We shipped the new templates. Did anything break?

Assistant:  site_audit · import   480 pages from this morning's crawl
            site_audit · compare  vs the crawl of 3 October

            Regressions: /pricing now returns 404, /blog/guide turned noindex,
            12 product pages changed their canonical.
            Fixed: meta descriptions on 118 pages, 9 broken pages work again.

Or let it run by itself: watch · site_audit audits the site every day, week or month (up to 25 pages), compares each audit with the last one, and posts the changes to Slack, Discord or any https webhook when pages broke, turned noindex, changed canonical or got new issues. action: "status" shows the last result.

Links to win, and AI answers to enter

Two more jobs where your SEO tool has the data and OnPage.dev makes it a plan:

• track_rankings: Search Console plus Ahrefs or Semrush rank tracking, keywords picked from your work, money pages and near wins, with what moved each run.

• backlinks · disavow: disavow.txt with only clear spam, the rest up for review, and a warning when you should not upload it.

• explain_google · manual_action: every Google manual action type with cleanup steps, checking tools, proof to keep and a reconsideration request draft.

• check_links · outbound: dead links to other sites, cited pages that now redirect to a home page and moved pages, with an archived copy as replacement.

• check_keyword · cannibalization: the page that should rank next to your pages that outrank it, signal by signal (title, URL, meta, H1 to H3, mentions, first 100 words, bold, italics, alt texts, file names, internal keyword anchors), with the plan to fix it.

• plan · split_test: 20+ pages of one template split into two groups with equal traffic, a Worker that changes the title or description on one group only (same for visitors and Googlebot), measured with measure · impact.

• site_audit · report: a finished site audit as a clean report page with your agency name, to send as a link or save as a PDF.

• text_quality · spelling: real spelling and grammar errors in a page's main text (LanguageTool, about 30 languages), brand names and style advice left out.

• sitemap · generate: sitemap.xml from an audit with only indexable, self-canonical pages and the reason for every page left out.

• Sections and competitors: site_audit · continue shows issues per section; site_audit · compare with competitor_audit_id compares two sites side by side.

• find_opportunities · content_decay: monthly clicks per page (Search Console, Ahrefs pages-history or GA4) become a refresh queue of pages that peaked and kept falling, seasonal dips left out.

• get_fix_pack · alt_texts: lists images without alt text; your assistant looks at them and writes the texts; OnPage.dev checks them and ships them as HTML, a Cloudflare Worker, WordPress or code.

• Applied internal links: internal_links · suggest with platform returns a Cloudflare Worker that links the first mention on each page (never inside an existing link), a WordPress plan or code edits.

• Google Business Profile vs site: local · check with gbp_profile compares name, phone, address, opening hours per day, category and the profile's website link with the site.

• Rich result errors: explain_google · index_status groups URL Inspection richResultsResult and Enhancements export rows per type and issue, so a broken template is one fix.

• get_fix_pack · web_vitals: speed fixes as code, ordered by the failing metric (main image priority, deferred scripts, preconnect, font swap, image sizes), also as a Cloudflare Worker.

• backlinks · opportunities: pass the referring domains of up to 5 competitors and your own (Ahrefs, Semrush or a CSV). You get the sites that link to two or more competitors but not to you, ranked by overlap and domain rating, typed (best-of list, resource page, review site, directory, forum, news) with how to approach each, and checked live. Add pages that mention your brand and it reads each one: the ones that name you without a link come back with the sentence to quote in your email.

• ai_visibility · gaps: pass real AI answers from Ahrefs Brand Radar or another AI visibility tool. You get your share of answers per engine next to each competitor, the questions where they are named and you are not (by search volume), what the AI searched to answer them, and the outside sites it cites, which are the places to get onto.

You:        Why does ChatGPT recommend Rivalo and not us?

Assistant:  (Ahrefs) Brand Radar     120 answers for us and 2 competitors
            ai_visibility · gaps     ChatGPT names Rivalo in 41%, us in 12%
                                     14 questions where only they appear
                                     cited most: zapier.com list, g2.com, reddit
            backlinks · opportunities  zapier.com links to both rivals, not to us

And the links you lost

Other sites still link to pages you deleted or moved, and visitors still land on them. Every one of those links and visits is value you no longer get. With Ahrefs, Semrush, GA4 (page views of your 404 page) or a CSV export, backlinks · broken turns them back into ranking power and traffic:

You:        Which of our backlinks point at dead pages? Fix them.

Assistant:  (Ahrefs) broken backlinks   112 links to 19 dead pages
            backlinks · broken          ranked by linking sites and domain rating
                                        top 20 checked live: 14 dead, 3 already fixed, 2 block bots

            1. /blog/running-shoes-guide  38 sites, best DR 81  → /guides/running-shoes
            2. /old-promo                 12 sites, best DR 64  → /socks/trail (anchor text match)
            3. /moved                     reached via 3 redirects → one 301 straight to /new-home
            14 rules ready for _redirects. /old-promo is still in your sitemap.

The dead pages are grouped and ranked by link value (each linking site counts once, weighted by domain rating, nofollow at 30%). The top 20 are checked live, so pages that already work again or only block bots are not redirected by mistake. Each dead page gets the best live page from your sitemap or a site audit, matched on the URL, the page title and the anchor texts other sites used. No close match? It says so instead of dumping the link on the home page. GA4 404 hits add real visits to the ranking, and when the visitors came from one of your own pages, that link is listed as an edit instead of hiding it behind a redirect. The rules come out for _redirects, nginx, Apache, Next.js or CSV, with the strongest linking sites worth an email. Then check_links · urls confirms each one is a single 301 and fix_log · log keeps watching them.

Lost backlinks work too. Pass Ahrefs backlinks with their history and lost_reason: a page that died or a redirect that broke on your side gets a 301, and a link the other site took out goes on an outreach list, strongest first, with what to ask ("put it back", "link the new version of your page") and the sentence the link used to sit in.

No Search Console connected? find_opportunities · striking_distance and content · topics also take Ahrefs or Semrush organic keyword rows (keyword, url, position, volume, traffic). And content · topics with competitor_rows gives a keyword gap: topics where competitors rank in the top 10 and you do not, by search volume, with the page to strengthen or the page to write.

Writes in your site's own voice

Most AI writing tools sound like AI writing tools. OnPage.dev does not write at all: your own agent writes, and OnPage.dev gives it the eyes, the plan and the checks, so every post sounds like the rest of your site and is built on what already worked there.

You:        Plan next month's posts for example.com and draft the first one.

Assistant:  content · voice      5 articles read: sentences ~14 words, paragraphs ~52,
                                 "you" voice, 30% question headings
            content · calendar   8 items over 4 weeks
                                 Mon  Refresh /guides/compost "compost bin" (pos 11, +140 clicks)
                                 Thu  New     "raised bed soil"  as a list (lists lifted clicks +18% here)
            content · draft      Voice match 91/100
                                 1 figure without a source: "cuts household waste by 30%"
                                 SEO scan 88/100

            Here is the draft. Approve it and I publish it as a draft in WordPress,
            log it, and measure it in 4 weeks.

• Learns the voice. Sentence, paragraph and section length, question headings, lists, "you" or "we", title length and sample passages, from 2 to 5 of your best articles. Every content brief then carries it.

• Plans the calendar. Refreshes for queries almost on page 1 and new pages for topics you miss (from content · topics or ai_visibility · gaps), alternated and dated per week. Keywords already drafted are skipped.

• Checks every draft before you see it. Voice match with concrete tips, figures without a source link, and a full SEO scan of the HTML.

• Learns what works on your site. Once a draft is published and logged, measure · impact results are tied to its format, length, title and FAQ. Three measurements make a rule, Google updates are left out, and every fifth item tests a format not tried yet.

• Keeps the loop going. The calendar is saved in the site memory, so site_memory shows what is due and overdue, and which published posts are ready to measure. Add a Slack or Discord webhook and it reminds you every Monday.

• Never publishes on its own. The content_autopilot prompt runs the whole loop and waits for your approval before anything goes live.

Matches search intent

The fastest way to waste a month: write a product page for a keyword where Google only ranks guides. content · intent checks what actually ranks before you write.

Your agent pulls the top results for the keyword from Ahrefs or Semrush, and OnPage.dev scans every one of them and works out the page type Google rewards: guide, listicle or comparison, product page, category page, service page, tool, local business page, news article, recipe, help page, pricing page, forum or video.

You:        Does our page fit "best running shoes for flat feet"?

Assistant:  (Ahrefs) serp-overview   top 7 results
            content · intent         8 pages read

            Your page fits: Google ranks listicles here (runrepeat, rtings),
            and yours is one too.
            4 of 7 results are forums (Reddit, JustAnswer): searchers want
            real experience. Add first-hand testing, photos and named experts.
            43% of the top results put the year in the title.

• Page type match: match, close (same intent, other format) or mismatch, with the evidence per result.

• Format that ranks: median length and subheadings of the top results, how many have a FAQ, a year or a number in the title.

• Forums and videos: recognised from the address, without scraping them, and turned into concrete advice about experience and trust.

• The whole site: pass Search Console rows and it finds queries where two of your pages compete with each other, and pages that attract mixed intents.

Readability that fits the page

A product page should not read like documentation. text_quality · readability measures reading ease (Flesch, or Flesch-Douma for Dutch) against the right target: the median of the pages that rank for the keyword, or the common norm for the page type when there are no competitors. It lists the hardest sentences and paragraphs to rewrite first, ignoring menus, link lists and tables.

Assistant:  text_quality · readability  Reading ease 63, ranking pages median 52 (52, 63, 49)
            Hardest sentence (22 words, score 8):
            "Runner's World Running Reviews Editor, Amanda Furrer, who has
             relatively low arches, researched shoe testing data from..."

Ships to WordPress

From chat to live, with you approving every change. get_fix_pack with platform: "wordpress" turns the fixes into a WordPress plan your agent can apply through your own WordPress connection (for example a WordPress MCP server):

You:        Fix the SEO on /trail-shoes and put it live.

Assistant:  scan_page            46: title too short, no meta description, 1 image without alt
            get_fix_pack         platform: wordpress, 3 changes
                                 SEO title       -> Yoast _yoast_wpseo_title
                                 Description     -> Yoast _yoast_wpseo_metadesc
                                 Alt text        -> media library

            Shall I apply these 3 changes?          You: yes
            (WordPress) update post + media
            scan_page · rescan   94, all 3 fixed

• The exact field for each value in Yoast SEO and Rank Math, alt texts for the media library, and structured data as a Custom HTML block.

• Your agent shows every change as old and new value and waits for your approval before anything goes live.

• OnPage.dev never logs in to your site and stores no passwords: your own WordPress connection makes every change.

• Without a WordPress connection, the same plan tells you exactly what to paste where.

One-click approval with the WordPress plugin

Install the OnPage.dev WordPress plugin (source), click Connect in Tools, OnPage.dev and give your agent the site key. Then get_fix_pack with mode: "wordpress" sends the fixes straight to your wp-admin:

New in plugin 1.1: your agent can also send a whole post. A new post or page arrives as a draft you publish yourself. An update to an existing post shows the removed and added paragraphs side by side and goes live when you approve it. Undo restores the old text unless someone edited the post since.

You:        Fix the SEO on /trail-shoes and send it to WordPress. Site key wpk_...

Assistant:  get_fix_pack · wordpress   3 changes waiting for approval

wp-admin:   Tools, OnPage.dev
            title             Trail shoes          ->  Trail running shoes for rocky ground | Acme
            meta_description  (empty)              ->  Grip, cushioning and sizes for ...
            jsonld            (none)               ->  Product
            [Approve selected]  [Reject all]

Assistant:  get_fix_pack · wordpress   change_id: applied, old values kept
            scan_page · rescan         94, all 3 fixed

• Old and new value per field, approve all or some, undo any change set later.

• Written through Yoast SEO or Rank Math when active, otherwise the plugin outputs the title, description, canonical and social tags itself. JSON-LD and media library alt texts work everywhere.

• Pull only: the plugin fetches proposed changes when you open its page. OnPage.dev never logs in to your site, and nothing changes without an administrator's approval.

Ships to your CMS, not just WordPress

get_fix_pack writes the plan for the platform the site runs on, with the exact MCP tool or API call and field for every fix, applied through the user's own connection after approval:

Ships as a pull request

Not on WordPress? get_fix_pack with platform: "git" writes the fixes as code for the site's framework and opens a pull request through the git tools your agent already has. It detects Next.js (App and Pages Router), Nuxt, SvelteKit, Astro, Angular, React, Vue and plain HTML from the page itself.

You:        Fix the SEO on /pricing and open a PR.

Assistant:  scan_page            58: title too short, no canonical, no structured data
            get_fix_pack         platform: git, detected Next.js (App Router)
                                 export const metadata = { title, alternates.canonical }
                                 JSON-LD in the page component
            git switch -c seo/onpage-pricing
            (edit app/pricing/page.tsx, build)
            scan_page · html     91, nothing else changed
            gh pr create         #42 "SEO: title, canonical, jsonLd for /pricing"

• metadata for Next.js, useSeoMeta and useHead for Nuxt and Vue, <svelte:head> for SvelteKit, the Title and Meta services for Angular, head tags for Astro and plain HTML.

• Always a new branch, checked with scan_page · html before the PR, never merged by the agent.

• For client-side React, Vue and Angular apps it also says how to prerender, because AI crawlers do not run JavaScript.

Share cards, with a free API

snippet · social shows how a page looks when it is shared on Facebook, LinkedIn, X, WhatsApp and Slack: every Open Graph and Twitter tag, and the share image itself. It loads the image and reads its real size from the file header, so it catches the cases other checkers miss: an og:image that returns 404, a 400 x 400 logo where a 1200 x 630 image belongs, an SVG that no platform shows, or a 6 MB file.

The same check is a free public REST API, no key needed:

curl "https://onpage.dev/api/v1/og?url=https://example.com"

{ "url": "https://github.com/", "score": 100,
  "image": { "ok": true, "type": "image/png", "width": 1200, "height": 630, "bytes": 618778 },
  "issues": [] }

10 requests a minute per IP address, CORS open, each result cached for 5 minutes. Try it in the browser: Open Graph checker.

Keeps watching after you ship

Most SEO problems are not there on launch day. They arrive later: a deploy adds noindex, a CMS update changes the canonical, a new robots.txt blocks GPTBot. watch · page rechecks a page about once a day and records every change for search and AI. Alerts go to a private RSS feed and, if you give one, a Slack or Discord webhook. No account, no key.

You:        Keep an eye on our pricing page and tell me if anything breaks.

Assistant:  watch · page         baseline 94/100, 8 of 8 AI crawlers allowed
            ...three days later, in your Slack:
            OnPage.dev: 2 change(s) on https://example.com/pricing
            - A noindex tag was added: the page will drop out of Google
            - The score went from 94 to 71

And three more jobs agents get asked to do every week:

• content · brief: give a search term and the pages that rank, get a writing brief: the subtopics most of them cover, the questions they answer, figures to back up with your own data, a target length, schema and internal links. Bot walls and navigation headings are filtered out.

• plan · redirects: give the old and new URLs (or the sites, to read their sitemaps) and get a 301 map with a confidence score per match, written as _redirects, nginx, Apache, Next.js or CSV. Then verify after launch with check_links · urls.

• site_audit · import: pass the page rows of a crawl you already have (Screaming Frog, Ahrefs Site Audit, Semrush, Sitebulb), up to 500 pages plus the internal links, and every audit tool works on the whole site. Only the columns you send are checked.

• site_audit · compare: a finished site audit against the previous one of the same site (snapshots kept 90 days): pages that broke, turned noindex or changed canonical or title, issues new or fixed per code, pages added or gone, average score before and after.

• watch · site_audit: audits a whole site every 1, 7 or 30 days, compares each audit with the previous one and posts regressions to a webhook (Slack, Discord or any https endpoint). Status and stop with the schedule_id.

• backlinks · opportunities: competitor backlink gap (sites linking to 2+ competitors, not to you) ranked and typed with how to approach each, plus unlinked brand mentions read live with the sentence to quote.

• ai_visibility · gaps: real AI answers (Brand Radar or similar) turned into share per engine, questions where only competitors are named, the AI's searches and the sites it cites.

• backlinks · broken: pass the broken backlinks from Ahrefs, Semrush or a CSV export. The dead pages are ranked by the sites that still link to them, the top 20 are checked live, each gets the best live page to 301 to (from the sitemap, a site audit and the anchor texts), and the rules come out ready to ship. Dead pages still in the sitemap, redirect chains and temporary redirects are flagged too.

• share · link: after fixing a site, publish a before and after page (for example 46 → 94, with the issues fixed) to send to your client. Not indexed, expires after 90 days.

Remembers every site

Agents forget everything between chats. OnPage.dev does not. site_memory keeps one memory per site, behind a secret memory_key: open it in a chat and every OnPage.dev tool call is recorded (what was found, shipped and measured), and guards, scheduled audits, competitor watches and fix logs started in that chat add their results too. The next chat, in Claude, ChatGPT or Cursor, starts where the last one stopped.

You:        Pick up where we left off on example.com.

Assistant:  site_memory · open   41 steps since July: pricing 46 → 91, 12 fixes shipped,
                                 +38% clicks vs control, guard caught a noindex on 3 Oct
            Next:                1. Measure the 4 fixes shipped 5 weeks ago
                                 2. /blog/guide scored 58, no fix written yet
                                 3. No rank tracker yet

It learns. Every measured result is tied to the fixes shipped before it, so with a memory open prioritize_fixes, get_fix_pack and plan · sprint show which fix types moved traffic on this site ("title rewrites +38% here"), and site_memory · next suggests rolling them out to more pages. Decisions saved as notes come with every fix pack, brief and draft.

It connects the dots. A ranking drop, traffic drop, decay, vitals regression or alert comes with the fixes, deploys and decisions of the last three weeks, so the agent checks those first.

It learns across sites, if you opt in. Open the memory with share_learning: true and each measured result adds one anonymous row per fix type to a shared pool: the fix type, the change rounded to a whole percent and the month, never the site, addresses, numbers or text. Once a fix type has 20 measurements from 10 sites, prioritize_fixes, get_fix_pack and plan · sprint show the median change across sites. Turning it off or deleting the memory removes everything that memory added.

The memory stores summaries and a few numbers per step, not your raw data rows or page content. The key is stored only as a hash, and an unused memory is deleted after 400 days.

Acts, guards and measures like an SEO team

The work around the fixes, done by your agent with the tools you already connected.

You:        We shipped the new templates. Make sure nothing broke and plan next month.

Assistant:  request_recrawl      12 of 12 pages indexable, IndexNow sent
            watch · guard        guarding robots.txt, sitemap and 5 key pages
            plan · sprint        19 tasks over 4 weeks, tickets ready for Linear
            ...two days later, in your Slack:
            OnPage.dev guard: /pricing has noindex. Fix: remove the noindex meta tag.

Built for agents

What makes OnPage.dev different from every other SEO MCP server:

• Everything in one chat, dashboards included. Data, plan, the fix your agent deploys and the proof all happen in the chat. dashboard · feed checks a site's key pages every day, dashboard · data returns the history as clean tables that join with GA4 and Search Console, and dashboard · build designs a live dashboard for Claude with a realtime GA4 block (active users per minute, pages, events) next to SEO health, fixes, speed and AI visibility.

• Takes action, not notes. Your agent ships the fix itself: a pull request in your framework, a change through your own WordPress connection, or a Cloudflare Worker from get_fix_pack with platform: "cloudflare" that corrects the tags as the page is served, on any CMS on your own Cloudflare account. One step to roll back.

• Closes the loop for real. fix_log · log records every fix that shipped. OnPage.dev checks about every 6 hours that each one is still live, sends the restore code to your webhook when a deploy undoes it, saves measure · impact results per fix with a rollback plan when one did worse, and fix_log · report writes the client report.

• Proves the result. measure · impact compares before and after numbers against a control group of unchanged pages. More.

• From finding to done. share · export sends the plan to Google Sheets (no connector needed), Slack, Notion or a task board. More.

• Sees every reader. First screen on phone, tablet and desktop in a real browser, and the page read aloud like a screen reader. More.

• Handles JavaScript apps. Pure client-side React, Angular and Vue apps get a full audit of the rendered page, the way Google sees it, plus how little AI crawlers get without JavaScript.

• Ships anywhere. WordPress through your own connection, every other stack as a Git pull request with framework code. More.

• Real users and real bots. web_vitals · now reads Core Web Vitals from real Chrome users; technical · logs shows what Googlebot and AI crawlers actually crawl.

• Multilingual and trustworthy. technical · hreflang checks every language version and writes the corrected tag set; entity · trust checks the E-E-A-T signals across the whole site.

• No gaps in the technical audit. sitemap · check checks format, limits and lastmod dates and samples the listed URLs for redirects, errors, noindex and canonicals elsewhere. technical · extract pulls one value from up to 20 pages (CSS selector, regex or JSON-LD path). technical · duplicates groups near-duplicate pages from an audit by their own content, and technical · parameters finds tracking, search and filter URLs that trap crawlers.

• Measures more than clicks. find_opportunities · traffic_drop explains a drop page by page (lost rankings, lower demand, fewer clicks at the same position, pages that dropped out), find_opportunities · ctr_gaps and find_opportunities · striking_distance find the fastest wins in Search Console data, web_vitals · trend shows real-user speed weekly for about 9 months before and after a fix, and measure · ai_citations proves the gains in AI answers against a control group.

• Fixes a whole section, and JavaScript apps. edge_worker · rules turns a site audit into one Cloudflare Worker rule per section (titles, descriptions, canonicals, social tags on every matching page, with a preview). edge_worker · prerender serves GPTBot, ClaudeBot and PerplexityBot the rendered page of a React, Vue or Angular app from Browser Rendering in your own Cloudflare account.

• Explains why Google skips a page. explain_google · index_status turns Search Console URL Inspection results into causes, fixes and the next tool, and every scan catches a head that ends early (an image or iframe in <head> that hides the canonical).

• Watches your competitors. watch · page with competitor_of follows a competitor's page; when they add a section, structured data or a lot more text, the alert says what your page is missing and which tool fixes it.

• Every fix in your GA4 charts and your repo. fix_log · report with format: "annotations" marks each fix day in GA4, and the fix guard GitHub Action opens an issue with the restore code when a deploy undoes a fix.

• Debugs your GA4. tracking · ga4 captures the hits a page really sends to Google in a real browser, before and after accepting cookies and on a return visit: double counting, tracking before consent, a banner that never updates Consent Mode, debug mode left on, Universal Analytics leftovers.

• Makes AI read and quote you. robots_txt · ai_policy writes robots.txt rules for 13 AI crawlers, llms_txt · generate and llms_txt · validate handle llms.txt, answer_readiness · passages shows whether a page answers well enough to be quoted, entity · graph checks that AI knows who is behind the site.

• Maps your topics and wins the snippet. content · topics groups Search Console queries into topics with the page that owns each one, competing pages and gaps; answer_readiness · format shows the answer format (paragraph, list or table) that wins the featured snippet.

• Matches what ranks. content · intent finds the page type Google rewards for a keyword, text_quality · readability compares reading ease with the pages that rank, and content · brief turns them into a writing brief.

• Share previews that work. snippet · social loads the real share image and checks it against Facebook, LinkedIn and X, also as a free REST API.

• Local and linked. local · check checks LocalBusiness markup, NAP consistency, the Google Business Profile link and a page per location; internal_links · equity maps internal PageRank and click depth and shows which important pages need more links.

• Ready for AI Mode. answer_readiness · questions checks a page against the sub-questions AI search fans out for a topic, and shows the gaps where AI will cite someone else.

• Accessibility for the EAA. accessibility · wcag maps every check to WCAG 2.1 AA, the standard behind the European Accessibility Act.

• Ecommerce and consent. schema · product_page checks Product markup for merchant listings; tracking · consent checks the cookie banner and Consent Mode v2.

• Closes the loop after shipping. request_recrawl · indexnow pings Bing and other IndexNow engines, and the agent runs URL Inspection in your Search Console tool for Google.

• Reads every language right. Reading ease uses the formula for the page language: Flesch-Douma for Dutch, Amstad for German, Kandel-Moles for French, Fernández-Huerta for Spanish.

• A public scoring method. Every check, what it costs and what the score leaves out, on onpage.dev/methodology. What changed lives on onpage.dev/changelog.

• Light on context. 37 tools cover 116 jobs: related jobs share one tool with a mode, so the tool list your agent loads in every chat is about 71 KB instead of 155 KB, and it fits clients that cap the number of tools. Old tool names keep working. Connect https://onpage.dev/mcp?tools=core for the 8 main tools when your agent already loads many servers.

• Easy to continue, easy on context. Every partial result carries next_call, the exact tool and arguments to continue, so long jobs get finished. Add detail: "brief" to any call for a short summary (about 80% shorter) while the structured result stays complete.

• Keeps watching. watch · page catches regressions after launch and alerts by RSS or webhook. More.

• Uses the data you already have. Search Console, GA4, Ahrefs or Semrush in the same chat? prioritize_fixes ranks every fix by traffic impact with their numbers, and ai_visibility · citations shows what the pages AI cites do differently. How it works.

• Stable issue codes and typed results. Every issue has a fixed code like meta-missing or h1-missing, and the main tools declare an output schema. An agent can work through issues one by one and prove each one is gone.

• It checks the code the agent writes. scan_page · html, schema · validate and compare · html test new HTML and JSON-LD before it ships, and catch regressions such as a stray noindex or a removed canonical.

• Launch and migration built in. check_links · urls follows every redirect chain for up to 20 URLs at once; robots_txt · test answers "may this bot fetch this URL" with Google's own matching rules, including * and $ wildcards.

• Whole sites, step by step. site_audit · start runs as a job the agent works through, so a 25-page audit fits a free hosted service. It reports issues across the site by code, broken and orphan pages and duplicates.

• You vs the pages that rank. compare · pages puts a page next to up to 3 competitors with content gaps and fixes to catch up; internal_links · suggest shows which pages should link where.

• Knowledge graph ready. entity · graph checks that your Organization and authors are real, linked entities with profile links, not just valid markup. llms_txt · validate catches the common case where /llms.txt returns an HTML page.

• Citability, not just crawlability. AI readiness checks fact density, cited outside sources and whether every question heading gets a direct answer. compare · pages shows the facts and figures only a competitor gives, and the ones only you give: information gain, measured against the pages that rank.

• No made-up advice. The onpage://rules resource gives the assistant every check, threshold and fix, so it explains SEO from the same rules the scanner uses.

• Free and hosted. Paste one URL. No account, no API key, no install.

Install in one minute

One click for Cursor and VS Code. For Claude, ChatGPT and other clients, see below.

The server is hosted. There is nothing to install or run, and no key.

Fewer tools in context: use https://onpage.dev/mcp?tools=core for the 8 main tools (site memory, scan, AI visibility, fix pack, layout, site audit, prioritise, share). The full server has 37 tools, under the roughly 40 that Cursor shows across all servers..

Server URL: https://onpage.dev/mcp

claude mcp add --transport http onpage https://onpage.dev/mcp

Or install the plugin for the server plus ready commands and skills.

Settings → Connectors → Add custom connector → paste https://onpage.dev/mcp → save. Turn the connector on in a chat.

Add a custom connector with https://onpage.dev/mcp (Settings → Connectors, with developer mode on). Which plans can use custom connectors is up to OpenAI.

~/.cursor/mcp.json or .cursor/mcp.json in your project:

{
  "mcpServers": {
    "onpage": { "url": "https://onpage.dev/mcp" }
  }
}

.vscode/mcp.json:

{
  "servers": {
    "onpage": { "type": "http", "url": "https://onpage.dev/mcp" }
  }
}

~/.codeium/windsurf/mcp_config.json (Windsurf uses serverUrl), then Refresh under Manage MCPs:

{
  "mcpServers": {
    "onpage": { "serverUrl": "https://onpage.dev/mcp" }
  }
}

~/.gemini/settings.json, then check with /mcp:

{
  "mcpServers": {
    "onpage": { "httpUrl": "https://onpage.dev/mcp" }
  }
}

codex mcp add onpage --url https://onpage.dev/mcp

Or [mcp_servers.onpage] with url = "https://onpage.dev/mcp" in ~/.codex/config.toml.

cline_mcp_settings.json:

{
  "mcpServers": {
    "onpage": { "type": "streamableHttp", "url": "https://onpage.dev/mcp" }
  }
}

settings.json (a small bridge with Node.js):

{
  "context_servers": {
    "onpage": { "command": "npx", "args": ["-y", "mcp-remote", "https://onpage.dev/mcp"] }
  }
}

MCP Client Tool node on an AI Agent: Server URL https://onpage.dev/mcp, transport HTTP Streamable, no authentication. Workflows can then scan, audit and report on a schedule.

Streamable HTTP transport at https://onpage.dev/mcp, no authentication. Supports MCP 2026-07-28 (stateless, server/discover) and the earlier revisions with a session down to 2024-11-05. Without sessions, pass memory_key on tool calls to record them in the site memory.

What it can do

37 tools that cover 116 jobs. Related jobs share one tool and are picked with mode, for example site_audit with start, continue, import, compare and report; leave mode out for the first one. Old tool names from before 2.0 keep working. Every result links to the full visual report on onpage.dev. Issues carry stable codes; the full list is in the onpage://rules resource.

Audit and fix

Whole site and competitors

Act, watch and measure

AI search

Launch and migration

Writing and code

Ready workflows (MCP prompts)

One click in clients that show prompts:

• Full SEO and AI audit: scan, AI check and fix pack, then a prioritised plan.

• Why can't AI find my site?: which assistants can read and quote you, and what to change.

• Launch checklist: a tick or cross for everything a page needs before going live.

• AI visibility makeover: robots.txt, llms.txt and answer passages in one go.

• Pre-deploy SEO gate: scan the built HTML and block the release below a minimum score.

• Pick up where we left off: opens the site memory and continues with the next step.

• Weekly SEO routine: alerts, rankings, undone fixes and the three things to do this week.

• Fix and prove it: scan, fix, ship after approval, log, recrawl and plan the measurement.

• Site migration: baseline audit, redirect map, checks on the new site and a guard.

• Monthly client report: fixes shipped, results against unchanged pages, rankings and next month.

• Investigate a traffic drop: when it dropped, the Google update that ran then, the pages and queries that lost, and the first fixes.

• AI search review: the queries AI answers, the pages that should be quoted and the passages to add.

• Executive summary: one page for leadership: trend, causes, what was fixed and next month.

• Content autopilot: learn the voice, plan the calendar, draft, check, publish after approval and learn from the results.

Reference resource

onpage://rules: every check with its stable code, why it matters and how to fix it, plus the key thresholds (title and description length in pixels, word counts, alt text, server response, AI answer length).

Score card in the chat

In clients that support MCP Apps (Claude) or the Apps SDK (ChatGPT), a scan also shows as a visual card right in the chat:

• The score from 0 to 100, with a one-line verdict.

• AI readiness: how well AI assistants can read, trust and quote the page.

• Fix first: the most important issues, marked error, attention or tip.

• Open full report: the complete visual report on onpage.dev.

Other clients get the same result as text and structured data, so nothing is lost.

Why it is different

Full comparison with the Ahrefs, Semrush, SE Ranking and DataForSEO MCP servers, with prices: onpage.dev/compare.

What OnPage.dev does not have: its own search volumes, rankings or backlinks. Connect a data vendor in the same chat and OnPage.dev turns their numbers into ranked fixes.

Example prompts

Why does ChatGPT never mention example.com? Check it with OnPage.dev.
Scan our pricing page and give me the five fixes with the code.
Let ChatGPT search read our site but block AI training. Write the robots.txt.
We moved to a new URL structure. Check that these 20 old URLs redirect to the right new pages.
Review this pull request for SEO regressions: compare the old and new HTML of the changed pages.
Audit our whole site and tell me the three fixes that help the most pages at once.
We are writing a page about trail running shoes. Which of our pages should link to it?
How does our pricing page compare with these two competitors, and what are we missing?
Does our blog post answer "how long does shipping to Germany take" well enough for AI to quote?
Write three title options for this page and check which ones fit in Google.
Fix the SEO issues in this project, check the build with OnPage.dev and keep going until it scores 95.

Claude Code plugin

The server plus commands and skills that run the fix loop for you.

/plugin marketplace add seoonpage/seo-mcp-server
/plugin install onpage@onpage-dev

• /seo-check [url or path]: scan a live page, or find this project's built HTML and scan that, then fix what is wrong.

• /ai-visibility: check whether ChatGPT, Claude, Perplexity and Gemini can read and quote the site, and write robots.txt and llms.txt.

• seo-fix-loop skill: fixes in your source (templates, Next.js metadata, Astro frontmatter), checks with scan_page · html before deploy and confirms with scan_page · rescan after.

About 300 tokens of always-on context.

GitHub Action: SEO gate

Scans the HTML your build produces on every pull request, comments the scores and top fixes, and fails when a page drops below your minimum.

name: SEO gate
on: pull_request
permissions:
  contents: read
  pull-requests: write
jobs:
  seo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: npm ci && npm run build
      - uses: seoonpage/seo-mcp-server@v1
        with:
          paths: "dist/**/*.html"          # built HTML to check
          base-url: "https://example.com"   # optional, for canonical and relative links
          min-score: "80"                   # fail below this
          max-files: "10"                   # about 20 scans per minute

The pull request gets a comment like this, updated on every push:

❌ OnPage.dev SEO gate: lowest score 36 (minimum 80)

Page	Score	AI readiness	Fix first
dist/about/index.html	36	0	There is no meta description; There is no H1; The title is 5 characters
dist/index.html	90	22	Thin content: 32 words; No structured data; Open Graph is incomplete

GitHub Action: preview check

Checks every deploy preview against production before you merge. It compares the same paths on Vercel, Netlify or Cloudflare Pages previews and on the live site: pages that break, titles, canonicals and H1s that disappear, a new noindex, lost structured data, and canonicals or og:url that point to the preview host. The X-Robots-Tag noindex that preview hosts add is ignored. Results go into one pull request comment.

name: SEO preview check
on: deployment_status
permissions:
  contents: read
  pull-requests: write
jobs:
  seo:
    if: github.event.deployment_status.state == 'success' && github.event.deployment.environment != 'Production'
    runs-on: ubuntu-latest
    steps:
      - uses: seoonpage/seo-mcp-server/preview@v1
        with:
          preview-url: ${{ github.event.deployment_status.environment_url }}
          production-url: https://example.com
          paths: "/ /pricing /blog"
          fail-on: blocker          # blocker, warning or none
          bypass-token: ${{ secrets.VERCEL_AUTOMATION_BYPASS_SECRET }}   # only for protected Vercel previews

The same check works in chat: compare with mode: "preview".

GitHub Action: fix guard

Keeps shipped fixes live. Once a day it asks OnPage.dev whether every fix in your fix log is still on the page. When a deploy undid one, it opens an issue with the restore code; when all are live again, it closes the issue. It uses the repository's own token, so OnPage.dev never gets access to GitHub.

name: SEO fix guard
on:
  schedule:
    - cron: "0 7 * * *"
permissions:
  issues: write
jobs:
  guard:
    runs-on: ubuntu-latest
    steps:
      - uses: seoonpage/seo-mcp-server/guard@v1
        with:
          fix-log-id: "YOUR_FIX_LOG_ID"   # from fix_log
          fail-on-regression: "false"     # true to fail the run as well

Your coding agent can pick the issue up and open the pull request with the value restored.

Security and privacy

• Nothing changes on your site by itself. OnPage.dev only reads public pages or the HTML you send. Fixes ship through your own tools (your git, your WordPress, your Cloudflare), after you approve them. Watches and shared result pages store scores and issue names, never page content; fix logs store the URLs and the old and new values you log.

• Public pages only. Private, internal and local network addresses are refused (SSRF protection), and so are non-web schemes.

• No storage of content. HTML sent to scan_page · html is analysed in memory and dropped. For change tracking, only the score and issue names are kept, under a hashed key, for up to 30 days. A scheduled audit stores the site address, interval, webhook and last result until you stop it (at most 400 days). A finished site audit leaves a snapshot for 90 days (per page: address, status, score, title, canonical, noindex and issue names) so site_audit · compare can show what changed; page text is never kept. text_quality · spelling sends up to 10,000 characters of the page's own public text to LanguageTool. Backlink, 404 and AI answer rows passed to backlinks · broken, backlinks · opportunities or ai_visibility · gaps are used for that answer only.

• Your traffic data stays yours. Numbers passed to prioritize_fixes or measure · impact are used for that answer only, except that measure · impact with a fix_log_id saves the before, after and change per logged page in that fix log. OnPage.dev never connects to Search Console, GA4, Ahrefs or Semrush itself.

• Prompt injection aware. Text from scanned pages is returned as data and marked as such.

• Fair use limits. About 20 scans per minute per connection, plus a shared cap. Real-browser checks (layout · render, accessibility · screen_reader) share a daily budget; with your own browser tool, layout · probe has no limit. No accounts, no keys, no tracking cookies.

Full details: onpage.dev/privacy and onpage.dev/terms.

Good to know

• The main scan reads the HTML a server returns, the way AI crawlers do. When that HTML is an empty shell from a client-side React, Angular or Vue app, scan_page loads the page in a real browser and audits the rendered page instead, and reports how many words crawlers without JavaScript get. This shares the daily real-browser budget; when it runs out you get the raw-HTML scan with a warning. layout · render and accessibility · screen_reader add phone, tablet and desktop views, with and without JavaScript.

• Link checks, image sizes and AI crawler access need a live URL, so scan_page · html skips them.

• Pixel widths in snippet · search are an estimate; Google can also rewrite snippets.

Links

• Web app: onpage.dev

• MCP server and setup: onpage.dev/mcp

• Questions: hi@onpage.dev or open an issue

License

MIT