SEO Audit

What is the SEO Audit?

An SEO audit tells you what a search engine sees when it looks at one of your pages, and what you would need to change to make that view better. This one runs Google PageSpeed Insights against any public URL and hands back four category scores, then the failures worth fixing first. Performance is how fast the page loads and becomes interactive. Accessibility is how well a person using assistive technology can read it. Best practices is a grab-bag of things Google considers non-negotiable: security headers, HTTPS, deprecated APIs. SEO is the one that reads most literally on the label: whether the page has a meta description, whether its links are crawlable, whether its viewport is set for mobile.

Under the four scores are up to ten specific audits the page failed, in order of how much fixing them would move the numbers. That order is the point. A typical page fails thirty things, and the ranking tells you which two or three would earn you real ground and which twenty-eight are noise. Fix the top item, run the audit again, and watch the scores change. That loop is what makes the audit useful before a client meeting, before shipping a redesign, or after somebody drops a new script tag into the site and the numbers slip without an obvious cause.

When to use it

Ship a change that touches the browser and the scores drift. A new WordPress theme, a build-config tweak, a hero image swapped for a heavier one, a third-party analytics tag added under duress. Fresh numbers are the fastest way to know whether the change moved the site in the direction you thought it did. Run the audit against staging before merging, then again after deploy, and compare against the last time you looked. What matters is the delta. A jump from 82 to 71 says something even when both would count as green in a report you would share with a client.

Desktop is the default because it matches the environment most developers work in. What the tool shows is closest to what the person building the site is looking at. Mobile is what Google actually indexes, and what Search Console judges rankings on. Switch to Mobile if the goal is understanding ranking behaviour rather than debugging a change locally, and expect the numbers to be lower. The mobile audit runs under a slower simulated CPU and network, on purpose, because Google's real crawler does the same. One PageSpeed call either way.

How this tool works

Every page you audit is loaded fresh in a headless Chrome that Google runs on their server. Lighthouse, the same auditing tool built into Chrome DevTools, measures the load: how long until the first paint, how much time until the page is interactive, whether the largest content element is text or an image, how many bytes crossed the wire. It also inspects the page after load: does every image have alt text, are colour contrasts high enough for low-vision readers, are links descriptive, is there a meta description in the head. Each check comes back as a score between 0 and 1, or a pass or fail, and Google averages the ones in each category to produce the four numbers you see.

The four scores are weighted differently. Performance is a weighted composite of six timing metrics; a single slow one drags the number down more than any two decent ones lift it. Accessibility is closer to pass or fail: every failing check counts equally toward the deduction. Best practices is the same shape as accessibility. SEO is stricter than most people expect. It fails a page for a missing meta description even when the rest of the page is perfect.

The "What to fix" list at the bottom is not sorted by which category the failure sits in, or by which score is lowest. It is sorted by how much fixing the item is likely to move the numbers, which for performance audits is a millisecond estimate Google attaches, and for the others is a calibrated default. Expect the highest-impact fix to be either a performance issue or an accessibility one. SEO items rarely top the list, because most of them are cheap to fix and score high the moment they are done.

Frequently asked questions

• Why did my score change between two runs?

  PageSpeed scores are noisy. Google runs the audit on a shared virtual machine under a simulated network and CPU throttle, and the same page can score 78 one minute and 84 the next without any change on your side. A single-run difference of 5 to 10 points is normal. If you need a stable number for reporting, run the audit three times and use the median, or look at Search Console's Core Web Vitals report instead: it aggregates measurements from real users over 28 days rather than one simulated run.

• Is the URL I audit logged anywhere?

  Not by us. There is no record of which URLs are audited, no history you can reopen, no analytics event that carries the URL. The one thing this site remembers is a per-IP counter so you cannot run more than twenty audits a day from the same address, and that counter is deleted twenty-four hours after the last audit. Google does log the URL on their side, because they need it to run the audit, and Google's privacy policy at policies.google.com/privacy covers what they do with that. If a URL is truly sensitive (an unlaunched staging site under NDA), do not paste it here or anywhere else that hands it off to a third party.

• What if my site is behind a login or a firewall?

  Google's PageSpeed crawler cannot reach it. That means the audit cannot happen, and the tool comes back with an error saying Google could not audit that URL. The same story applies to pages behind Cloudflare's under-attack mode, IP allowlists that do not include Google's crawler range, User-Agent blocks on Googlebot, or a robots.txt that disallows the path you are testing. For a private staging site, either put it behind Basic Auth so Google can request the page with credentials, or run Lighthouse locally in your own Chrome (DevTools > Lighthouse) against localhost. This tool is for auditing pages Google can already see.

• Why does the audit take up to twenty-five seconds?

  Because PageSpeed is doing real work. Google's server loads the page in a headless Chrome, runs Lighthouse against it, times how long each rendering step takes, checks the accessibility tree, inspects every image and every script, and computes the four category scores from about two hundred underlying audits. That takes eight to twenty-five seconds for most pages, sometimes longer for heavy single-page applications that keep loading resources after the first paint. This tool caps the wait at twenty-five seconds so a browser tab does not sit there indefinitely on a broken page. If Google does not finish inside that window, the request times out and you can try again without using up an audit slot.

• How does this differ from running Lighthouse in Chrome DevTools?

  The audit engine is identical. Lighthouse in DevTools runs the same category rules against a page loaded in your own Chrome; PageSpeed runs those same rules against a page loaded on Google's server. The DevTools version is fast, private (no URL leaves your machine), and reflects your machine's network and CPU. The PageSpeed version is slower and requires a public URL, but it uses Google's standardised environment, which is what Search Console reports on. Use DevTools while working on a change. Use this tool to see the number Google would report after the change ships.

• Can I get a custom version of this for my team?

  Yes. A rate-limited public tool is the right shape for a single developer checking a change before shipping. It is the wrong shape once an SEO team is tracking a hundred URLs weekly, once a marketing agency wants a monthly report for every client site, or once a build pipeline needs a gate that blocks a merge when Performance drops below a threshold. Zinc Online Solutions builds that: scheduled crawls against your URL list, historical scoring stored in a database you can query, per-client PDF reports, and a Slack notification when a Core Web Vital regresses. Tell us how you track this today and what would count as an improvement, and we will scope the version that gets there.