Search essentials together
Review response status, HTTPS, title, meta description, canonical, robots directives, document language and primary heading in one report.
Free · no signup
On-Page SEO Audit
Inspect the initial HTML that a guarded server fetch receives, then work through concrete search, page-structure and social-preview findings without an opaque ranking score.
Your audit will appear here
Review indexability signals, titles, descriptions, headings, image alt attributes, structured data syntax, Open Graph and card metadata in one report.
The submitted public URL is fetched once by WebTaskKit. The URL, query string and HTML body are not stored or written to access or event logs; only this tool's canonical path and an allowlisted action name may be counted.
Simple by design
How to use SEO audit
- 1
Enter one public HTTP or HTTPS page on its normal port. Never submit a private dashboard, signed link or URL containing an access token.
- 2
Run the audit and review definite issues before warnings. Each finding explains the observed signal instead of hiding it behind a score.
- 3
Update the page, run the bounded check again, then confirm platform-specific behavior in Search Console, a schema validator and relevant social preview tools.
Meta and Open Graph checks
Inspect the basic Open Graph properties, card fields, URL validity and the content that may shape search and social previews.
A fetch path built to fail closed
Every destination and redirect is DNS-validated, pinned to a public address and bounded by response, redirect, header and absolute time limits.
Put it to work
Practical ways to use SEO audit
Review a page before publishing
Catch a missing title, description, canonical or H1 in the server-rendered HTML before submitting a new landing page for indexing.
Diagnose a weak link preview
Compare Open Graph and card fields when a shared URL shows the wrong title, description or image on messaging and social platforms.
Check a rendered-site migration
Confirm that a framework migration still returns essential metadata and internal links in the initial response, not only after client JavaScript runs.
Choose deliberately
Make the right output
Treat issues as observable gaps
Missing page signals such as a non-empty title, description, canonical or H1 are clear review points, but their relevance still depends on the page's purpose.
Review warnings in context
A noindex directive, different canonical or sparse social metadata may be intentional. Confirm the page's job before changing it.
Use platform tools for eligibility
A parseable JSON-LD block is not proof of a valid rich result, and complete Open Graph tags do not guarantee identical previews everywhere.
Continue the workflow
Useful next steps
Primary guidance
What the checks are based on
Guidance reviewed August 19, 2026. Search appearance is not guaranteed; the report describes the fetched HTML and links to the source documentation behind its recommendations.
Good to know
Frequently asked questions
Does the audit store the URL or page HTML?
No. The submitted URL and fetched HTML are used in memory for one response and are not stored or written to WebTaskKit access or event logs. The destination server may still log the incoming WebTaskKit request.
Why does this tool use a server fetch?
Browsers normally prevent one site from reading another site's HTML. A bounded server fetch can inspect the public response while applying destination, redirect, size and time protections.
Can it check a localhost, staging or password-protected page?
No. The security policy rejects local, private, reserved and credential-bearing destinations. Publish a safe public preview or inspect private HTML with development tools inside the authorized environment.
Does it render JavaScript?
No. It analyzes the initial HTML response only. Content and metadata added exclusively by client JavaScript may not appear in the report.
Is a clean report proof that the page will rank?
No. The checks cover a bounded set of technical and editorial signals. Relevance, content quality, links, competition, crawlability, indexation and many other systems affect search visibility.
Why are compressed HTML responses rejected?
The client explicitly requests identity encoding. Rejecting unexpected compression keeps the raw and decoded byte budget identical and removes decompression-bomb ambiguity.
Does it validate structured data?
It checks whether JSON-LD blocks parse and lists bounded @type values. It does not validate schema requirements or eligibility for a particular rich result.
What should I fix first?
Start with a successful HTTPS response and one useful title, description, canonical and primary heading. Then review indexing intent, content structure and social preview fields in context.