Single-page SEO, accessibility and mobile scores

Every domain scan reads the homepage and produces three scores: SEO, accessibility and mobile readiness. They come from the page's own HTML, not from Lighthouse, and there is no speed score here; the site check measures speed in a real browser.

Where

• Web: a domain's SEO & search tab, Overview (score and history); SEO in the rail compares every domain.
• iOS: Website shows Content, Accessibility and Mobile; SEO & accessibility opens on the score ring, the categories, and one row per open problem. Rescan re-reads the homepage.
• API/MCP: GET /api/seo-results/:domainId, /history; POST /api/domains/:id/seo-scan (Starter and up) for a website-only rescan; tools get_seo_results, get_seo_history, run_seo_scan, check_page_seo.

What is checked

SEO: the title (length, and generic wording such as "Home" or "Homepage"), the meta description and its length, the H1 (missing or empty; several non-empty H1s are noted, not penalised, because Google reads them), the canonical (absent, relative, naming another page, or two that disagree), Open Graph tags (including an og:image that is not a full https address), structured data (present, whether the JSON-LD parses, and whether it matches the page: a rating no visitor can see, a phone number or street address that is not on the page, properties Google requires that are missing, or a business rating itself, which Google never shows as stars), and robots directives (noindex, none, nofollow, nosnippet, and an X-Robots-Tag noindex header). Length checks count what a searcher sees, so & is one character. The lengths are guides, not Google rules: Google sets no limit on a title or description and trims them to fit the screen, so roughly 60 and 160 characters are where the end usually stops showing.

Site level: robots.txt (whether Googlebot may crawl the page, and whether the scripts and stylesheets the page needs are blocked), the XML sitemap, and whether http:// redirects to https://. These come from small requests made alongside the page, and a request that fails says nothing rather than reporting a problem.

Best practices and speed: HTTPS, mixed content (only files the page loads: scripts, styles, frames, images and media, not links or og:image), character encoding, favicon, render-blocking scripts (classic external scripts in <head> without async or defer; scripts at the end of <body> are not counted), lazy loading, and HTML size (flagged past 500KB). Earlier versions also counted inline style attributes and listed colour contrast as information; both were removed because they described nothing a searcher or visitor feels.

Accessibility: a static pass over the same HTML for what can be judged without a browser. The quick accessibility score lists every check. The accessibility audit runs the full axe engine in a real browser and is the audit-grade version.

Mobile readiness: five checks, viewport meta (present, device-width, zoom not locked), fixed-width layout, legible text size, tap target size, and plugin content (Flash or Java applets).

What a finding tells you

Each finding quotes what is on the page now, says what to change and why, and carries the corrected tag. Where the page gives enough to build one, the fix includes a draft: a title or description written from your page's own H1, the one-line description in its structured data and its first real paragraph, an og:image taken from the first large image on the page, a label for an unnamed button inferred from its class or id (a cookie-settings button is named "Cookie settings"). A draft is always marked as one, with what it was built from; read it, check every fact in it, and edit it before using it. Google asks the same of anything a tool writes, titles, descriptions, alt text and structured data included (see AI-written content and location pages). When the page says too little to draft from, the fix says so instead of guessing. On a site built with WordPress (with Yoast SEO, Rank Math, All in One SEO or SEOPress), Shopify, Wix, Squarespace, Webflow, GoDaddy Websites + Marketing or Ghost, the fix ends with the screen in that platform's admin where the setting lives.

How a score is built

Each check has an impact: high (weight 3), medium (2) or low (1). A pass earns the full weight, info earns 0.75 of it, a warning 0.4, a failure nothing. The score is earned over total, per category. A category with no checks scores null and is shown as a dash, never as 100: unmeasured is not perfect.

Manual URL scans (Starter and up)

POST /api/seo-results/manual-url scores any public URL and saves it on the account without a monitored domain row; GET /api/seo-results/manual-url/history lists the last 25. The MCP tools check_page_seo, assess_website, score_page_accessibility and score_page_performance do one-off reads of any public page. score_page_performance reports weight, requests and render-blocking resources; it is not a speed score.

Limits

The homepage scan is part of the website scan allowance (6 a day on Free, 25 / 50 / 200 on paid plans). Free accounts cannot run a website-only rescan (POST /api/domains/:id/seo-scan and run_seo_scan answer 402); on Free the homepage is scored with each domain scan.

Common questions

The app shows a different score from the web. Since the scoring moved to the server there is one score, produced by the same function on every scan. If they differ, one side is showing an older scan; pull to refresh.

Why is accessibility 100 when my site is clearly not? A static pass can only see what is in the HTML. Colour contrast from a stylesheet, keyboard traps and dynamic content need the browser-based audit.

Why does the scan say pages checked: 1? The automatic and on-demand scans read the homepage. A whole-site crawl or a sitemap-sampling scan reports the number of pages it read.