Technical SEO audit checklist: what to check and how to fix it

How to use this technical SEO checklist

Technical SEO is everything that affects whether search engines can crawl, render, index and understand your site, separate from what the words on the page say. Most small business sites don't need advanced work here. They need the basics checked and the handful of real problems fixed.

This technical SEO checklist is in priority order. The early checks can stop a page appearing in Google at all; the later ones refine how it appears. Work down the list and stop to fix anything serious before moving on.

You'll need Google Search Console (free), PageSpeed Insights (free), access to your CMS, and a crawler that lists every URL on your site with its status code. If you want the wider picture first, start with our guide to doing a website audit. This checklist is the technical part of it.

The checklist at a glance

1. Robots.txt

Open yourdomain.com/robots.txt. It tells crawlers which parts of the site they may request.

• Look for Disallow: / (blocks everything) or rules that cover folders holding real pages, such as /services/.
• Don't use robots.txt to hide pages from Google. Google's documentation is clear that robots.txt manages crawling, not indexing: a blocked page can still be indexed if other pages link to it. To keep a page out of search results, let it be crawled and add a noindex tag.
• Reference your sitemap with a Sitemap: line. It's optional but helpful.

2. Noindex tags

A noindex tag (<meta name="robots" content="noindex"> or an X-Robots-Tag header) tells Google not to show the page.

• Check every key page with URL Inspection in Search Console. "Excluded by 'noindex' tag" means it's set.
• Check site-wide settings. WordPress has "Discourage search engines from indexing this site" under Settings, Reading. Other builders have a similar switch for unpublished sites. It's one of the most common reasons a new site never appears.
• Check SEO plugins for page types set to noindex by mistake, such as service pages built as a custom post type.

3. Indexing coverage

Open Indexing, Pages in Search Console. It shows how many of your URLs are indexed and lists the reasons the rest aren't.

Not every excluded page is a problem: redirects, deliberate noindex pages and duplicates with a correct canonical are meant to be excluded. Focus on your key pages and on statuses that suggest Google chose not to index something it could have, such as "Crawled, currently not indexed" on a service page. Our guide to the page indexing report explains each status and what to do.

4. XML sitemap

Your sitemap should list the pages you want indexed, and nothing else.

• No redirects, 404s or noindex pages in the sitemap. Each one sends a mixed signal.
• Submitted in Search Console, with status "Success" in the Sitemaps report.
• Within limits: a single sitemap can hold up to 50,000 URLs or 50MB uncompressed. Most small sites are nowhere near this.

See how to submit a sitemap to Google for the steps on each platform.

5. One version of the site

Type each version of your homepage into a browser: http://, https://, with and without www. All of them should end up at the same address through a single 301 redirect. If two versions both load, you've split your signals across duplicates.

6. Redirects

Redirects matter most after a redesign or URL change, which is exactly when rankings are most often lost.

• Use permanent redirects (301 or 308) for pages that have moved for good. Google treats them as a strong signal that the new URL should replace the old one in results.
• One hop only. A chain (A to B to C) slows users and crawlers, and every extra hop is another place for something to break. Point A straight at C.
• No loops (A to B to A), and no redirects to pages that return 404.
• Redirect to the closest equivalent, not everything to the homepage. Someone looking for an old service page wants the new service page, not your home page, and search engines read it the same way.
• Update internal links to point at the final URL, so your own site doesn't rely on redirects.

7. Broken links and images

A broken link points at a page or file that no longer exists and returns a 404 (not found) or 410 (gone). Broken links frustrate visitors, waste crawling and leak the value of links to pages that no longer exist.

How to find them:

• Run a crawler over the site and filter for internal links returning 4xx status codes. Most crawlers show the page each broken link sits on.
• In Search Console's Pages report, open "Not found (404)" to see URLs Google tried and failed to fetch.
• Check images too: a broken image shows an empty box or alt text in place of the picture.

How to fix broken links:

Fix links at the source rather than adding redirects for your own mistakes. A 404 for a page that genuinely doesn't exist is normal and doesn't harm your site. A custom 404 page with links to your main sections helps people who land there.

8. Canonical tags

A canonical tag (<link rel="canonical" href="...">) tells Google which URL is the main version when similar pages exist, such as the same page with tracking parameters.

• Each indexable page should point to itself, using its full, preferred URL.
• Duplicates should point to the original.
• Don't canonicalise to redirected or noindexed URLs.
• URL Inspection shows both your declared canonical and the one Google selected. If they differ on a key page, find out why: usually duplicate or very similar content.

9. Speed and Core Web Vitals

Core Web Vitals measure loading (Largest Contentful Paint), responsiveness (Interaction to Next Paint) and visual stability (Cumulative Layout Shift). Google's "good" thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less.

Check the Core Web Vitals report in Search Console for groups of URLs marked Poor or Needs improvement, then test example pages in PageSpeed Insights. Our guide to Core Web Vitals explains the common causes and fixes.

10. Mobile

Google uses the mobile version of a page for indexing and ranking. So the mobile page needs the same content, headings, structured data and links as the desktop page, not a cut-down version.

Use the key pages on a real phone, and check our mobile-friendly website check for the full list.

11. HTTPS

Every page should load over HTTPS with a valid certificate, and every resource on the page (images, scripts, fonts) should load over HTTPS too. A single http image creates "mixed content", which can trigger browser warnings. See site not secure for fixes.

12. Structured data

Structured data (usually JSON-LD) describes your page to search engines: your organisation, articles, FAQs, products, events and so on.

• Test it with Google's Rich Results Test and fix errors.
• Only mark up what's visible on the page. Google's guidelines require structured data to represent the page's actual content.
• Start simple: Organization on the homepage, Article on blog posts, BreadcrumbList site-wide.

13. Internal linking and site structure

• Key pages should be reachable within a few clicks of the homepage through normal links.
• Use real links. Google follows <a href> links; links that only work through JavaScript click events may not be followed.
• Find orphan pages: pages in your sitemap that no other page links to. Link them from relevant pages, or remove them if they shouldn't exist.

14. JavaScript rendering

If your site builds its content with JavaScript, check that Google sees it. In URL Inspection, run a live test and open "View tested page" to see the rendered HTML. If your main content, links or headings are missing, ask your developer about server-side rendering or pre-rendering for those pages.

After the audit

Record each finding with its impact and effort, fix the high-impact items first, and re-crawl to confirm. Then check Search Console over the following weeks: use URL Inspection to request indexing for important fixed pages, and watch the Pages report for the problem count to fall.