The technical SEO checklist

Technical SEO is the part of the work that makes a site easy for Google to find, read, understand and trust. It is unglamorous and it is where most "we have great content but we do not rank" problems live. This checklist is the one we work through by hand in the free SEO audit and at the start of every technical engagement. Each check says what to look for and how to test it. You need a Search Console account, a crawler (there are free tiers), PageSpeed Insights and a browser.

A note on scale. Most London businesses have sites of 20 to 2,000 pages. At that size, crawl budget is not your problem: Google’s guidance on it is aimed at "Large sites (1 million+ unique pages)" and "Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)", and says that otherwise keeping your sitemap current and checking the Page indexing report "is usually enough" (Google Search Central). The checks below are the ones that matter at your size.

1. Crawling (checks 1 to 8)

Google describes robots.txt as a file that "tells search engine crawlers which URLs the crawler can access on your site", mainly to manage crawler traffic, and warns that it "is not a mechanism for keeping a web page out of Google" (Introduction to robots.txt). Sitemaps are limited to "50MB (uncompressed) or 50,000 URLs", the lastmod value "should reflect the date and time of the last significant update to the page", and "Google ignores <priority> and <changefreq> values" (Build and submit a sitemap).

1. robots.txt exists at the root and returns 200. Test: open yourdomain.co.uk/robots.txt.
2. robots.txt does not block CSS, JavaScript or image folders Google needs to render pages. Test: URL Inspection, view the rendered page and the "page resources" list.
3. robots.txt is not being used to hide pages that should be out of Google. Test: any Disallow line for a page you want excluded is a mistake; use noindex instead (check 12).
4. An XML sitemap exists, is referenced in robots.txt and is under 50MB and 50,000 URLs per file, with an index file if you need several. Test: open it; count.
5. The sitemap lists only canonical, indexable, 200-status URLs, and lastmod reflects real changes. Test: crawl the sitemap URLs and compare status, canonical and noindex.
6. The sitemap is submitted in Search Console and shows no errors. Test: Sitemaps report.
7. Every important page is reachable through ordinary HTML links (an a element with an href), within three clicks of the home page. Test: crawl depth report; orphan pages appear in the sitemap but not in the crawl.
8. The server answers quickly and does not return 5xx under load; Google says "5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling" (HTTP status codes and network errors). Test: Crawl stats report in Search Console.

2. Indexing (checks 9 to 15)

Indexing is Google deciding to keep a page. The noindex rule "is a rule set with either a <meta> tag or HTTP response header", and the page carrying it "must not be blocked by a robots.txt file" because otherwise "the crawler will never see the noindex rule" (Block Search indexing with noindex).

1. The Pages report in Search Console shows your important pages as indexed, and the count roughly matches your sitemap. Test: Pages report; investigate each "why pages aren’t indexed" reason.
2. Your ten most valuable pages pass URL Inspection as indexed, with the canonical Google chose matching yours. Test: inspect each.
3. Utility pages (thank-you, internal search results, filters, login, cart, tag archives with one post) carry noindex. Test: crawl, filter by noindex, confirm the list is only pages you intended.
4. No noindexed page is also blocked in robots.txt. Test: compare the noindex list with Disallow rules.
5. Staging, development and preview sites are not indexable (password or noindex) and are not in Google now. Test: search site:staging.yourdomain.co.uk.
6. No soft 404s: pages that return 200 but show "no results" or an error. Google describes these as content that suggests "an error for Google Search, an empty page or an error message" (HTTP status codes and network errors). Test: Pages report, "Soft 404".
7. Pages marked "Discovered, currently not indexed" or "Crawled, currently not indexed" are either improved, consolidated or removed; a long list means thin or duplicate pages. Test: Pages report.

3. Canonicals and duplicates (checks 16 to 22)

Google treats redirects as "A strong signal that the target of the redirect should become canonical", rel=canonical annotations as a strong signal too, and sitemap inclusion as "A weak signal", and it prefers "HTTPS pages over equivalent HTTP pages as canonical". It asks you to "Use absolute paths rather than relative paths" in canonical tags and to add a self-referencing canonical on the canonical page itself (How to specify a canonical).

