Page SEO Audit

What it does

The Page SEO Audit pulls one URL through our server, parses the response in your browser, and returns a single report covering every common page-level SEO check at once — title and description, canonical, robots meta, hreflang, Open Graph and Twitter Cards, JSON-LD schema, heading hierarchy, image alt text, internal and external links, word count, redirect chain, status code, response time, and key headers. Findings are weighted by severity and rolled into a score so you can see at a glance whether the page has a few cosmetic issues or something structurally broken.

Common situations

You have just published a new page and want to check it before promoting it — the audit catches missing canonicals, oversized titles, and incomplete schema in seconds, which is usually faster than opening seven Chrome extensions.

A page that was performing well in search has dropped, and you suspect something on-page changed during a recent deploy. Run the audit on the live URL and compare against your memory of what was there before — title length, robots meta, canonical, schema presence are the usual suspects.

You are vetting a competitor’s article that is outranking yours and want to know what they are doing differently. Run their URL, check the schema types they declared, the headings they used, the social card presence — these are the structural things you can match without copying their content.

You have inherited a site mid-engagement and need a quick triage of which pages are obviously broken. Audit the top-traffic URLs (or the ones the previous team flagged), sort by score, and you have a prioritised remediation list before you have written a brief.

A migration has just gone live and you want to verify the redirected old URLs land cleanly on their new homes — the audit shows the full redirect chain plus the destination’s audit in one report. If a 301 is landing on a 404, the audit catches both.

What you need to know

The audit is built around the checks that consistently move rankings on real engagements, weighted in proportion to how often they actually cause problems. The score starts at 100 and deducts: 15 points per high-severity finding (no title, robots noindex, HTTP 4xx/5xx), 7 per medium (no canonical, slow TTFB, redirect chain over two hops, missing H1), 2 per low (no Open Graph, short title, missing schema). The arithmetic is deliberately rough — the score is a triage signal, not a precise diagnostic. The findings list is what to act on.

What the audit reads is the HTML the server returns to a non-JavaScript client, which is also what most search bots see during the initial crawl. Pages that rely heavily on client-side rendering (React, Vue, or Next.js apps that hydrate client-side) will return less to the audit than they show to a real visitor — the audit will report what the crawler sees on first fetch, which is usually the relevant view for indexing decisions. If your stack uses server-side rendering or full prerendering, the audit and the visitor see the same content; if it does not, the gaps the audit finds may also be the gaps Googlebot finds.

A few specific things the audit deliberately does NOT do. It does not score Core Web Vitals — those require running the page in a real browser environment, and Google’s PageSpeed Insights is the canonical source for that data. It does not check for backlinks, domain authority, or keyword rankings — those need paid data feeds. It does not crawl the wider site — it audits exactly one URL. For wider coverage, the WP Beacon Plugin is the right next step.

The audit follows up to ten redirects and reports the full chain. The audited URL is the final URL — so an audit of http://example.com/old-page/ that 301s to https://example.com/new-page/ reports the audit of the new page, with the redirect chain shown alongside as context. This is intentional: redirects are part of the indexing story, but the page that ranks is the destination.

Frequently asked questions

What does the score mean?

The score is a 0–100 weighted aggregate of all findings. Above 80 is solid; 60–80 is fixable; below 60 means structural problems that are likely affecting indexing, ranking, or both. The score is a triage indicator — the findings list is what tells you what to do.

Why do JavaScript-heavy pages score lower than they should?

The audit reads the server’s initial HTML response, not the rendered DOM after JavaScript has hydrated. If your site relies on client-side rendering, important markup (title, meta, schema, headings, content) may not be in the initial response and the audit will flag it as missing. This is also what naive bots see, so the gaps may be real.

Does the audit check Core Web Vitals?

No — Core Web Vitals require running the page in a real browser to measure LCP, INP, and CLS. Google PageSpeed Insights is the authoritative source for that data and is also free. The audit reports server response time (TTFB), which is one of the inputs to LCP but not the whole story.

Will it show backlinks or keyword rankings?

No. Backlink and rank data require paid third-party APIs. The audit covers everything that can be derived from the page’s HTML response and headers. For backlinks and rank tracking, the major SEO platforms (Ahrefs, Moz, SEMrush) are the canonical sources.

Can I audit pages behind a login?

