How to audit your website’s technical SEO: a step-by-step guide

01 / 08

What is a technical SEO audit, and why does a local business need one?

A technical SEO audit reviews the machine-facing foundations of your site: whether search engines can reach your pages, read them, index them, and understand them. It is separate from content and links. For a local business, a single technical fault, like a blocked page or a broken canonical, can quietly keep your best pages out of search while everything looks fine to visitors.

Search engines do three things before you can rank: discover your URLs, crawl and render them, and index the result. A technical SEO audit checks each stage for the faults that break it. None of it is about word count or keywords; it is about whether the pipeline that turns your site into search results is intact, because a page that never gets indexed cannot rank. These faults matter because they are invisible from the front end: your site looks perfect in a browser while a stray line in robots.txt blocks a whole section.

Work through the steps below in order and keep a running list of what you find, sorted by impact. Google publishes its own overview of these tasks in its documentation on maintaining a site (Google, 2026)^[1], and the free tools it provides, Search Console plus the URL Inspection and Rich Results tests, are enough to complete most of this audit. Fix the issues that block indexing first, then the ones that dilute or confuse it.

02 / 08

How do you check crawlability and your robots.txt?

Start at the front door. Open yoursite.com/robots.txt and read every Disallow line, because that file tells crawlers which URLs they may fetch. A single overly broad rule can hide entire sections. Then confirm the pages you care about are reachable by real links, not buried behind scripts or forms, so a crawler can actually discover them in the first place.

The robots.txt file lives at the root of your domain and controls crawler access. Google is explicit that it manages crawl traffic and is not a tool for hiding pages from search (Google, 2026)^[2]. Read yours line by line: a rule like Disallow: / blocks the whole site, and narrower rules can accidentally cover a /services/ path you want crawled. Remember its limits too. A disallowed URL can still be indexed if other sites link to it, and blocking a page in robots.txt prevents Google from seeing a noindex tag on it, so to keep a page out of the index, leave it crawlable and use noindex instead (Google, 2026)^[3].

Then check discoverability. Crawlers follow links, and Google can only follow a link that is a standard HTML anchor element with an href attribute (Google, 2026)^[5]. Navigation that only works through JavaScript, buttons, or on-hover menus can leave pages effectively invisible. Make sure every important page is reachable through plain, crawlable links, ideally within a few clicks of the homepage.

03 / 08

Is your site actually getting indexed?

Crawlable is not the same as indexed. Google Search Console’s Page Indexing report shows exactly which URLs are indexed and, for the ones that are not, why. This is the single most useful screen in the whole audit, because it tells you in Google’s own words where pages are being dropped, and the URL Inspection tool lets you check any single page live.

Open the Page Indexing report in Google Search Console. It lists which pages Google has indexed and groups the excluded ones by reason: crawled but not indexed, discovered but not indexed, blocked by robots.txt, duplicate without a canonical, redirect, soft 404, and more (Google, 2026)^[4]. Read the not-indexed reasons carefully, because each points at a specific fixable cause. For any single URL, the URL Inspection tool then tells you its current index status, which canonical Google chose versus the one you declared, and whether the live page can be indexed right now.

Set a simple expectation: the pages that should be indexed are, and the ones that should not be, like thank-you pages or thin tag archives, are cleanly excluded with noindex. A site with far more indexed URLs than real pages usually has a duplication or parameter problem generating junk. A site with far fewer indexed pages than it has content has a discovery or quality problem. Both show up here first.

04 / 08

Does your site architecture and internal linking help crawlers?

Site architecture is how your pages are organized and linked to each other. A shallow, logical structure, where important pages sit close to the homepage and related pages link to one another, helps both crawlers and visitors. Internal links are how discovery and authority flow through a site, so orphaned pages with no links pointing to them are a quiet, common problem.

Aim for a shallow hierarchy. The fewer clicks it takes to reach an important page from the homepage, the more easily it is discovered and the more clearly its importance is signaled. Group related pages into logical sections, for example a services hub that links to each service and each service linking back. Then hunt for orphan pages, URLs with no internal links pointing at them, which are hard for crawlers to find and read as unimportant. A crawl of your own site surfaces pages that exist in your sitemap but are linked from nowhere; give every page you care about at least one contextual internal link.

Use descriptive anchor text. Google treats the words inside a link as a signal about the destination, and advises against vague anchors like "click here" in favor of text that describes the target page (Google, 2026)^[5]. Link your service pages to each other where it helps a reader, and keep the anchors specific.

05 / 08

Are canonicalization and duplicate content under control?

Canonicalization is how you tell search engines which URL is the real version when the same content is reachable at several addresses. Duplicate content is rarely a penalty, but it splits signals and wastes crawl budget. The rel=canonical tag, consistent internal linking, and clean URL handling keep engines pointed at one authoritative version of each page.

