Technical SEO checklist for business websites (36 checks)

A 36-point technical SEO checklist grouped by area, from crawling and indexing to speed, schema and hreflang, with how to test each check.

By Sohail Hussain29 October 20267 min read

Technical SEO is the work of making sure search engines can find, fetch, understand and rank your pages without obstruction. This checklist covers the 36 checks we run on a business website, grouped by area, with how to test each one. It is the audit behind our technical SEO and performance service. Work through it in order; the first two groups are where most lost traffic hides.

The reference for almost everything here is Google's own Search Central documentation, which is more useful and more current than most of what is written about it.

Can search engines crawl the site?

  1. robots.txt exists at the root and does not block pages you want indexed. Fetch yoursite.com/robots.txt. A Disallow: / left over from staging is the most expensive single mistake on this list. Test specific URLs with the robots.txt tester, and read robots.txt: what to block and what not to before editing it.
  2. robots.txt does not block CSS, JavaScript or image folders. Google renders pages; blocked assets mean a broken render and a worse assessment.
  3. The sitemap URL is declared in robots.txt with a Sitemap: line, so crawlers find it without Search Console.
  4. Crawl errors in Search Console are near zero. Open the Pages report and look at "Not found (404)" and "Server error (5xx)". A rising count after a change means broken links or missing redirects.
  5. Internal links use the final URL, not a redirect. Crawl the site and export links that return 301; fix the source link. Redirect chains waste crawl budget and leak signals; how to fix redirect chains covers it.
  6. No pages are orphaned. Every page you want indexed is reachable by at least one internal link. Crawlers find pages through links; a page only in the sitemap is a weak signal.
  7. Pagination and filters do not create infinite URL spaces. Faceted navigation, calendar pages and sort parameters can generate millions of URLs. Block or canonicalise them.

Is the site indexed the way you intend?

  1. No unintended noindex. Check the HTML meta robots tag and the X-Robots-Tag HTTP header on key pages. Staging sites are launched with it left on more often than anyone admits.
  2. The pages Google has indexed match the pages you want indexed. Compare the "Indexed" count in Search Console with your real page count. A large gap in either direction is a problem; why your pages are not indexed covers the usual reasons.
  3. An XML sitemap exists, is valid, and lists only indexable, canonical, 200-status URLs. No redirects, no noindexed pages, no 404s. Generate one from a URL list with the XML sitemap generator; XML sitemaps: what should be in yours explains the rules.
  4. The sitemap is submitted in Search Console and shows no errors.
  5. Thin, duplicate and expired pages are handled. Tag archives, empty categories, old campaign pages and test pages are either improved, redirected, noindexed or removed. Duplicate content: causes and fixes lists where it comes from.
  6. Search Console is verified for the exact property (domain-level, ideally) and someone looks at it monthly. How to use Google Search Console covers what to look at.

Does every page have one URL?

  1. One protocol and one host. http://, https://, www and non-www all resolve, with one hop, to a single canonical version. Test with curl -I on all four.
  2. Trailing slashes and letter case are consistent. /about/ and /about should not both return 200. Pick one; redirect the other.
  3. Every indexable page has a self-referencing canonical tag, and paginated or parameterised variants point to the right canonical. Canonical tags explained covers the edge cases.
  4. Redirects are 301 (or 308) for permanent moves and point directly at the final URL. Audit after any migration; 301 vs 302 redirects explains which to use. The redirect generator produces the rules from a list of old and new URLs.
  5. URLs are readable, lowercase, hyphenated and stable. No session IDs, no dates unless editorial, no capital letters.
  6. Custom 404 page returns a real 404 status, not a 200 with "page not found" text, which creates soft 404s.

Is the site fast and stable?

  1. Core Web Vitals pass in field data. The thresholds, from web.dev, are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile of real visits. Check the Core Web Vitals report in Search Console, not just a lab score. Enter your numbers in the Core Web Vitals checker to see pass or fail. Page speed vs Core Web Vitals explains what Google measures.
  2. The largest element on each key page loads early. Hero images are preloaded or inlined, not lazy-loaded; fonts are preloaded with font-display: swap or similar.
  3. Nothing shifts after load. Images and embeds have width and height set; ads, banners and cookie notices reserve their space.
  4. JavaScript is not blocking interaction. Third-party scripts (chat widgets, tag managers, trackers) are deferred or loaded after interaction. Count them; more than five is usually too many.
  5. Pages are served compressed, over HTTP/2 or HTTP/3, from a CDN. Check response headers for content-encoding and the protocol in browser dev tools.
  6. The site renders correctly on a phone and uses the mobile version for indexing. Google indexes the mobile version; content hidden on mobile is content Google may not count.
  7. Images are compressed and served in modern formats (WebP or AVIF) at the size they are displayed, not at the size they were uploaded. The image compressor handles batches in the browser; image SEO: formats, sizes, alt text covers the rest.

