The technical SEO checklist: 12 things to look at first
Technical SEO sounds complicated, but most problems live in the same handful of places. This is the full list of 12 checks we start every audit with.
Work through it in order. Points 1–3 decide whether your site appears in search at all, and only once they are clean is it worth moving on to speed and structure. To get started you need Google Search Console, your browser’s developer tools and any crawler that can walk the whole site.
1. Indexing before anything else
Check the Pages report in Search Console: how many pages are indexed and what reasons are given for exclusions. If important pages are missing from the index, no other optimization matters.
Learn to recognise the two most common reasons. “Discovered – currently not indexed” usually points at thin or near-duplicate content, and “Alternate page with proper canonical tag” means Google considers the page a copy of another. Compare the number of indexed pages with the number of pages that should exist: a large gap points at a structural problem rather than individual errors.
2. Robots.txt and meta robots
A surprising number of sites block their own content by accident. Read robots.txt line by line and make sure no staging noindex tags survived the launch.
Keep the distinction clear: robots.txt blocks crawling, not indexing. If you want a page out of the index, use a noindex tag and do not block the page in robots.txt — otherwise the crawler never sees the noindex instruction. Do not block CSS and JavaScript either, because without them the page cannot be rendered correctly.
3. Canonical tags
Every page should point at itself unless there is a specific reason not to. Conflicting canonicals are the most common cause of the wrong page ranking.
Pay particular attention to paginated listings, filtered category pages and parameterised URLs. A canonical is a hint rather than a command: if the content of two pages differs clearly, search engines will ignore the hint. Make sure the canonical is an absolute URL and uses the same protocol and hostname as the rest of the site.
4. Core Web Vitals and page speed
Measure with real user data, not just a lab test. Most of the wins are in images, fonts and third-party scripts.
The thresholds Google publishes are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. The Page Experience report in Search Console is based on measurements from real visitors, so use it as your baseline and keep lab tests for debugging. The fastest single win is almost always images: correct dimensions, a modern file format and lazy loading for everything below the first screen.
5. Internal linking
Internal links tell search engines which pages matter on your site. A page that can only be reached through the sitemap is effectively an orphan.
Check that every important page sits no more than three clicks from the home page and that anchor text describes the destination. Avoid situations where “read more” is the only anchor pointing at a page. Crawl the site and look for pages with no internal links at all: they are almost always either redundant or forgotten.
6. Structured data
Structured data does not lift rankings directly, but it shapes how your result looks in search and how well machines understand the content.
At a minimum, mark up your organisation and contact details, articles, products and frequently asked questions. Test the markup with Google’s Rich Results Test and the Schema.org validator. The most important rule is to mark up only what is visible to the user on the page — describing content that is not there breaks the guidelines and can cost you rich results entirely.
7. Hreflang and language versions
If the site has several languages, hreflang tells search engines which version to show to whom. The errors are common and quiet: nothing looks broken, but the wrong language version ranks.
Every language version must reference all the others as well as itself, and the references have to be reciprocal. If the Finnish page points to the English one, the English page has to point back. Use valid language and region codes, and set x-default for the audience that none of your language versions serves directly.
8. XML sitemap
The sitemap should contain exactly the pages you want indexed — and nothing else.
Remove redirects, 404s, noindex pages and pages whose canonical points somewhere else. A contradiction between the sitemap and your other directives undermines trust in the whole file. Declare the sitemap location in robots.txt and submit it in Search Console, where you can see how many of its URLs are actually indexed.
9. Broken links and 404s
A single 404 is not a problem, but linked 404s are: they waste both visitors and link value.
Separate two cases. Pages your own site links to needlessly are fixed by updating the link. Removed pages that still attract external links or still appear in search results are redirected to the closest relevant page. Do not redirect everything to the home page: search engines treat an irrelevant redirect as a soft 404.
10. Redirect chains
Every extra hop slows the page down and spends crawl budget. The target is one hop from the original URL to the final one.
The most common chain comes from combining protocol and www variants: the unsecured URL redirects to the www version, which redirects to the secure one. Pick one canonical form and send everything else straight there. Use 301 redirects for permanent moves and re-check them after a migration, because that is when chains usually appear.
11. Duplicate content and URL parameters
The same content on several URLs splits your signals across all of them. In e-commerce this is almost always the single biggest technical problem.
Filters, sorting, session identifiers and campaign parameters easily produce hundreds of near-identical URLs. Choose one address per piece of content, canonicalise the rest to it and keep pointless parameter combinations out of the index. Also check that the same product is not reachable through several category paths on different URLs.
12. Server log analysis
Log files tell you what the crawler actually did — not what you assume it did.
Logs show which pages the crawler visits most often, where it runs into errors and whether crawl budget is being spent on pages that do not matter. This is the most laborious item on the list, and its value grows with the size of the site: on a small site you can skip it, on a site with tens of thousands of pages it is often the only way to find the real bottleneck.
Where to start if you only have an hour
Spend the hour on points 1, 2 and 3. They decide whether your site is in the race at all. Points 4–8 determine how well you do, and points 9–12 are refinements whose importance grows with the size of the site.
Record every finding in one table and score it on two scales: expected impact and estimated effort. Fix the high-impact, low-effort items first. That is the whole of technical SEO prioritisation compressed into a single rule.
Want the complete list?
We will run a technical audit on your site where every point is checked and prioritised.