Technical SEO Audit Checklist: Fixing the Problems Content Can't Fix

A common pattern shows up on sites that have done everything "right" on the content side: well-researched articles, sensible keyword targeting, a decent link or two, and rankings that still don't move. The usual explanation isn't that the content is bad. It's that something underneath the content — how the page loads, how it's structured, whether search engines can even reach it cleanly — is quietly capping what the content can achieve. That's technical SEO: not a separate discipline from writing good pages, but the plumbing that decides whether a good page gets a fair chance.

This isn't a guide to becoming a developer. It's a checklist you can work through with free tools, understand what each item actually affects, and know which problems are worth fixing first. It builds on the fundamentals in our SEO for Beginners guide — if you haven't read that one, the on-page and keyword basics there come before most of what's below.

What technical SEO actually covers

Technical SEO is everything that affects a search engine's ability to crawl a page, render it correctly, understand what it's about, and decide it's trustworthy enough to show someone. None of it involves writing new content. All of it can quietly undo the content you already have. A page can be the best answer to a query on the internet and still rank behind a worse one if it loads slowly, returns the wrong HTTP status, or accidentally tells Google not to index it.

The good news is that technical SEO problems are usually binary — a page is either indexable or it isn't, a redirect either works or it doesn't — which makes them easier to diagnose than content quality. The bad news is that they're invisible unless you go looking, because nothing about a broken canonical tag shows up when you look at the page in a browser.

The three free tools this audit uses

You don't need a paid SEO platform to work through this checklist. Three free tools cover almost everything:

• Google Search Console. The single most important tool here. It shows exactly which of your pages are indexed, which are excluded and why, Core Web Vitals data pulled from real visitors, and any manual actions against your site. If it's not already installed, verify your domain and submit your sitemap before doing anything else.
• PageSpeed Insights (or Lighthouse in Chrome DevTools). Both run on the same underlying engine and report load performance, Core Web Vitals, and specific fixes for a given URL.
• A crawler. Screaming Frog's free tier crawls up to 500 URLs, which is enough for most small business sites, and surfaces broken links, missing titles, duplicate content, and redirect chains in one pass.

Crawlability and indexing: can search engines even find the page?

Before anything else, confirm search engines can reach and index your pages at all. This is the step most often skipped because it's easy to assume it's fine.

• Check robots.txt. Visit yourdomain.com/robots.txt and make sure it isn't accidentally blocking sections of the site that should be indexed. A single stray Disallow: / left over from staging can de-index an entire site.
• Confirm your XML sitemap exists and is submitted. It should live at a predictable location (commonly /sitemap.xml), list only canonical, indexable URLs, and be submitted through Google Search Console's Sitemaps report.
• Look for accidental noindex tags. Pages sometimes carry a <meta name="robots" content="noindex"> tag left over from development or a CMS default. Search Console's Page Indexing report flags these under "Excluded by 'noindex' tag."
• Review the Page Indexing report in full. It categorizes every URL Google has seen: indexed, excluded, or with warnings. "Crawled — currently not indexed" on important pages is worth investigating specifically — it usually means Google saw the page and judged it not worth indexing, which is often a content-quality signal, not a purely technical one.

Site speed and Core Web Vitals

Core Web Vitals are three specific, measurable aspects of page experience that Google uses as a ranking signal, and that real visitors feel even when they can't name them. They matter more for competitive queries, where content quality between the top few results is close and Google has said page experience helps break ties.

Metric	What it measures	Good threshold
LCP (Largest Contentful Paint)	How long until the largest visible element (usually a hero image or heading) finishes loading	Under 2.5 seconds
INP (Interaction to Next Paint)	How responsive the page feels when someone clicks, taps, or types	Under 200 milliseconds
CLS (Cumulative Layout Shift)	How much visible content jumps around as the page loads	Under 0.1

The most common fixes for small business sites, in order of typical impact:

1. Compress and resize images. A 4000px-wide photo displayed at 800px wastes bandwidth and load time on every visit. Resize to the actual display dimensions and export at a reasonable compression level before uploading.
2. Reserve space for images and ads. Layout shift usually comes from an image or ad slot that loads after the surrounding text, pushing everything down. Setting explicit width and height attributes (or a CSS aspect-ratio) reserves the space in advance.
3. Cut third-party scripts you don't need. Every chat widget, tracking pixel, and embedded video adds load time. Audit what's actually installed on the site and remove anything left over from a tool you stopped using.
4. Use a caching or hosting layer built for speed. If the underlying host is slow, no amount of front-end optimization fully compensates. A CDN and server-side caching typically produce the largest single improvement on a slow site.

