An SEO audit service checks whether search engines can crawl your site, whether your pages are actually indexed, how fast they load for real users, where your content falls short of what ranks, and how your links point around. SerpInsight delivers findings ranked by impact against effort, with the exact URLs affected.
Most audits arrive as a 200-page crawler export with the defaults left on. You get 4,000 “issues”, 3,900 of them duplicate meta descriptions on paginated archives nobody visits. That isn’t an audit. That’s a CSV with a cover page.
A technical SEO audit should end with a short list of things worth doing, in the order they’re worth doing them. The mild opinion we’ll defend: if a website SEO audit doesn’t change what you do next week, it wasn’t worth commissioning.
What an SEO audit is
An SEO audit is a structured review of the technical, content and link factors that decide whether a page can rank — crawlability, indexation, page experience, topical coverage, backlink profile, internal link flow — checked against how search engines treat your site rather than against a generic SEO site audit checklist.
What the audit covers
Crawlability
We crawl the site the way Googlebot would, then compare that against your server logs where you can give us access. We’re looking for robots.txt rules blocking things you didn’t mean to block, redirect chains three hops deep, orphan pages, soft 404s returning a 200 status, and JavaScript navigation a crawler can’t follow. Crawl budget on a large site is finite, and a crawler spending it on faceted filter URLs isn’t spending it on your money pages.
Indexation
Crawlable and indexed are different problems. We reconcile your Search Console coverage data against our crawl: pages marked “Discovered — currently not indexed”, pages excluded by an unexpected canonical, noindex tags left on after a staging push, thin pages Google decided aren’t worth storing. The number that matters is indexed pages against pages you meant to publish. When it’s badly off, no amount of link building fixes it.
Core Web Vitals
We look at field data from the Chrome UX Report first, because that’s what Google actually uses, and lab data second to work out why. Largest Contentful Paint usually traces to an unoptimized hero image or a slow server response. Cumulative Layout Shift is nearly always images without dimensions or a late ad slot. Interaction to Next Paint is normally third-party JavaScript. Page experience is a light ranking factor — we’ll say that plainly — but it’s the difference between a visitor reading your page and bouncing back to the results.
Content gaps
We take the pages ranking in the top ten for your target queries and compare their coverage to yours: subtopics they answer that you don’t, questions they address, formats they use. Then we check your site for cannibalisation — two or three pages competing for one query, splitting signals, none winning. Gaps tell you what to write; cannibalisation tells you what to merge, usually the faster win.
Backlink toxicity
We review your referring domains for patterns that suggest a problem: sudden spikes from unrelated sites, sitewide footer links, anchor text that’s overwhelmingly exact-match commercial, expired domains rebuilt as private blog networks, directories with no standards. We don’t disavow reflexively — Google ignores most junk on its own, and an over-aggressive disavow file does real damage. We flag what looks deliberate and explain why.
Internal linking
Where does authority currently flow? We map internal links to find pages sitting five clicks from the homepage that shouldn’t be, important pages with two internal links while a privacy policy has 300, and anchors saying “click here” instead of what the page is about. Internal links are the cheapest ranking lever you own, and our guide to structuring internal links covers the approach.
What you receive
A findings document, not a data dump. Every finding is ranked by estimated impact against effort, so the first item is the thing to do first. Each names the exact URLs affected, states the fix in terms a developer can action, and estimates effort in hours or days.
You also get a one-page summary for whoever signs off the budget. No score out of 100 — those numbers are arbitrary, and they encourage fixing whatever moves the gauge rather than the rankings.
What a finding looks like in the report
Severity: High. Illustrative example only — not data from a real client.
Finding: Product category pages are canonicalised to a filtered URL variant. Roughly 40 URLs affected, listed in Appendix B.
Why it matters: Signals consolidate onto a filtered page that isn’t in your navigation, so the category page collecting your internal links can’t rank.
Fix: Set each category page’s canonical to its own unfiltered URL; noindex filter combinations beyond one facet.
Estimated effort: 3-5 developer hours, one template change.
How long does an SEO audit take?
Typically one to two weeks from the point we have access, depending on site size. A 200-page brochure site is faster than a 40,000-URL store with faceted navigation. The crawl takes hours; analysis takes the rest.
-
Access and scope
Search Console, analytics, and server logs if you have them. We agree which sections and queries matter before starting.
-
Crawl and data collection
Full crawl, index reconciliation, field performance data, backlink export, internal link map.
-
Analysis
The slow part. Every flagged issue is checked by hand, because crawlers throw false positives at a rate that would make the report useless.
-
Prioritisation and walkthrough
Findings sorted by impact against effort with URLs attached, then a call with whoever implements the fixes.
Why we ask you to run this before buying links
Here it is without hedging: if the page you’re pointing links at can’t be crawled, isn’t indexed, or doesn’t cover the topic well enough to compete, links are wasted money. Not less effective. Wasted.
A link insertion (also called a niche edit) passes authority to a URL. If that URL carries a canonical to another page, the authority goes elsewhere. If it’s noindexed, nothing happens. If it’s crawlable but 400 words against competitors running 2,000 with original data, the link improves a page that still loses.
We sell links. Telling you to spend elsewhere first costs us revenue, and we’d still rather do it than take an order for a page that can’t convert it into rankings.
| Scenario | Audit first, then links | Links first, audit later |
|---|---|---|
| Where the first spend goes | Finding what blocks the page from ranking | Referring domains pointed at the current page |
| If the page is technically fine | Small delay; audit cost spent confirming it | Works as intended — the case where skipping the audit pays off |
| If the page is noindexed or canonicalised away | Caught before you spend on links | Every link bought until the problem surfaces does nothing |
| If content coverage is the real gap | Rewrite first; links then amplify a page that can compete | Links push a page that still ranks behind deeper competitors |
| What you learn either way | Which lever was holding you back | That something isn’t working, but not which thing |
That’s reasoning, not a measured study. But the failure mode is common enough that we’d rather check first. Our notes on judging whether a link is worth buying and how many links a month is sensible both assume a sound target page.
SEO audit FAQ
Do you need admin access to my site?
No. Read-only Search Console and analytics access is enough, plus server logs if you can export them. We don’t need CMS logins and we don’t make changes — the audit is diagnosis; fixes are handled separately.
Will an audit tell me how many links I need?
It’ll show where you stand against the sites currently ranking, including their referring domain counts. That’s a range, not a target. Anyone quoting an exact number is guessing, and a site below roughly DR 20 has bigger problems than link volume.
What if the audit finds nothing serious?
That happens, and it’s a useful result — the constraint is content or authority, not technical. We’ll say so and point you at the placement service rather than inventing problems to justify the invoice.
How often should I re-audit?
Once a year for a stable site, or after any migration, replatform or major template change. Those events cause most of the technical damage we find. Monthly audits are a subscription product, not a need.
Can I run an SEO site audit checklist myself?
Yes, and you should check the basics: search site:yourdomain.com, read the Search Console coverage report, run three key pages through PageSpeed Insights. That catches the worst problems in an afternoon. The hard part is deciding which of 200 flagged issues matter.
Where to go next
If you already know the technical side is sound, go straight to per-link pricing or the wider SerpInsight service list. If you’re not sure — most people aren’t — send us the domain and the pages you want ranking. We reply within 24 hours and we’ll tell you which you need.
How findings get prioritised
Every finding lands in one of four quadrants, plotted on estimated impact against implementation effort. The quadrant decides where it sits in the list and, more usefully, whether it appears in the list at all.
Effort here means developer time, not your time. A change that takes you five seconds to approve and your engineering team two sprints to ship is a big project, however small it looks in a report.
| Quadrant | Impact vs effort | Example findings | What we tell you to do |
|---|---|---|---|
| Quick wins | High impact, low effort | A noindex tag left on a template after a staging push. A 302 sitting on your highest-traffic redirect. Your main money page reachable in four clicks when three high-traffic guides could link to it directly. | Ship this week. These are usually one-line changes and they’re the reason the audit pays for itself. |
| Big projects | High impact, high effort | Faceted navigation generating tens of thousands of crawlable filter URLs. Three cannibalising pages that need merging and rewriting to match the depth of the current top ten. A client-rendered catalogue that needs server rendering. | Plan properly, scope with your developer, and expect a quarter rather than a sprint. Worth doing, but not worth starting badly. |
| Low priority | Low impact, low effort | Duplicate meta descriptions on paginated archives. Missing alt text on decorative images. A handful of 404s nobody links to and nobody visits. | Batch them into whatever maintenance work is already happening. Never let them displace a quick win. |
| Not worth doing | Low impact, high effort | Chasing a perfect Lighthouse score on a site whose field data is already passing. Disavowing scraper links. Rewriting every URL slug sitewide to include a keyword. | We name these explicitly and explain why we’re not recommending them, because someone will suggest them later. |
That last row is deliberate. An SEO audit service that only lists things to do hands you a backlog with no ceiling. Telling you what to leave alone is the harder half of the judgement, and the sitewide URL rewrite is the one we argue about most — it’s a lot of redirect risk in exchange for a signal Google has said very little about.
What can an SEO audit not tell you?
It cannot predict rankings, it cannot see what your competitors spend, and it cannot fix a product nobody wants. Those three limits cover most of the disappointment people carry out of audits, so they’re worth stating before you commission one rather than after.
It can’t forecast where you’ll rank
An audit describes constraints. It can tell you a page is blocked from indexing, or that it covers six of the twelve subtopics the current top ten cover. It cannot tell you that fixing those things puts you at position four by November. Anyone producing that forecast is extrapolating from a model of an algorithm they haven’t seen, on a results page that changes weekly, against competitors who are also working.
It can’t see competitors’ budgets or intentions
We can count a competitor’s referring domains and read their anchor distribution. We can’t see what they’re paying, what’s contracted for next quarter, or whether the fifty links that appeared in March were a one-off campaign or the new baseline. Current state is observable. Spend and intent aren’t. Any competitive section that reads as though it is should be treated with suspicion, including ours.
It can’t rescue a weak offer
Search rewards pages that satisfy the person who clicked. If your pricing is uncompetitive, your delivery time is twice everyone else’s, or the page asks for a phone number before it explains anything, no technical fix touches that. An audit can tell you your bounce-back-to-results behaviour looks bad on commercial queries. Whether that’s a title tag problem or a business problem is a judgement we’ll give you honestly and can’t measure for you.
The crawl setup, and why raw and rendered HTML get compared
How a site gets crawled changes what the crawl finds, so the configuration is part of the method rather than a detail.
-
Two user-agents, on purpose
We crawl once with a mobile user-agent, because mobile-first indexing means the mobile rendering is the one that counts, and once as a desktop client. Where the two disagree — content hidden on mobile, different internal links in a collapsed menu — that difference is itself a finding.
-
A pass declaring Googlebot
We also run a limited pass identifying as Googlebot and compare the responses to our normal crawl. If the server returns different HTML, different status codes or different canonicals to a crawler that says it’s Google, we want to know, because that’s differential serving and it’s usually accidental — a CDN rule or a bot-mitigation product doing something nobody documented.
-
Rate limits agreed in advance
We ask for our IP to be allowlisted and we agree a request rate with whoever runs the infrastructure. A crawler hitting a shared-hosting store at full speed either slows it down or gets blocked halfway through, and a half-finished crawl produces confidently wrong conclusions.
-
Raw response against rendered DOM
We fetch the raw HTML the server sends, render the same URL in a headless browser, and compare them. This is the check that catches the expensive problems.
-
Sitemaps crawled as a separate list
The XML sitemaps get crawled independently and diffed against the pages we reached by following links. Pages in the sitemap that no link points to are orphans; pages we crawled that the sitemap omits usually mean the sitemap is generated from stale data.
The raw-versus-rendered comparison deserves its own explanation because JavaScript-rendered content is where most modern technical problems now live. Google renders JavaScript, but rendering is a second pass on a queue, and anything that only exists after that pass is at best delayed and at worst missed.
What we look for in the diff: navigation links that exist only as click handlers rather than real hrefs, so no crawler can follow them. Pagination replaced by infinite scroll with no crawlable page-two URL. Canonical tags or meta robots injected or overwritten by client-side script, which is how a page ends up canonicalised somewhere nobody intended. Body content loaded into tabs or accordions only when clicked. Client-side 404s that render an error message while returning a 200 status, so Google files a few thousand error pages as real content. And consent or geo-gating scripts that block rendering entirely for a bot, leaving a page whose indexable content is a cookie banner.
What log files and Search Console show that a crawler can’t
A crawl tells you what’s possible. Server logs and Search Console tell you what Google actually did. That distinction is the whole value of asking for them.
Log files, where you can export them
Raw access logs are the only place you can see which URLs Googlebot requested, how often, and what status code it received — which is not always the status code you see, particularly behind a CDN with edge rules. We verify hits by reverse DNS before trusting them, because a meaningful share of self-declared Googlebot traffic is scrapers wearing the name.
What that reveals: crawl budget being spent on parameter URLs and filter combinations instead of your commercial pages. New URLs going undiscovered for weeks. A section of the site Google visits once a quarter, which explains why updates there never seem to take effect. Intermittent 5xx responses that were long gone by the time anyone looked. And the honest caveat — plenty of sites on managed hosting simply can’t produce usable logs, and we run the audit without them rather than making it a condition.
Search Console signals
- Page indexing reasons — “Crawled, currently not indexed” and “Discovered, currently not indexed” mean different things and point at different fixes.
- The crawl stats report — average response time, file types requested, and whether crawl purpose is discovery or refresh. A site where almost everything is refresh isn’t publishing anything Google considers new.
- Query data at page level, which shows what Google thinks a page is about — often not what you wrote it about.
- Impressions and average position by URL pattern, which locates decline in a section rather than a sitewide panic.
- Manual actions and security issues, which take about ninety seconds to check and change the entire shape of an engagement when present.
- Core Web Vitals field data grouped by URL pattern, which is real user measurement rather than a lab score.
Put together, these answer questions a crawler can only guess at. A crawler can tell you a page is indexable. Search Console tells you whether Google indexed it, and the logs tell you whether Google has been back since.
How often should a site be re-audited?
Most small sites need a full re-audit far less often than they’re sold one. Once a year is right for a stable site, and beyond that the trigger should be an event rather than a date on a calendar.
The reasoning is simple: technical problems don’t accumulate on their own. They arrive with deploys. A twenty-page consultancy site that hasn’t been touched since the last audit will have the same findings twelve months later, and re-running the crawl produces an invoice rather than information.
Re-audit when one of these has happened, regardless of how recently the last one was:
- A migration, replatform or domain change — before launch if possible, and again a fortnight after.
- A redesign or a template rebuild, which is a migration that nobody called one.
- A traffic drop that survives two weeks and isn’t explained by seasonality or a known update.
- A large content merge, prune or category restructure.
- A CDN, hosting or bot-protection change, which is how differential serving usually appears.
Between audits, monitoring does the job at a fraction of the cost. Check the page indexing report once a month, watch indexed-page count against pages you meant to publish, and set an alert on organic sessions. That’s twenty minutes and it catches the things worth catching. A large store deploying template changes weekly, or a publisher shipping hundreds of URLs a month, genuinely does need a shorter cycle — but the site that needs continuous auditing usually knows it, because someone there is already nervous about the last deploy.
What we hand over, and how to actually action it
The deliverable is a work queue, not a document. Findings arrive as a tracker — one row per finding, importable straight into Jira, Linear or a spreadsheet — with these fields: an ID, the area, the severity, the quadrant, the affected URLs, the fix stated as an instruction, the estimated developer hours, and empty columns for owner and target date.
Those two empty columns matter more than anything we write in the others. An audit with no owner per row becomes a file in a shared drive.
Why not a PDF
A PDF is read once, by one person, and then quoted from memory six months later. It can’t be filtered, sorted, assigned or marked done, and a developer can’t copy a canonical tag out of a page image. We’ll produce the one-page summary as a document because that’s what a summary is for. The findings themselves stay in a format your team can work from.
Alongside the tracker you get the specifics a developer needs rather than a description of them: the exact canonical URL each affected template should output, the exact robots directives, the redirect map as a CSV with source and destination columns, and example markup where the fix involves markup. If a finding can’t be stated that concretely, it isn’t finished and we don’t ship it.
Then a walkthrough call with whoever implements, not only whoever commissioned. Two things happen on that call every time: your developer explains why one of our fixes is harder than we estimated, and we re-sequence the list around it. Estimates written from outside a codebase are estimates.
Once the fixes deploy, we re-crawl the affected URLs and confirm in writing that each one shipped as specified. Fixes get half-implemented more often than they get ignored — a canonical corrected on one template and not its sibling, a redirect chained instead of pointed at the destination — and a silent partial fix reads as a failed recommendation.
If the audit comes back clean and the constraint turns out to be authority rather than anything on the site, the next spend is external links. Our explanation of how a link insertion works and the realistic account of how long placements tend to survive are the two things to read before buying any, and the placement service and per-link pricing cover the rest. Not sure which of the two you need — send us the domain and we’ll reply within 24 hours with an opinion rather than a proposal.
More audit questions
Do you need my server log files?
No, but they change what we can see. Logs are the only source for what Googlebot actually requested and what status code it got behind your CDN. Plenty of sites on managed hosting can’t export them, and we run the audit anyway — the crawl, index reconciliation and Search Console data still cover most findings. A week of logs is enough; a month is better.
Can you audit a site built in React or Next.js?
Yes, and JavaScript sites are where the crawl-versus-render comparison earns its keep. We fetch the raw server response and the rendered DOM and diff them, which catches links that exist only as click handlers, canonicals injected client-side, and client-side 404s returning a 200 status. Framework choice isn’t the problem; what the framework ships in the initial HTML is.
Can you audit a staging site before a migration goes live?
Yes, and pre-launch is the cheapest audit you’ll ever buy — a redirect map checked before launch takes hours, and the same map checked afterwards takes weeks of recovery. We need HTTP auth credentials or an IP allowlist, plus the old-to-new URL mapping. Budget a second short pass a fortnight after launch, because staging never quite matches production.