The technical SEO checks that actually move something

Run any crawler over a mid-sized site and it will return several hundred findings, colour-coded by a severity scale that knows nothing about your business. Somewhere in that list are three or four things that are genuinely costing you money. The rest is homework.

The skill in technical SEO is not finding issues. Tools find issues. The skill is deciding which ones to spend a developer sprint on, and being able to say why.

The question to ask about every finding

Before anything goes on a fix list, finish this sentence:

If we do not fix this, the specific consequence is __________.

If you can complete it — “these forty product pages will stay out of the index”, “the migration will drop the two hundred URLs that earn most of our organic revenue” — it is a real issue and you can defend the ticket.

If the honest ending is “our score in the tool stays lower”, it is not an issue. It is a measurement.

This single filter removes most of a typical audit, and it is the reason two auditors can look at the same crawl and produce completely different plans. The findings are the same. The judgement about consequence is not.

Before the list, the reason it is in this order.

Figure 1

Your server Revenue

1. 01 Discovered Google knows the URL exists. Fails when: nothing links to it and it is in no sitemap
2. 02 Crawled Googlebot fetched it. Fails when: blocked in robots.txt, or crawl budget is going elsewhere
3. 03 Rendered JavaScript executed, final content produced. Fails when: content only exists after JS, and the render queue is long
4. 04 Indexed Stored and eligible to appear. Fails when: judged duplicate, thin, or low value
5. 05 Understood Matched to the queries it answers. Fails when: the page hedges between two intents
6. 06 Ranked Placed high enough to be seen. Fails when: competitors answer the query better, or authority is missing
7. 07 Clicked, then converted A person arrives and does something. Fails when: the title misrepresents the page, or the page is slow

Most audits start at stage six, because that is where the anxiety is. The cheap wins are almost always earlier.

What follows is the shorter list — in the order I would work through it, because each one gates the next.

1. Are your commercial pages indexed at all?

Nothing else matters if the pages that make you money are not in the index.

The mistake is looking at the total number of indexed URLs, which is nearly always inflated by pagination, filters, tag archives and things nobody meant to publish. A site can show 40,000 indexed URLs and be missing a third of its product catalogue.

Do it the narrow way. Take the list of pages that actually matter — the commercial pages, the service pages, the category pages, the money pages, whatever they are for you — and check that specific list.

In Search Console, the Page Indexing report and the URL Inspection tool will tell you which are in, which are excluded, and why. That narrow list is also the one worth watching over time, for the reasons set out in the guide to telling whether SEO is actually working.

The exclusion reasons are where the diagnosis lives:

Fix the reasons, not the symptom. Resubmitting a URL that Google has deliberately declined achieves nothing.

2. Does your content exist before JavaScript runs?

Google can render JavaScript. It does not do so immediately, or reliably, or in unlimited quantity. Rendering sits in a queue behind crawling, and on a large site a meaningful share of your content can wait a long time in that queue or never get there at all.

The test takes thirty seconds. Open a key page, view source, and search the raw HTML for a sentence from the middle of your main content. Then do the same for your internal links. If the body copy and the navigation are not in the HTML that arrives from the server, they exist only after execution, and you are gambling.

This matters most for the things that are easiest to overlook:

• Product and pricing detail loaded from an API after paint
• Internal links inside interactive components — carousels, tabs, “load more” buttons, faceted navigation
• Content behind tabs or accordions that is injected on click rather than hidden with CSS

The fix is server-side rendering or static generation for anything that needs to rank, and real <a href> elements for anything that needs to be crawled. A <div> with a click handler is not a link, however much it behaves like one for a human. The same content has to survive a second set of crawlers now, which is a separate problem covered in the local SEO for AI search guide.

Checking the raw HTML is the easy half of this check

The view-source test above tells you whether content exists in what the server sends. It does not tell you whether Googlebot successfully rendered the version that depends on JavaScript to appear — and most generic checklists stop at the first test, leaving the harder failure mode unexamined.

Google’s current documentation on JavaScript processing describes the sequence as three distinct stages — crawling, rendering, indexing — and is explicit that rendering is a queue, not something that happens the moment a page is crawled. “Googlebot queues all pages with a 200 HTTP status code for rendering,” unless a robots directive says otherwise, and “the page may stay on this queue for a few seconds, but it can take longer than that.”