Fix the pages that matter most first — your highest-traffic and highest-intent pages — rather than chasing a perfect score sitewide.

Mobile-friendliness

Google indexes and ranks based primarily on the mobile version of a page, not desktop, which means a site that looks fine on a laptop but breaks on a phone is being judged by its broken version. Check for: text that requires zooming to read, buttons or links spaced too close together to tap accurately, content that overflows the viewport and forces horizontal scrolling, and pop-ups or interstitials that cover the main content on load. Testing on an actual phone catches problems that a resized browser window sometimes hides.

URL structure and canonicalization

Canonicalization tells search engines which version of a page is the "real" one when duplicates or near-duplicates exist — a common and mostly invisible source of wasted crawl budget and diluted ranking signals.

• Every page should have exactly one canonical URL. If both https://example.com/page and https://example.com/page/ (with a trailing slash) return content without redirecting to a single version, that's a duplicate the site is creating for itself.
• Set a self-referencing canonical tag on every indexable page. <link rel="canonical" href="..."> pointing to the page's own preferred URL removes ambiguity, even when there's no obvious duplicate yet.
• Watch for parameter-based duplicates. URLs with tracking parameters (?utm_source=..., ?ref=...) or filter/sort parameters on category pages can generate hundreds of near-identical URLs that dilute the canonical page's authority if not handled with canonical tags.
• Keep URLs stable. Changing URL structure without redirects breaks every inbound link and every ranking signal built up under the old address. If a URL must change, a 301 redirect from the old to the new is mandatory, not optional.

Structured data and schema markup

Structured data is a standardized way of labeling content (Article, Product, FAQ, LocalBusiness, BreadcrumbList, and dozens of other types) so search engines can understand it with certainty rather than inferring it. It doesn't directly boost rankings, but it's what makes rich results possible — star ratings, breadcrumbs in search results, FAQ dropdowns — which can meaningfully improve click-through rate even at the same ranking position.

Start with whichever schema types genuinely match your content: Article schema for guides and blog posts, LocalBusiness schema for a physical location or service area, Product schema for anything sold directly, and FAQPage schema for pages that actually contain a question-and-answer format. Validate every implementation with Google's Rich Results Test before publishing — invalid or exaggerated structured data (marking content as a review when it isn't one, for example) risks a manual action rather than a reward.

Broken links and redirect chains

Run a full site crawl and look specifically for two problems: internal links pointing to pages that return a 404, and redirect chains where one URL redirects to a second URL that redirects to a third. Both waste crawl budget and pass along less authority than a direct link. Fix broken internal links by updating them to point at the current correct URL, and collapse redirect chains so every old URL points directly to its final destination in a single hop rather than through several intermediate steps.

HTTPS and basic security hygiene

HTTPS has been a baseline ranking factor for years and is table stakes at this point rather than an advantage — but it's still worth confirming the entire site enforces it. Check that HTTP requests redirect to HTTPS automatically, that the SSL certificate is valid and not close to expiring, and that no pages load mixed content (HTTP resources like images or scripts loaded on an HTTPS page), which browsers flag as insecure and which can break the padlock indicator visitors rely on for trust.

A step-by-step audit sequence

Work through a first technical audit in this order — each step depends less on the ones before it, so this sequence catches the highest-impact problems first:

1. Verify Google Search Console is installed and review the Page Indexing report for excluded pages.
2. Check robots.txt and confirm the XML sitemap is current and submitted.
3. Run PageSpeed Insights on your five highest-traffic pages and note any Core Web Vitals failures.
4. Test the site on an actual mobile device for layout and tap-target problems.
5. Crawl the site with a free crawler and export the list of broken links and redirect chains.
6. Spot-check canonical tags on your top 10 pages, including the homepage.
7. Validate any existing structured data with the Rich Results Test, and add Article or LocalBusiness schema if missing.
8. Confirm HTTPS is enforced sitewide with no mixed-content warnings.
9. Fix problems in order of pages affected — a sitewide issue (broken robots.txt, missing HTTPS redirect) always outranks a single broken link.

How often to re-run this

A full audit once a quarter is enough for most small business sites. The exception is right after any major change — a redesign, a CMS migration, a URL structure change, or a new hosting provider — all of which are the most common moments for technical SEO problems to get introduced. Check Search Console's coverage and Core Web Vitals reports monthly as a lighter ongoing check between full audits; both update automatically and take a few minutes to scan for new warnings.