Duplicates happen for ordinary reasons: http and https versions, www and non-www, trailing slashes, URL parameters, and printer-friendly pages. Google clusters URLs it considers equivalent and picks one canonical to index and show (Google, 2026)^[6]. You influence that choice but do not control it, so make your preferred version obvious everywhere. The main tool is the rel=canonical link element, which names the preferred URL: every page should declare a canonical, usually pointing to itself, and duplicate variants should point at the primary version.

Google treats the canonical tag as a strong hint rather than a directive (Google, 2026)^[6], so reinforce it: link internally to the canonical version only, and make sure your sitemap lists canonical URLs, not duplicates. A templating error that puts the homepage canonical on every page tells Google your whole site is one page. Self-referencing canonicals on unique pages, plus one consistent choice of https and www or non-www site-wide, resolve most duplicate-content confusion before it starts.

06 / 08

How do you find broken links and fix your redirects?

Broken links waste crawl budget, frustrate visitors, and strand any authority pointing at a dead URL. Redirects are how you move a page without losing its value, but only when they are done cleanly. Audit for 404 errors and for redirect chains, then make sure every moved or removed URL resolves to the right destination in one hop.

Find your broken links first. A site crawler, or the Page Indexing report’s not-found bucket, will list URLs returning 404 status codes. Some 404s are fine and expected. The ones that matter are internal links pointing at dead pages, and external backlinks aimed at URLs you have since moved or deleted, because those are inbound value leaking away. Repoint internal links to live pages, and redirect valuable dead URLs to the closest replacement.

Use the right redirect type. A permanent move should return a 301 (or 308) status, which Google uses as a strong signal that the target should become canonical and which passes ranking signals along (Google, 2026)^[7]. Reserve temporary redirects (302, 307) for genuinely temporary situations, and Google publishes how each status code affects its crawlers if you are unsure (Google, 2026)^[8]. Then collapse chains and loops, so every old URL reaches its destination in one hop. After a rebuild or a domain change this is where the damage usually hides, and it is the core of the work on our site migration services page.

07 / 08

Is your site mobile-friendly and served over HTTPS?

Google indexes the mobile version of your site, so mobile-friendliness is not optional. Check that pages render and function on a phone, with readable text and tappable controls. Separately, confirm your whole site loads over HTTPS with a valid certificate, because secure serving is both a baseline trust signal and a lightweight ranking factor Google has confirmed.

Google uses mobile-first indexing, meaning it predominantly crawls and indexes the smartphone version of your content (Google, 2026)^[9]. If your mobile site hides content that exists on desktop, or is hard to use on a small screen, that gap is what gets indexed. Load your key pages on an actual phone and check that the main content is present, text is legible without zooming, and tap targets are not cramped. This overlaps with site speed and Core Web Vitals, a topic large enough to deserve its own treatment, so we cover performance in depth elsewhere and our mobile SEO work goes deeper on the mobile experience specifically.

On HTTPS, confirm every page loads over https with a valid certificate, and that http requests redirect to the https version. Google announced years ago that HTTPS is a lightweight ranking signal and encourages secure serving (Google, 2014)^[10], and modern browsers flag insecure pages to visitors. Watch for mixed content, where a secure page loads an image or script over http, because it undermines the padlock and can break the page.

08 / 08

Are your structured data and XML sitemaps set up correctly?

Structured data describes your business to engines in a machine-readable format and can make pages eligible for richer results. An XML sitemap lists the URLs you want crawled and helps engines discover them. Neither is a ranking lever you turn up, but both help engines find and understand your pages, and both are easy to validate for free.

Structured data, written as schema.org markup, gives engines an explicit description of your pages instead of leaving them to infer it from copy (Google, 2026)^[11]. For a local business the foundation is LocalBusiness markup with your name, address, phone, and hours. That topic has its own depth, so we keep this to the audit step: confirm your markup exists in the raw HTML, is valid, and matches what is visible on the page. Validate it with the Schema Markup Validator and Google’s Rich Results Test. Our ultimate guide to local business schema covers the implementation in full, and our schema markup services page covers the hands-on work.

Your XML sitemap should list your canonical, indexable URLs and nothing else, no redirects, no 404s, no noindexed pages. Google recommends sitemaps especially for larger sites and newer sites with few external links (Google, 2026)^[12]. Submit it in Search Console and check the sitemap report for read errors. A sitemap full of junk URLs sends mixed signals; a clean one is a straightforward map of what you want indexed.

Neither structured data nor a sitemap is a ranking lever: both simply help engines find and understand your pages, which is the whole aim of a technical audit. Then fix your findings by impact: anything that blocks indexing first, like a robots.txt block, a stray noindex, or a 404 on an important page, then the issues that dilute signals, like redirect chains and duplicates, and cosmetic warnings last. If you would rather have this run for you and the fixes implemented, that is what our technical SEO services cover, starting with a free audit.