For a page whose critical content only exists after execution, that queue is the actual bottleneck a view-source check cannot see. The HTML you are inspecting is the pre-render version regardless of whether the render ever completed cleanly.

Two tools show you the render outcome rather than your assumption about it, and they are the two Google’s own documentation points to for this specific check. Its instruction is to “use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML.”

In Search Console’s URL Inspection tool, running Test Live URL and opening View Tested Page returns the raw HTML Googlebot received, the JavaScript console output, the resources that loaded and a screenshot of what its renderer produced. The Rich Results Test does the same job for a URL that isn’t in the index yet.

Compare either against the raw view-source output. Content or internal links present in one but absent from the other identify precisely what your JavaScript is costing you, rather than leaving it as a guess.

A handful of failure patterns turn up often enough to check for specifically, beyond the API-loaded content and click-injected links already covered above:

• Client-side redirects fired after render, using window.location rather than a server-side 3xx. A redirect that only exists after JavaScript executes competes with the render queue itself for reliability, on top of every other reason a JavaScript redirect is a worse choice than a server one.
• Content gated behind an interaction Googlebot’s renderer may not reliably simulate — a “load more” button, a scroll-triggered fetch, a hover state. If the content only appears after a user action, do not assume the renderer performed that action; verify it in the rendered output directly.
• A blocked or slow third-party script the main content depends on. If your critical content is fetched by a script that a slow CDN, an ad blocker equivalent server-side, or a timeout interrupts, the rendered snapshot can capture the page mid-failure — present in a browser a human is patiently waiting on, absent from the one-shot render Googlebot took.

3. How many URLs can be reached, and how many should be?

Crawl budget is widely over-discussed for small sites and genuinely under-managed on large ones. Google’s own guidance on it is considerably narrower than the folklore, and worth reading before anyone builds a sprint around the phrase.

Google names three cases: large sites of a million or more unique pages whose content changes moderately often, medium or larger sites of ten thousand or more unique pages whose content changes very rapidly, and sites with a large share of their URLs classified in Search Console as “Discovered — currently not indexed”. It calls the first two rough estimates rather than exact thresholds.

If you have a few hundred pages, skip this section. If you match one of those descriptions — and the third is the one sites qualify under without realising it — this may be the single biggest lever you have.

The failure mode is almost always the same: faceted navigation, sorting parameters, session IDs and pagination multiply a catalogue of 20,000 products into millions of crawlable URLs, none of which should rank. Googlebot spends its time there instead of on the pages you care about, and new products take weeks to get indexed.

The arithmetic is worth doing once, because it is always worse than people expect:

None of the last 26.98 million deserve to rank. All of them are crawlable if you linked them, and Googlebot has no way of knowing which ones you meant.

Get the real number, not the theoretical one. Crawl your own site with the same settings a search engine would use, and compare the URL count to the number of pages you actually intend to have. If the first is an order of magnitude larger than the second, you have found your problem.

Then reduce it, in this order of preference:

1. Do not generate the URL. Filters that produce no unique value should not be linked in a crawlable way at all.
2. Block the pattern in robots.txt. Cheap, effective, and stops the crawl before it starts. Remember that a blocked URL cannot be seen, so never block something you also need de-indexed.
3. Canonical the variants to the page they are variants of. Useful when the URLs must exist and are occasionally linked externally.
4. noindex the rest. The slowest option, because the page must be crawled to see the tag. Google’s crawl budget documentation advises against noindex for this purpose specifically: Google “will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.”

A small number of filter combinations genuinely deserve to be indexed — the ones with real search demand behind them, like a colour or size that people actually search for. Those are pages, and should be treated as pages, with their own copy and internal links — the same argument made at length about category pages being underbuilt. Everything else is noise.

4. What do your server logs say Googlebot is actually doing?

The migration checklist further down this page already treats server logs as one of several sources for a complete URL inventory. Outside a migration, they are usually the one source nobody consults at all — which is a waste, because a crawler report is a simulation and a log file is a record.