Not directly — the audit fetches the URL anonymously, the same way Googlebot does, so it cannot pass authentication. For login-gated pages, the visible-to-Google view is usually a paywall or sign-in screen, which is what the audit will show.

How is this different from running Lighthouse?

Lighthouse runs the page in a headless browser and measures rendering performance and accessibility in addition to SEO. This audit is narrower and faster — it focuses specifically on the page-level SEO surface. They complement each other. Use Lighthouse for performance and full accessibility; use this audit for the SEO checks Lighthouse is shallower on (schema, social cards, hreflang, robots).

Why does the audit report a different status than my browser?

The audit sends a generic non-browser user-agent and follows up to ten redirects. Some sites serve different content to different user-agents (cloaking) or have redirect logic that branches on cookies. The Mobile vs Desktop Diff tool surfaces user-agent-driven differences directly.

Does the audit work on intranet or staging URLs?

Only if they are publicly reachable. The audit fetches through our server, which means private IPs, firewalled hosts, and basic-auth-protected origins are not accessible. For staging environments, the simplest workaround is to expose the URL temporarily through a tunnel like ngrok or Cloudflare Tunnel and audit the public URL.

Common problems

Problem: The audit reports “no title” but the page clearly has one in the browser.

The page is rendering the title client-side. Open the page, view source (not “Inspect” — actual View Source), and search for <title>. If it is missing or empty in the raw HTML, the audit is correct: search bots that do not execute JavaScript see no title. The fix is server-side rendering or, at minimum, statically rendering the head.

Problem: Score drops 30 points overnight without any deploy.

The most common cause is a redirect change introduced upstream — a CDN rule, a security plugin, or an SSL certificate update. The audit’s redirect chain and HTTP headers sections show what changed. The next likely cause is robots meta drift — a CMS update or a publishing workflow change can flip a page to noindex unintentionally.

Problem: The audit shows “noindex” but the page is showing in Google.

Google’s index can lag behind on-page changes by days or weeks. If you recently set noindex on a previously-indexed page, the page will continue to appear in search until Googlebot re-crawls and processes the directive. Use Search Console’s URL Inspection to force a re-crawl if the change is urgent.

Problem: Schema validation passes here but fails in Google’s Rich Results Test.

Google’s Rich Results Test checks against Google-specific requirements that are stricter than schema.org’s own spec. The validator here checks against schema.org’s required and recommended fields per @type. Use this audit for structural completeness; use Rich Results Test for Google rich-snippet eligibility specifically.

Problem: A 301 chain is reported but you only set up one redirect.

CDN, hosting platform, or security plugin layers often add their own redirects (HTTP→HTTPS, www→non-www, trailing-slash normalisation) on top of yours. Each is a hop. The fix is to either consolidate them or accept the chain — but every additional hop costs SEO equity and a small amount of TTFB on every request.

Tips

• Run the audit on the URL Google has indexed, not the URL you typed. Type your URL, follow the redirect chain shown, and re-audit the final URL — that is the page that ranks.
• The score is a starting point, not a target. A page can score 95 and still be invisible to search because the content does not match real intent. Use the audit for technical hygiene, not for content strategy.
• Re-audit after every deploy that touches templates, theme files, or SEO plugins. Drift between deploys is where most regressions hide.
• If two URLs that should serve the same content have different scores, you have a canonicalisation problem. Audit both and compare.
• The audit’s findings list is sorted by severity, not by visibility. A medium-severity “no canonical” usually matters more for ranking than a high-severity “no H1” in practice. Read the findings, don’t just chase the score.

Related tools in this suite

The natural pairing for follow-up is the Schema Validator — once the page audit reports the schema types found, paste the JSON-LD into the validator for required-field checks per type. The Redirect Chain Tracer is the deeper-dive when the audit shows a long chain or an unexpected destination.

What this looks like at scale

Auditing one URL is a spot check. Auditing every page of a site, every visit, with regressions flagged automatically — that is what the WP Beacon Plugin does. It runs the same audit logic against every page and rolls findings into a single dashboard so technical debt is visible rather than discovered the next time something breaks.

Take it further

If the audit has surfaced enough findings that a structured remediation makes sense, the WordPress development service is where ad-hoc SEO fixes turn into a planned, scoped engagement.