SEO audit, prioritized by payoff

How the fetch works

Three routes race at once: a first-party proxy on this domain that resolves the target's DNS and validates it is a public address before fetching (so it cannot be pointed at internal infrastructure), a direct request from your browser, and one public relay (allorigins.win) as a backup. Whichever answers first with usable HTML wins; the others are cancelled. If all three fail within 10 seconds, the tool shows a curl command and a paste-HTML box instead of stopping dead. The log above the results shows exactly which route won, or why each one failed.

The proxy caches a successful fetch for 60 seconds (by URL, so re-running the same audit twice in a row does not hit the target site twice) and rate-limits requests per visitor. Nothing is retained past that window.

Core Web Vitals proxies, not field data

Real LCP, CLS, and INP need a rendering browser and real users. A static HTML fetch cannot produce them, so this tool measures structural proxies that correlate with them:

• HTML document weight (correlates with time to first render)
• Render-blocking stylesheets and synchronous head scripts (delay first paint and LCP)
• Images without width and height attributes (the most common layout-shift source)
• Total DOM element count (large trees slow style, layout, and interaction)
• Native lazy-loading adoption on images

Scoring

Each check carries an impact weight (1 to 5, how much it moves rankings or user experience) and an effort estimate (1 to 5, typical time to fix). Priority is impact × (6 − effort), so a high-impact one-line fix scores 25 and a low-impact rebuild scores 1. The health score is the impact-weighted share of passing checks; warnings count half.