Technical SEO audit checklist: what to check and fix first

1. Collect the baseline without changing the site

• List the pages that should appear in search: services, relevant locations, guides and important products.
• Save the current sitemap, robots.txt, redirects, canonical tags and indexing rules. Back up configuration before editing it.
• Use Search Console's Page indexing and URL Inspection reports if you have owner-approved access. Separate the indexed URL Google selected from the canonical the page declares.
• Record the device, date, URL and evidence for each test. A crawler warning is a lead to investigate, not proof of lost traffic.

Without Search Console, you can inspect technical signals, but you cannot verify Google's current indexing decisions. A site: search is not a complete index report.

2. Check discovery, crawling and indexing separately

HTTP status

Important live pages should return 200. Fix unintended 5xx errors first. Removed pages without a relevant replacement should return 404 or 410, not redirect to the homepage.

robots.txt

Allow access to public content and the CSS or JavaScript needed to understand it. A disallow controls crawling; it does not reliably remove a URL from search.

Noindex

Inspect the HTML robots tag and the X-Robots-Tag response header. A crawler must be able to fetch a page to see its noindex instruction. Do not combine a robots.txt block with noindex and assume both will be processed.

XML sitemap

List canonical URLs you actually want indexed, not redirects, search filters or unfinished translations. Use genuine substantive modification dates when known; do not refresh dates on unchanged pages.

Internal links

Every important page needs a useful route from another page. Use descriptive, crawlable links to the final URL. A sitemap is helpful but does not replace navigation.

Keep a small test set: homepage, one service, one guide, a real missing URL, and each redirect pattern. Test complete redirect chains, not only the first response.

3. Give each useful page one preferred URL

Compare HTTP and HTTPS, www and non-www, trailing-slash forms, old extensions and tracking parameters. Permanent redirects, canonical tags, internal links and sitemap entries should agree on the preferred URL. A canonical is a signal; it does not force Google to select that URL.

Use a permanent redirect when a page has genuinely moved and its replacement meets the same intent. Do not canonicalise different services or different cities to one page merely because they share a layout. First decide whether each page offers distinct value.

Example, not a live result: if /service.php redirects to /service, the internal link, sitemap entry and canonical should all use /service. The final page should not then canonicalise back to the redirecting address.

4. Check what a visitor and a crawler can actually read

• Confirm that the main answer, headings and important links are available without a click that fetches the content. Compare source HTML and rendered HTML when JavaScript supplies important text.
• Use a real phone-width viewport. Check navigation, forms, horizontal overflow, readable text, keyboard focus and whether overlays obscure the answer.
• Give images descriptive alt text where useful and explicit dimensions. Supply appropriately sized image files; do not lazy-load the likely Largest Contentful Paint image.
• Validate structured data against the visible page. Valid JSON alone does not prove eligibility for a rich result. Never add invented reviews, branches, prices or credentials.
• Measure Core Web Vitals using field data where available. Google's good thresholds at the 75th percentile are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1. A single fast lab run does not prove a field-data pass.

Technical accessibility is also relevant to AI search. See the Google AI Overviews optimization guide for the distinction between eligibility and being cited.

5. Prioritise by affected intent, evidence and risk

1. Urgent: site-wide outages, accidental noindex or robots rules, and canonical errors affecting important pages.
2. Next: broken service links, redirect chains, duplicate URL patterns and missing rendered content.
3. Then: page-level metadata, image delivery and performance work backed by measurements.

Before a release, record the expected response, take a backup and decide how to roll back. Afterward, fetch the same URLs, check mobile output and inspect the sitemap again. In Search Console, request recrawling selectively after meaningful fixes; repeated submissions are not a ranking tactic.

Judge success with qualified enquiries as well as search metrics. For a business serving a local area, use the Karnataka local SEO checklist alongside this technical review.

Download a blank SEO audit issue log

Use one row per issue and representative URL. Keep response codes, canonical observations and the expected outcome together so somebody else can reproduce the test.

Download the blank CSV log

A header-only template. No email, account, tracking formula or example results are required.

Technical SEO audit questions

Primary sources and limits

• Google crawlers overview
• Canonical URLs and duplicate content
• Block indexing with noindex
• Build and submit a sitemap
• Core Web Vitals and Google Search

Tools expose different parts of the system. This checklist is not a substitute for inspecting your server, measuring your visitors or reviewing Search Console evidence.