Every few weeks the same document lands in our inbox: a forty-page PDF generated by a tool, listing 312 "critical errors", 1,400 warnings and a large red traffic light on the cover. The client is worried and wants to know where to start. The honest answer is almost always: with hardly any of them.
An SEO audit is not an inventory of defects. It is a prioritisation exercise. The question to answer is not "what is broken?" — something always is — but "what is stopping this site from winning more customers, and in what order do we fix it?". This article describes the process we run at ValenciaSEO, the logic behind each layer, and how to build the measurement side with tools that cost nothing, starting with the free Semalt stack.
Website problems stack in layers, and a broken layer invalidates all the work above it. Auditing out of order is the number one cause of audits that produce no results.
| Layer | Question it answers | If it is broken... |
|---|---|---|
| 1. Access | Can the crawler reach and read the page? | Nothing else matters. The page does not exist. |
| 2. Indexing | Has Google included it, and under which canonical URL? | The content exists but competes with itself or never surfaces. |
| 3. Performance | Does it load and behave reasonably well? | You lose clicks you already earned and degrade quality signals. |
| 4. Value | Does this page deserve to sit ahead of the other ten? | Everything technical is perfect and you still do not rank. |
Optimising content on a page blocked in robots.txt is 100% wasted work. So is improving Core Web Vitals on a duplicate that will never be canonical. Each layer assumes the one below it works.
The fastest layer to audit and the one that produces the biggest shocks. Four checks and you are done.
Sounds obvious; it is not. We find inherited staging blocks at least once every couple of months. The typical patterns: a Disallow: / that survived launch, blocks on asset directories that stop CSS and JS loading — so Google renders a broken page — and AI-crawler blocks copied from a template nobody consciously decided on.
You do not need to crawl all 4,000 URLs. Take the fifty that generate traffic or that you want to generate traffic, and confirm they return 200. The usual findings are redirect chains (301 to 301 to 301, diluting and slowing), 302s used where a permanent 301 belonged, and soft 404s: pages returning 200 while displaying "product unavailable".
If the main content is injected by JavaScript, confirm it exists in the served HTML or renders without user interaction. Quick test: disable JavaScript and see whether the text survives. If it disappears, you have work to do.
The decisive check is observational rather than theoretical: have the bots visited these URLs? The crawl log shows live GoogleBot, BingBot and OpenAIBot visits with their response codes. If a whole section of the site receives no visits, you know where the problem sits without speculating.
This is where most serious problems live on mid-sized sites, and where automated tools are least useful, because they do not understand the intent behind the business.
Area or service pages identical apart from a place name. Twenty URLs that, to the index, are one.
Filters, sorting and pagination generating thousands of variants that eat the crawl budget.
The most expensive case: good pages pointing at another URL, removing themselves from the index.
The practical diagnosis uses two numbers: URLs submitted in the sitemap versus URLs actually indexed. On a healthy local-business site that ratio exceeds 85%. At 45%, you do not have an isolated technical fault: you have content Google has seen and declined to include, which is a conversation about quality, not about tags.
Neighbourhood pages generated from one template with only the place name swapped. It is the most repeated local SEO tactic and one of the least effective today. If an area page contains nothing that applies only to that area — real references, travel times, cases, the particular character of its commercial fabric — it is not a page. It is a variable.
Web performance has become the area where the most budget is spent for the least return, because it is measurable, carries a numeric score and produces satisfying graphs. Worth putting in its place.
Performance affects rankings modestly and conversion considerably. In other words: it is worth fixing, for the right reason. Moving a lab score from 45 to 92 rarely moves positions; cutting the time until a user sees something useful from 6 seconds to 2.5 genuinely changes how many people stay.
Those three causes, by frequency: images neither compressed nor sized (the classic 3 MB JPEG in a header), third-party scripts — chat widgets, maps, ad pixels, cookie banners — blocking rendering, and web fonts loaded without a fallback strategy, leaving text invisible for seconds.
Our practical recommendation: measure with real user data rather than lab scores, and fix only what affects templates with traffic. Optimising the page of a discontinued product is entertaining and pointless.
Once the three layers below are reasonably sound — and on most sites they are, after a week of work — everything else is content. This is the part no automated tool can audit, and the part that determines the outcome.
We apply four questions to every important page:
Sort your pages by impressions and keep the top twenty. Apply the four questions to those only. On a typical thirty-to-two-hundred-page site, that is where 80% of the potential lives, and the exercise fits in a morning.
An audit without a baseline is a well-argued opinion. Before touching anything, freeze the current state — otherwise you will never separate the effect of your work from market noise.
The minimum we record before the first intervention:
| Data point | Source | What it is for afterwards |
|---|---|---|
| Clicks and impressions per URL, last 90 days | Search Console analytics | Isolating the real effect of each change |
| Positions across the target query set | Google SERP | Telling your movement apart from the market's |
| Bot visits by section | Indexing log | Confirming the layer 1 fixes worked |
| Presence in generated answers | AI Analytics | Measuring the layer Search Console cannot see |
| Submitted / indexed ratio | Sitemap versus index | Quantifying the layer 2 problem |
All five are free and take an afternoon to set up. The advantage of holding them in one account is not the saving: it is that they share a period and a domain, so when someone asks three weeks later "did this help?", the answer comes with a graph rather than a feeling.
A useful report fits in five pages and is organised by decision, not by error type. This is the exact structure we hand over:
One page of diagnosis. Which layer holds the main problem and why. No jargon, with the figure that proves it.
Three to five priority interventions. Each with: what gets done, how many hours it costs, what is expected to happen, and how we will verify it. If the last column cannot be written, the intervention does not make the list.
A maintenance list. Things that need fixing but are not urgent, to be worked through without blocking what matters.
An explicit list of dismissals. Items the tool flags red that we have decided not to touch, with the reason. This section prevents the awkward conversation three months later when someone runs the same scanner again.
If an audit you are handed has no dismissals section and no hour estimate per intervention, what you bought is a tool run, not an analysis. You could have generated that yourself in ten minutes.
A full audit every month makes no sense. The site does not change that much and the team burns out. Our calendar:
Full audit every 12 months, or whenever there is a redesign, migration or platform change. Layers 1 and 2 quarterly: they break on their own through deployments and plugin updates. Layer 4 on the top twenty pages every six months, because competitors publish and what was differentiating stops being so. And a continuous fifteen-minute weekly check on sharp drops, which is what prevents discovering a disaster three months late.
Search analytics, rankings, crawl log and AI visibility — all free, no time limit. It is the step that turns an audit into something verifiable.
Sign in to Semalt See plansBetween 8 and 20 hours for a site of up to two hundred pages, depending on how much digging layers 2 and 4 require. What takes an hour is a tool run, not an audit.
Yes, for layers 1 and 3, which are mechanical. Layer 2 requires understanding the business and layer 4 requires reading. No tool knows whether two of your pages compete for the same customer.
No. Only layer 1 and the serious layer 2 problems. The rest can run in parallel, and waiting for technical perfection is a common way to lose six months.
Layer 1: days, as soon as crawling resumes. Layer 2: two to six weeks. Layer 3: immediate on conversion, slow and modest on rankings. Layer 4: six weeks to several months.
It can, but it is guesswork. Third-party data estimates; Search Console measures. If someone audits without asking for access, they are working blind.
The difference between an audit that changes a business and a PDF that gets filed is not the number of checks. It is the order — layers, bottom up — and the discipline to dismiss. A report flagging three hundred problems forces the client to prioritise, which is precisely the work they were paying to delegate.
To start on your own, the order is: read your entire robots.txt, check the status of your top fifty URLs, calculate your submitted-versus-indexed ratio, and apply the four layer-4 questions to your twenty highest-impression pages. With the free analytics layer connected you also get the before and after, which is what makes the exercise demonstrable.
And if you would rather we ran it on your site, the initial audit is free and delivered within 48 hours, with all five sections described above — dismissals included. Get in touch and we will tell you frankly which layer your problem sits in.
Free analytics for Google Search, SERP rankings and AI answers - plus fast indexing for your new pages.
Sign in to Semalt semalt.comGet in touch for a free audit