A crawler visits your site the way it thinks a search engine would: following links, respecting the settings you gave it, working from the outside. Your server logs show what Googlebot actually requested — every URL, every timestamp, every response code — with no simulation involved. The two disagree more often than most audits assume, and the disagreement is where the genuinely useful findings live.

Start with the aggregate view before the raw logs, if your site is verified in Search Console. The Crawl Stats report breaks Googlebot’s activity down by response code, by file type, by crawl purpose — Discovery, meaning a URL new to Google, against Refresh, a recrawl of one it already knows — and by which Googlebot variant made the request.

It is not URL-level detail, but it is free, requires no log access, and will often show the shape of a problem before the raw logs confirm the specifics: a spike in image or script requests relative to HTML, a response-code mix dominated by something other than 200s, or a host-availability warning worth chasing before anything else on this list.

Then, where the finding needs URL-level detail, go to the raw logs. Three things are worth looking for specifically, in this order:

1. Which URLs Googlebot actually visits, against which URLs you think matter. Export your priority list — the commercial pages, the ones with revenue attached — and check its overlap with what the logs show being crawled and how recently. It is common to find a priority page Googlebot has not revisited in months, sitting next to a low-value URL pattern it hits daily. A crawler report audits the site you built. The logs show the site Googlebot is actually experiencing, and the two are not always the same site.
2. Crawl frequency, grouped by page type rather than read one row at a time. A single URL’s crawl frequency tells you little. The same figure grouped by template — every product page, every location page, every blog post — tells you whether Googlebot is treating a whole category of your site as worth revisiting often, occasionally, or essentially never. A commercial template crawled less often than a legacy content template is a finding a crawl report will not produce, because a crawler has no concept of frequency at all — it only ever takes one pass.
3. Wasted activity concentrated in a URL pattern the crawler report never generated. Filter, sort and session-parameter variants are exactly the pattern a standard crawl configuration is set up to avoid requesting, which means a crawler report can under-represent the very problem covered in the URL-count arithmetic above. The logs do not have that filter. If a single parameterised pattern accounts for a large share of total crawl requests, that is the wasted crawl budget the arithmetic upstream predicted in theory, now confirmed in the one dataset that shows what actually happened rather than what should happen.

Verify you are reading real Googlebot traffic before drawing conclusions from any of it. The user-agent string is trivially spoofable, and plenty of scrapers do exactly that. Google’s own verification method is a reverse DNS lookup on the requesting IP, confirming the hostname is googlebot.com, google.com or googleusercontent.com, followed by a forward lookup on that hostname to check it resolves back to the same IP.

Most hosts retain a limited log window — often thirty to ninety days. That makes this a check worth scheduling on a recurring basis rather than treating as a one-off pull the one time a migration forces the issue.

5. Is there one page per intent, or four?

Cannibalisation is the most common finding that no crawler will hand you, because it is not a technical fault. It is an architecture fault, and it looks fine to a machine.

Symptoms: several URLs ranking and rotating for the same query, none of them well; a page that has never quite broken into the top ten despite obvious effort; two pages that were written eighteen months apart by two people who did not know about each other.

Find it by exporting your queries from Search Console and grouping by query rather than by page. Any query returning multiple URLs over time is a candidate. Which page should own which query is a business question before it is a keyword question, and answering it that way is what makes the consolidation decision straightforward.

The fix is a decision, not a redirect: pick the page that should own the query, make it comprehensively the best answer, and then consolidate the others into it with 301s. Merging content is usually better than deleting it. Rewriting one page to be twice as good beats having two pages that are each half as good, every time.

6. Do important pages look important?

Internal linking is the clearest signal you fully control about what matters on your own site, and most sites contradict themselves with it constantly.

Two checks.

Click depth. How many clicks from the homepage to your most commercially important page? If the answer is four or more, you are telling search engines it is peripheral. Anything that matters should be reachable in three, and the pages that matter most in one or two.

Internal links in. Count them, per page. It is common to find that a company’s highest-margin service page has six internal links pointing at it while a two-year-old blog post has ninety, because the blog post happened to be in the footer for a while. Nobody decided that. It accumulated.

Both are fixable in a day of editorial work, and both are among the highest-return changes available on most sites, because they cost no development time at all. On a local business site, the pages that should be winning that internal-link budget are the service and location pages rather than the archive — the complete local SEO guide sets out which those usually are.