1. Every indexable page has one rel=canonical tag with an absolute HTTPS URL, usually pointing to itself. Test: crawl; filter for missing, multiple or relative canonicals.
2. One host version is live and the other three redirect to it: http and https, www and non-www. Test: curl -I each of the four versions of the home page.
3. Trailing-slash and non-slash versions do not both return 200; one redirects. Test: curl -I both.
4. URL parameters (sorting, tracking, session IDs) resolve to the clean canonical and are not indexed as separate pages. Test: site: searches for "?" variants; inspect a parameter URL.
5. Paginated series (page 2, 3) are indexable with self-referencing canonicals, not all canonicalised to page 1. Test: inspect page 2 of a category.
6. The canonical in the page agrees with the sitemap and with Google’s chosen canonical. Test: URL Inspection on a sample.
7. Near-duplicate pages (two service pages that say the same thing, a printer version, an old campaign copy) are merged or redirected. Test: crawler duplicate-content report; one page per search intent.

4. Redirects and status codes (checks 23 to 29)

Permanent redirects (301 and 308) tell Google to treat the target as canonical; temporary ones (302, 303, 307) do not, and "The target page might still be indexed if other canonicalization signals are present". Google recommends "a permanent server-side redirect whenever possible" and says to "Only use JavaScript redirects if you can’t do server-side or meta refresh redirects" (Redirects and Google Search). Google’s crawlers follow redirects "by default up to 10 hops", and "Google doesn’t use the content from URLs that return 4xx status codes" (HTTP status codes and network errors).

1. Permanent moves use 301 or 308, not 302. Test: crawl; list all 3xx with their codes.
2. No redirect chains or loops: every old URL reaches its destination in one hop. Test: crawler redirect-chain report.
3. No meta refresh or JavaScript redirects where a server redirect is possible. Test: view source of any page that forwards you.
4. Every URL that ever ranked or earned a link redirects to its closest live equivalent, not to the home page. Test: export old URLs from Search Console (16 months) and old sitemaps; crawl them.
5. Missing pages return a real 404 (or 410 if deliberately removed) with a helpful page, not a 200 with an error message. Test: visit yourdomain.co.uk/this-does-not-exist and check the status in the network tab.
6. The 404 page links to the home page, the main sections and search; it does not redirect. Test: visit it.
7. External links to your site that point at dead URLs are redirected. Test: Search Console Links report against your crawl; Search Console "Not found (404)" list.

5. Rendering and JavaScript (checks 30 to 35)

Google processes JavaScript sites in three phases, crawling, rendering and indexing, and "The page may stay on this queue for a few seconds, but it can take longer than that". Content that only appears after JavaScript runs is indexed with a delay and only if rendering succeeds; Google adds that "server-side or pre-rendering is still a great idea" because "not all bots can run JavaScript". Links are discovered only as HTML a elements with an href, and you should "not use fragments to load different page content" (JavaScript SEO basics).

1. The main content, headings and links of each page are present in the initial HTML response, not only after JavaScript. Test: view source (not inspect element) and search for a sentence from the page.
2. Where content is client-rendered, URL Inspection’s rendered HTML contains it. Test: inspect, "View crawled page", HTML tab.
3. Navigation uses real links with hrefs, not onclick handlers or buttons. Test: crawl; a crawler that finds only the home page has found your problem.
4. Client-side routing uses paths (History API), not # fragments. Test: look at the URL as you move around the site.
5. Error states in a single-page app return a real 404 status or carry a noindex tag, so broken product URLs do not index as empty pages. Test: visit a made-up product URL and check the status.
6. Content behind "load more", tabs and accordions is in the HTML or loaded in a way Google renders; infinite scroll has paginated URLs behind it. Test: rendered HTML in URL Inspection.

6. Mobile (checks 36 to 40)

Google indexes and ranks with the mobile version of your pages, "crawled with the smartphone agent", and asks that your mobile site "contains the same content as your desktop site", with the same structured data and the same titles and meta descriptions (Mobile-first indexing best practices).

1. Mobile and desktop show the same content, including text hidden in accordions or tabs. Test: compare the two in URL Inspection or by resizing the browser.
2. Structured data, titles, descriptions and robots tags are identical on mobile and desktop. Test: crawl with a mobile user agent and diff.
3. A viewport meta tag is set and text is readable without zooming. Test: open on a phone; PageSpeed Insights flags viewport problems.
4. Tap targets are not crowded and nothing important sits under a sticky bar or a cookie banner. Test: use the site on a phone, one-handed, on the Northern line.
5. No intrusive interstitial covers the content on arrival. Google’s page experience self-assessment asks "Do your pages avoid using intrusive interstitials?" (Understanding page experience). Test: land on an inner page from a cold browser.

7. Speed and Core Web Vitals (checks 41 to 46)