Can search engines understand the pages?

  1. Each page has a unique title of roughly 50 to 60 characters and a description of 120 to 155. Longer titles are truncated in results. Check lengths with the meta title and description length checker.
  2. One H1 per page, matching the page's purpose, with H2s that describe sections. Headings are read as structure, not decoration.
  3. Organisation (or LocalBusiness) structured data is on the site, with logo, contact details and social profiles, and validates in Google's Rich Results Test. Structured data: which types matter ranks them.
  4. Article, Product and Breadcrumb schema are added where the content type exists; FAQ schema is optional. Google stopped showing FAQ rich results on 7 May 2026, so FAQPage JSON-LD no longer changes how a result looks, but it is still valid and cheap to add with the FAQ schema generator. How to add FAQ schema covers placement and when it is still worth it.
  5. Open Graph and Twitter card tags are set, so shared links show a title, description and image.
  6. Internal linking reflects the site structure. Important pages are within three clicks of the homepage and receive more internal links than minor ones. Site architecture and internal linking covers the method.
  7. Every meaningful image has descriptive alt text, and decorative images have empty alt attributes.
  8. PDFs and downloadable files that should not rank are blocked or noindexed, and the ones that should have readable titles.

Is the international and local setup correct?

  1. Multilingual sites have hreflang tags on every page, listing every language version plus x-default, with each version pointing back. Build the set with the hreflang generator. One-directional hreflang is ignored.
  2. Local businesses have a complete Google Business Profile and matching LocalBusiness schema, with the same name, address and phone number on the site, the profile and major directories. Local business schema: a setup guide and Google Business Profile for local businesses are the two guides.

How should you work through the list?

Run groups one and two first, on the same day. A site that cannot be crawled or is not indexed has no SEO to speak of, and those problems are usually quick to fix once found. Group three, URLs and redirects, is next, because duplicate URLs split the signals every other check tries to strengthen. Speed, structured data and images follow; they improve a site that is already visible rather than rescue one that is not.

Record the state of each check in a spreadsheet with the date, the result and the URL you tested, so that the next run, after the next redesign, has a baseline. Most of the damage we repair was done during a redesign that nobody audited afterwards.

Two things this list does not cover, deliberately. It does not cover content: whether pages answer the questions people search for, whether they are better than the pages that currently rank, whether the site has anything worth linking to. And it does not cover links from other sites. Both matter more than any item above once the technical side is clean, and both are work we do not do; we fix the platform so that the content you write has a fair chance. For an overview of how much of search is changing with AI-generated answers, and what we are seeing in client data, AI Overviews and your traffic is the companion piece.

Was this guide useful?

Questions

Frequently asked.

How often should I run a technical SEO check?

Fully, after any redesign, migration or platform change, and once a quarter otherwise. In between, Search Console's Pages and Core Web Vitals reports show the problems that matter most, and a weekly glance at them catches a broken sitemap or a noindex left on before it costs much.

Which items matter most if I only have an hour?

Confirm the site is indexable (no stray noindex, robots.txt not blocking), one URL per page with the others redirecting, a valid sitemap submitted, pages passing Core Web Vitals, and mobile rendering correctly. Those five cover most of the traffic lost to technical problems.

Does technical SEO improve rankings on its own?

It removes what holds a site back. A page that is not indexed, loads slowly or exists at four URLs cannot rank as it should. Once the technical side is clean, rankings depend on content, relevance and links, which no checklist delivers.

Sohail Hussain

Founder, MSH Technologies

Sohail has designed and built websites, web apps and AI products for over 12 years, for clients from Singapore-based industrial groups to early-stage SaaS startups. He writes about what actually worked.

Keep reading

Related guides.

All posts

Your next move

Like what you see? Tell us about it.

A process that takes too long, a website that undersells you, or an idea ready to take shape. Tell us where you are and we will suggest a useful next step.

India · Working with clients worldwide

We reply within a working day. No spam, ever.