7. Is your structured data valid, and actually eligible for anything?

Most audits treat structured data as done once it validates. Validity, eligibility for a rich result, and a genuine match between the markup and what a visitor sees are three different things, and a crawler report typically checks only the first.

Two tools do the checking, and Google names both for this job. The Rich Results Test, run against a live URL or pasted code, validates the markup and shows exactly which rich result types the page currently qualifies for. Search Console’s Enhancements reports show the same picture at scale, across the whole site, plus any manual actions Google has applied.

Neither tool checks that the marked-up content is actually visible on the page. That check is manual, and it is the one most schema mistakes fail — a block of Review schema describing testimonials quietly removed from the page six months ago will still validate cleanly.

Two corrections are worth building into a technical checklist specifically, because a generic crawler will not know about either and will keep flagging the old advice as an opportunity:

• FAQPage stopped earning a rich result for essentially everyone in 2026. Google’s FAQPage documentation carries the deprecation notice: the feature stopped appearing in Google Search on 7 May 2026. A finding that says “add FAQPage schema” is chasing a rich result that no longer exists for the great majority of sites. It can still be worth doing for content structure, not for the result a checklist implies it will produce.
• A star rating on your own homepage, built from testimonials you curate, is not eligible for the review rich result — regardless of how correctly the markup is coded — because the entity being reviewed controls the reviews about itself. That eligibility belongs to independent third-party platforms, principally your Google Business Profile.

This site’s local business schema guide covers implementation and the current eligibility rules for every schema type a local business is likely to use, including both corrections above in full.

The point worth carrying into a technical audit specifically is that “schema is present” and “schema is doing something” are different findings, and a crawler report conflates them by default. Applying the same test from earlier in this piece is enough to sort them: a schema error that blocks eligibility on a commercial page has a completable consequence. A missing FAQPage block chasing a rich result that was retired in 2026 does not.

Worth knowing while deciding how much of an audit to spend here: Whitespark’s 2026 Local Search Ranking Factors survey, the same expert panel behind this site’s local SEO statistics, scored on-page schema markup in the bottom third of the 187 factors its 47 practitioners rated for local pack impact.

That is a panel’s aggregated judgement rather than a measured test, and it says nothing about eligibility for a rich result, which is a separate question schema still answers well. But it is a reasonable check on how much time a technical sprint should spend chasing schema perfection relative to the checks earlier on this list. Correct and valid is worth doing quickly; correct, valid and exhaustive is rarely worth doing first.

8. Core Web Vitals: in the field, not the lab

Core Web Vitals are a confirmed ranking factor, and a small one. They are worth getting right anyway, mostly for reasons that have nothing to do with rankings.

The thresholds, at the 75th percentile of real users:

The distinction that matters: field data, not lab data. A performance tool run from a fast machine on a fibre connection will give you a lab score, which is useful for diagnosis and worthless as a measure of reality. What counts is the Chrome User Experience Report data — actual measurements from actual visitors on actual devices — which you will find in the Core Web Vitals report in Search Console.

INP is where most sites now fail, and it is the one people miss, because it replaced First Input Delay on 12 March 2024 and measures something much harder: responsiveness across the whole visit rather than at first interaction. Heavy third-party scripts, oversized event handlers and long tasks on the main thread are the usual culprits.

Be honest about the commercial case. The ranking effect is marginal. The conversion effect is not. A checkout that jumps under someone’s thumb, or a page that takes four seconds to respond to a tap, loses customers you have already paid to acquire — and that loss is far easier to measure than a ranking tweak. It is the same argument the local website conversion guide makes at length about everything else on the page.

What “passing” actually means across the web right now

It is worth knowing the population-level baseline before judging a single site against it, and the current figure is easy to misquote. 55.7% of origins Chrome tracks passed all three Core Web Vitals thresholds in the July 2026 Chrome UX Report — Google’s own real-user data, up from 51.3% eighteen months earlier.

That number gets repeated constantly, and it is usually repeated wrong. It blends every device Chrome tracks into a single figure, so it is not a description of the mobile experience specifically, however often it is quoted as one.

