You can publish excellent content and still struggle in search if Google cannot crawl, render or index your pages properly. A technical SEO audit finds those hidden blockers: pages accidentally set to noindex, slow templates, duplicate URLs, broken redirects and missing structured data. This guide walks through the audit we run on business websites, in the order we run it, and shows you how to turn a long list of findings into a short list of fixes that actually move rankings.
What a technical SEO audit covers
A technical audit answers four questions about your site:
- Can search engines find your pages? (discovery: links, sitemaps)
- Can they crawl them efficiently? (robots rules, server responses, crawl waste)
- Can they render and understand them? (HTML, JavaScript, structured data, canonical signals)
- Do the pages give users a good experience? (speed, mobile usability, security)
It deliberately does not judge whether your copy is persuasive or whether you target the right keywords. Those belong to content and keyword work. The technical layer is the foundation: if it is cracked, everything built on it underperforms.
Tools you need before you start
You do not need an expensive stack. For most business websites, this set is enough:
| Tool | What it tells you | Cost |
|---|---|---|
| Google Search Console | Indexing status, crawl errors, Core Web Vitals field data, manual actions | Free |
| Bing Webmaster Tools | Similar data for Bing, plus its own site scan | Free |
| A desktop crawler (e.g. Screaming Frog, Sitebulb) | Every URL, status code, title, canonical, redirect chain | Free tier or paid licence |
| PageSpeed Insights / Lighthouse | Lab and field performance data per page | Free |
| Rich Results Test and Schema Validator | Whether structured data is valid and eligible | Free |
| Server access logs | How bots actually crawl your site | Usually included with hosting |
If your site runs on a custom platform, ask your developer for read access to logs and the deployment configuration. Many of the most useful findings come from there.
Step-by-step: running the audit
Step 1: Check indexing in Search Console
Open the Pages report (page indexing) and look at two numbers: how many pages are indexed and how many are not. Then read the reasons. Common ones include:
- Excluded by noindex tag — fine for admin or thank-you pages, a serious problem for product or service pages.
- Crawled, currently not indexed — Google saw the page and decided it was not worth indexing. Often a sign of thin or duplicate content.
- Duplicate without user-selected canonical — your site is producing multiple URLs for the same content.
- Page with redirect and Not found (404) — usually harmless in small numbers, worth reviewing if they are growing.
Compare the indexed count with the number of pages you actually want in search. A big gap in either direction is your first lead.
Step 2: Crawl the site like a search engine
Run a full crawl with your desktop crawler. Set it to respect robots.txt and use a mobile user agent, because Google indexes the mobile version of your site. Export and review:
- Status codes: any 4xx or 5xx on internal links, and any redirect chains longer than one hop.
- Titles and meta descriptions: missing, duplicated or truncated.
- H1 tags: missing or duplicated across templates.
- Canonical tags: pointing to the wrong URL, to a redirected URL, or missing.
- Orphan pages: URLs in your sitemap that no internal link points to.
Step 3: Review robots.txt and XML sitemaps
Read your robots.txt line by line. It is surprisingly common to find a staging-era Disallow: / left behind, or rules blocking the CSS and JavaScript files Google needs to render pages.
Your XML sitemap should list only canonical, indexable URLs that return a 200 status. If it includes redirects, 404s or noindexed pages, it sends mixed signals. On larger sites, split sitemaps by type (pages, products, articles) so you can see indexing rates per section in Search Console.
Step 4: Check site architecture and internal linking
Important pages should be reachable within a few clicks from the home page. Look at click depth in your crawl data. If key service or category pages sit five or six levels deep, they receive less internal authority and get crawled less often.
Also check that navigation and important links are plain HTML anchor links, not JavaScript click handlers that crawlers may not follow.
Step 5: Test rendering and JavaScript
If your site relies on JavaScript to load content, use the URL Inspection tool in Search Console and view the rendered HTML. Confirm that your main content, links and structured data appear in the rendered output. Server-side rendering, which frameworks like Laravel provide by default, avoids most of these problems.
Step 6: Measure performance and Core Web Vitals
Look at the Core Web Vitals report in Search Console for field data from real users, then use PageSpeed Insights on representative templates (home, category, product or service, article). Focus on:
- Largest Contentful Paint (LCP) — usually hero images, web fonts or slow server response.
- Interaction to Next Paint (INP) — heavy JavaScript and third-party scripts.
- Cumulative Layout Shift (CLS) — images without dimensions, late-loading banners.
Fixes are often template-level, so one change can improve hundreds of pages. Our website speed optimization guide covers these in detail.
Step 7: Validate structured data
Run key templates through the Rich Results Test. Check that Organization, Product, Article, BreadcrumbList and FAQ markup (where relevant) is valid and matches what is visible on the page. Mismatched or misleading markup can be ignored or cause problems. For a deeper look, see our schema markup guide.
Step 8: Check duplicates, parameters and international signals
Look for the same content reachable at several URLs: with and without trailing slashes, with www and without, over HTTP and HTTPS, or with tracking and filter parameters. Each variant should redirect or canonicalize to one version.
If you serve multiple languages or countries, verify hreflang tags are reciprocal and point to indexable URLs.
Step 9: Review security and server health
Confirm the whole site loads over HTTPS with a valid certificate and no mixed-content warnings. In your server logs, look for frequent 5xx errors, slow time-to-first-byte and bots wasting crawl budget on endless filter or calendar URLs. Reliable hosting and server management is part of technical SEO, not separate from it.
Turning findings into a prioritized fix list
An audit that produces 300 line items and no priorities rarely gets implemented. Score each issue on two dimensions: impact (how many important pages it affects and how badly) and effort (developer time and risk).
A simple triage we use:
- Critical — blocks indexing of important pages (noindex on services, robots.txt blocks, broken canonicals, site-wide 5xx). Fix immediately.
- High — weakens many pages (slow templates, duplicate URL patterns, redirect chains, missing titles). Schedule in the next sprint.
- Medium — affects a subset of pages or rich result eligibility (invalid schema, orphan pages, thin tag archives).
- Low — cosmetic or marginal (slightly long titles, a handful of 404s from old external links).
Key takeaway: Fix what stops important pages from being crawled and indexed first. Speed and polish matter, but not if Google cannot see the page at all.
Common problems we find on business websites
After many years of auditing corporate, industrial and e-commerce sites, a handful of issues come up again and again:
- Leftover staging settings — noindex tags or robots blocks carried over at launch.
- Template duplication — every page sharing the same title or meta description because the CMS falls back to a default.
- Faceted navigation explosions — product filters generating thousands of near-identical crawlable URLs.
- Migration debris — old URLs returning 404 instead of redirecting after a redesign.
- Oversized media — uncompressed images and video backgrounds slowing every page.
- Plugin bloat — on WordPress sites, multiple plugins injecting scripts and conflicting meta tags.
Most of these are not difficult to fix once found. The difficulty is noticing them, which is why a regular audit is worth the time.
After the audit: monitor, do not just fix
Once fixes are deployed, request reindexing for the most important URLs, resubmit sitemaps and set a reminder to review Search Console in two to four weeks. Add basic checks to your release process so problems do not come back: a pre-launch checklist that verifies robots rules, canonical tags and noindex settings on every deployment.
Next steps
A technical SEO audit is most useful when someone can act on it. If you would like a second pair of eyes on your site, or a developer who can implement the fixes rather than just list them, DigiVort's SEO and content team works alongside our engineers on audits, speed work and migrations. You can describe your site and goals through our project wizard and we will suggest a sensible starting point.