Google says "Core Web Vitals are used by our ranking systems" and that good scores do not guarantee rankings, since "Google Search always seeks to show the most relevant content, even if the page experience is sub-par" (Understanding page experience). The targets are an LCP within "2.5 seconds", an INP "of less than 200 milliseconds" and a CLS "of less than 0.1" (Core Web Vitals and Google Search results), measured at the 75th percentile of real visits. The Core Web Vitals guide explains each metric and the fixes; these six checks tell you whether you need it.

1. The Search Console Core Web Vitals report shows your page groups as Good on mobile. Test: the report; it is built from "the CrUX report" of real Chrome users (Core Web Vitals report).
2. LCP for your template pages (home, service, product, article) is 2.5 seconds or less in field data. Test: PageSpeed Insights, the field section at the top, not the lab score.
3. INP is 200 milliseconds or less in field data. Test: as above; if there is no INP data, the page passes on LCP and CLS alone.
4. CLS is 0.1 or less in field data. Test: as above; then reload the page on a phone and watch for jumps.
5. Time to first byte is 0.8 seconds or less, the web.dev "good" threshold (web.dev: Time to First Byte). Test: the network tab, first document request.
6. Images are served at the size they are displayed, in a modern format, with width and height set, and the hero image is not lazy-loaded. Test: PageSpeed Insights diagnostics; view source for the hero img.

8. On-page signals (checks 47 to 53)

Google asks for title elements with "distinct text that describes the content of the page", warns against repeating boilerplate and notes there is "no reason to have the same words or phrases appear multiple times"; it may rewrite a title link when it finds these problems (Influencing your title links).

1. Every indexable page has a unique, descriptive title under about 60 characters, with the page’s subject first. Test: crawl; sort by title; look for duplicates and blanks.
2. Every indexable page has a unique meta description that reads as a sentence. Test: crawl; duplicates and blanks.
3. One H1 per page, matching the title’s subject, followed by H2s in order. Test: crawler heading report.
4. Every meaningful image has alt text that describes it; decorative images have an empty alt. Test: crawler images report.
5. Internal links use descriptive anchor text, not "click here", and the pages you most want to rank receive the most internal links. Test: crawler inlinks count.
6. The html element declares the language (lang="en-GB"). Test: view source, first line.
7. If the site has language or country versions, hreflang annotations are complete and reciprocal: "If two pages don’t both point to each other, the tags will be ignored", and x-default is set (Localized versions of your pages). Test: crawler hreflang report. Single-language London sites can skip this check.

9. Structured data and security (checks 54 to 60)

Google’s structured data policies require that "Your structured data must be a true representation of the page content", that you "Don’t mark up content that is not visible to readers of the page", and remind you that "Google does not guarantee that your structured data will show up in search results" (General structured data guidelines). The page experience self-assessment also asks "Are your pages served in a secure fashion?" (Understanding page experience).

1. Organization (or LocalBusiness for a single site, LocalBusiness per branch page for several) markup is present, valid and matches the visible NAP. Test: Rich Results Test.
2. BreadcrumbList markup matches the visible breadcrumb on every inner page. Test: Rich Results Test on a deep page.
3. Article, FAQPage, Product or Service markup is used only where that content is visible on the page, and nothing is marked up that a reader cannot see. Test: compare the markup with the rendered page.
4. No self-serving AggregateRating or Review markup for your own business. Test: search the source for "aggregateRating"; our schema guide explains what is allowed.
5. Search Console’s enhancement reports show no errors for the types you use. Test: the Enhancements section.
6. HTTPS everywhere: a valid certificate, every http URL redirecting to https, no mixed content (http images or scripts on https pages). Test: the padlock on every template; crawler mixed-content report.
7. Security headers are set (Strict-Transport-Security at minimum) and the site is not serving malware or hacked pages. Test: curl -I; Search Console Security issues report.

What to fix first

Sixty checks produce a long list. Fix in this order, because each group gates the next.

A London example, anonymised and composite: a Shoreditch studio rebuilt its site on a JavaScript framework, kept its rankings for three weeks and then lost them. Checks 30 and 31 showed the service descriptions existed only after rendering; check 24 showed every old URL redirecting to the home page; check 12 showed the new blog listing carrying a noindex left over from staging. None of it was about the writing. The website redesign checklist and the migration checklist are the pre-launch versions of this list.

If you would rather someone did the sixty checks for you, that is what our technical SEO service and the SEO audit are for. We work from the Tower 42 office in the City, by appointment, and visit clients across London. The free review below is the short version: three technical fixes, confirmed by hand with a screenshot each.

Get your free SEO auditA person runs the checks that matter most on your site, by hand, within two working days. Three fixes, each with a screenshot. No automated score, no call required.