The mobile-only, per-metric picture is less flattering and more useful for diagnosis. Across 2025, HTTP Archive’s Web Almanac performance chapter found 62% of mobile pages had good LCP, 77% good INP, and 81% good CLS.

LCP is consistently the weakest of the three by a wide margin, and on more than three-quarters of mobile pages the LCP element is an image. A slow hero image is not incidentally related to a failing LCP score. For most sites, it is the LCP score.

There is a genuinely useful, non-obvious finding sitting inside the same dataset, split by CMS platform rather than by device: the platform a site is built on predicts its Core Web Vitals pass rate almost as reliably as anything else measurable at scale, before a single line of that site’s own content or code is considered.

WordPress — the platform the largest share of small and local businesses actually build on — sits second from the bottom of the ten major platforms HTTP Archive’s CMS chapter tracks, across a sample of nearly 4.9 million origins.

That is not a verdict on any individual WordPress site. The platform’s own pass rate has climbed substantially since 2023, from 28% to 45%, and plenty of individual sites beat their platform’s average through disciplined theme and plugin choices.

It is a starting position, not a life sentence, and it is worth checking before assuming a slow site is a content or hosting failure unique to that business rather than a pattern shared with millions of sites built the same way. The full platform table, the mobile-versus-desktop trend since 2021, and the page-weight data behind the LCP finding above are on this site’s page speed statistics page.

9. Will your next migration cost you a quarter?

More organic revenue is destroyed by badly executed migrations than by any other technical event. Redesigns, replatforms, domain changes, “just tidying up the URL structure” — all of them.

The requirements are unglamorous and non-negotiable:

• A complete inventory of current URLs from every source: your crawler, Search Console, analytics, server logs, and your XML sitemaps. Any one source alone will miss URLs that still earn traffic.
• A one-to-one redirect map, tested in staging before launch. Not a blanket redirect to the homepage: Google’s site move documentation is explicit that redirecting many old URLs to one irrelevant destination “can confuse users and might be treated as a soft 404 error”, and it throws away every signal the old page had.
• A decision for every page, including the ones you plan to remove. Deliberately retiring a page is fine. Discovering after launch that it 404s is not.
• Monitoring for a month afterwards — indexation, rankings on your priority query set, and 404s in the server logs. Deciding in advance which numbers count as a successful move is the harder half; the local marketing measurement guide covers how to set that up before the launch rather than after it.

This is the check that pays for the entire audit, because it is the only one where the downside is measured in quarters rather than percentage points.

A worked example: three hundred flagged issues, five that matter

The scenario below is illustrative — a plausible, invented mix of the kind of findings a crawl produces on an ordinary site, not a real audit. The point is the triage logic from earlier in this piece, applied end to end, not the specific numbers.

Take a hypothetical local services business with roughly forty location pages, a blog running to a few hundred posts, and a faceted service-area filter added eighteen months ago. A standard crawl returns a little over three hundred findings. Run each through the test from the opening of this piece — if we do not fix this, the specific consequence is __________ — and most of them fail to complete the sentence.

Five fixes, out of roughly three hundred findings. Two of the five — the rendering gap and the log-file finding — exist entirely outside what a standard crawler report can see, which is the reason checks 2 and 4 earn a place on this list rather than being treated as optional extras.

The other 95% of the report is not wrong, exactly. It is undifferentiated, and shipping it as a sprint would have fixed forty trivial things and moved nothing that a customer, a ranking, or a pound of revenue would ever notice.

The list you should also write

Alongside the fix list, write a second, shorter list: the things you have deliberately decided not to fix, and why.

Missing alt text on decorative images. Duplicate meta descriptions on paginated archives. A handful of 302s that should be 301s on pages nobody visits. Every one of these will appear in a crawl report with an alarming colour next to it, and every one of them is fine.

That second list is what stops the same findings being re-raised every quarter by every new tool, and it is what lets you defend the work you did choose to do. A technical audit that produces three hundred tickets is not thorough. It is undifferentiated, and it will be ignored — usually right after the sprint where the team fixed forty trivial things and nothing changed.

Three fixes traced to a commercial page beat three hundred traced to nothing.

