SEO Checker methodology

You submit a single public URL. The Worker fetches that HTML with SSRF protections (private networks, credentials, and non-http(s) schemes are blocked). Optional context such as target keyword or business type, when offered in the UI, can refine copy of recommendations but does not invent ranking or traffic data.

• Required: publicly reachable http(s) page that returns HTML.
• Inspected: response status, titles, headings, meta, robots/canonical signals in HTML, main text proxies, links, images, social tags, and structured data when present in the document.
• Not fetched in this tool: full site crawl, robots.txt tree walks, Search Console, CrUX field data, or backlink indexes.

Client-rendered apps may under-report if critical SEO elements only appear after JavaScript. Prefer the URL that search engines receive as first HTML when testing.

score = weighted earned points / applicable points × 100

• Verified / pass earns full points for that check.
• Partial / warn earns a calibrated fraction.
• Failed earns zero there are no free 40–70 floors.
• Optional absent (e.g. hreflang on a single-locale page) is not scored excluded from the denominator.
• Unknown multi-source signals (robots.txt crawl, CrUX, GSC) reduce evidence coverage, not free points.

The design intent is honesty under incomplete evidence. A page that looks polished but fails indexability or title fundamentals cannot hide behind a cosmetic mid-band score.

• Technical status, HTTPS, indexability signals, canonical hygiene, and basic crawl eligibility proxies in HTML.
• On-page title, meta description, H1 structure, and keyword/topic alignment where evidence exists in the document.
• Content evidence main-content depth proxies, heading hierarchy, and extractable claims vs thin or boilerplate-heavy pages.
• E-E-A-T / trust author/org, policy, and proof language visible on-page (not a legal or YMYL certification).
• Social / share Open Graph and Twitter card completeness for link previews.
• Structured data JSON-LD presence and basic validity cues partial credit only, never a rich-result guarantee.
• Answer extractability clear definitions, lists, and FAQ-like blocks that help both users and answer-style systems.
• UX / perf proxies script/CSS weight and related HTML hints not field LCP/INP/CLS.

• Score / grade conversion-style readiness of on-page evidence under this model.
• Evidence coverage how much of the intended checklist was measurable from the fetch.
• Confidence measurement confidence, not "your SEO is good" or a ranking forecast.

Suppose a B2B service homepage scores 62 (C) with78% evidence coverage and medium confidence. Dimension notes show a solid title and HTTPS, weak H1 uniqueness, sparse proof blocks, and no Organization JSON-LD. Caps did not fire.

• Do not treat 62 as a Google rank. It means on-page evidence is incomplete relative to the checklist not that traffic will rise 38% after fixes.
• Prioritize failed technical and on-page checks before social tags. A missing self-canonical or duplicate H1 usually beats perfect Open Graph polish.
• Use coverage as a honesty dial. High score with low coverage is less trustworthy than a mid score with high coverage.
• Re-run after deploy on the same URL to compare score and open opportunities not against competitors’ unknown pages in this tool alone.

If noindex or non-200 caps apply, ignore vanity meta improvements until the page is intentionally indexable and reachable.