Where the list keeps coming back to rendering, template structure or a stack the fixes cannot reach, the honest conclusion is that the site is the problem rather than the tickets — which is a build question, not an audit one. The underlying numbers on what slow pages actually cost are on our page speed statistics page.

Questions

What is the most important technical SEO check?

Whether your commercially important pages are indexed. Nothing else in technical SEO matters if the pages that make you money are not in the index, and it is the one check that is fast, free and unambiguous. Use the Page Indexing report in Search Console filtered to the pages you actually care about, not the total URL count.

How many technical SEO issues should I fix from a crawler report?

Far fewer than the report lists. A crawl of a mid-sized site routinely returns hundreds of findings, most of which are severity labels applied without knowledge of your business. Fix the ones where you can complete this sentence: if we do not fix this, the specific consequence is X. If you cannot finish the sentence, it goes on a list, not into a sprint.

Do Core Web Vitals actually affect rankings?

Yes, but as a small factor, and only field data counts — the real measurements from Chrome users, not the lab score a tool gives you. LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 at the 75th percentile is the threshold. The larger commercial effect is usually on conversion rather than on position: slow pages lose people you already paid to acquire.

Does Google index JavaScript content?

It can, but rendering is deferred and not guaranteed at scale. Content that only exists after JavaScript executes is at the back of a queue, and on large sites a meaningful share of it may not be rendered promptly or at all. The test is simple: view the raw HTML source, or fetch the page with JavaScript disabled, and check whether your main content and internal links are present.

How do I know if a technical issue is worth fixing?

Trace it to a page that makes money. An issue affecting a commercial page or the crawl path to one is worth a sprint. The same issue on a tag archive from 2019 is worth deleting the archive. Severity labels in a crawler are generic; the cost of a finding depends entirely on which page it lands on.

How do I check what Googlebot actually rendered, not just what's in my page's raw HTML?

Use the URL Inspection tool in Search Console: run 'Test Live URL', then open 'View Tested Page' to see the rendered HTML and a screenshot of what Googlebot's renderer produced. The Rich Results Test does the same job for a URL that isn't indexed yet. Both are the tools Google's own documentation names for this specific check, and both show you the outcome rather than your assumption about it. Compare that rendered output against a plain view-source of the same page — content or links present in one but missing from the other identifies exactly what your JavaScript is hiding from the index.

What share of websites currently pass Core Web Vitals?

55.7% of origins Chrome tracks passed all three Core Web Vitals thresholds in the July 2026 Chrome UX Report, up from 51.3% eighteen months earlier. That figure is easy to misquote, because it blends every device into one number. The mobile-only, metric-specific picture is less flattering: 62% good Largest Contentful Paint, 77% good Interaction to Next Paint and 81% good Cumulative Layout Shift in 2025, per HTTP Archive's Web Almanac. LCP is consistently the weakest of the three on mobile, and it is very often a single hero image.

How do I validate structured data, and is a green result enough to trust it?

Run the URL through the Rich Results Test, and check the Enhancements reports in Search Console for the site-wide, ongoing view, including any manual actions. Neither tool checks that the content the markup describes is actually visible on the page — that check is manual, and it's the one most schema mistakes fail. A page can validate cleanly and still be marking up a testimonial section or FAQ block that doesn't genuinely match what's on the page, which is a different and more serious problem than a syntax error.

What is log-file analysis, and why doesn't a crawler report replace it?

A crawler simulates a visit to your site from the outside, following links the way it thinks a search engine would. Your server logs record what Googlebot actually requested, when, and how often — a different and more reliable source, because it shows real behaviour rather than a simulation of it. The two routinely disagree: a crawler report can miss URL patterns Googlebot is spending real crawl activity on, particularly parameterised and faceted variants a standard crawl setting won't request the way a search engine's crawler will.

Is FAQPage schema still worth adding as a technical SEO fix?

Not for a rich result — Google deprecated the FAQ rich result for essentially all sites, with it ceasing to appear in Search from 7 May 2026. A crawler report that still flags missing FAQPage markup as an opportunity is working from an out-of-date assumption, and fixing it will not produce the result the finding implies. It can still be worth adding for clean, self-contained content structure, covered in full on this site's local business schema guide, but it belongs on the 'nice to have' list, not the technical fix list.