A technical SEO check establishes whether search engines can fetch your pages, read them and add them to their index. This checklist covers each part, from status codes and indexing instructions to hreflang, page speed and HTTPS, and says how to check it yourself.
How do you use this checklist?
Start with your most important pages: the homepage, your main category or service pages and your contact page. Work through the parts from top to bottom, because each step builds on the one before. If a page is missing from Google entirely, read why is my page not showing in Google? first.
The order of a technical check
- ReachableThe page returns status code 200.
- AllowedRobots.txt lets the search bot fetch the page.
- IndexableThere is no noindex in the code or in the headers.
- CanonicalThe page points to itself as the version that counts.
- FindableInternal links and the sitemap lead to the page.
- ReadableTitle, headings, text and links are in the HTML.
- UsableThe page works on mobile, loads quickly and runs on https.
The Atlas column in the tables shows whether a point falls within what Atlas, Outseen’s research engine, examines in the public code of the pages it fetches. Anything that only appears after JavaScript, load times and private server code fall outside it.
Can a search engine reach your pages?
Status codes
| Check | How to check it | Atlas |
|---|---|---|
| Pages that should be found return status code 200 | URL Inspection in Search Console, or your browser’s Network tab | Yes |
| Removed pages return 404 or 410, or redirect to a suitable replacement | Page indexing report in Search Console, reason “Not found (404)” | Yes |
| No soft 404s: empty pages or error messages that return status code 200 | Page indexing report, reason “Soft 404” | No |
| No server errors (5xx) | Page indexing report in Search Console | Yes, at the moment of fetching |
Google does not process the content of pages that return a 4xx code and removes them from the index. With persistent 5xx errors, Google slows down its crawling and pages eventually drop out of the index as well. What the codes mean is explained under HTTP status code.
Robots.txt
| Check | How to check it | Atlas |
|---|---|---|
The file is at yourdomain.com/robots.txt and can be reached | Open the address in your browser | Yes |
| Important pages, CSS and JavaScript are not excluded | Read the Disallow rules, or look at the “Crawl allowed?” field in URL Inspection | Yes |
| You do not use robots.txt to keep pages out of Google | Look for pages you are trying to hide with Disallow | No |
A simple robots.txt that only excludes the basket and account pages and names the sitemap:
User-agent: *
Disallow: /basket/
Disallow: /account/
Sitemap: https://www.example.com/sitemap.xmlMay a search engine index your pages?
Noindex
| Check | How to check it | Atlas |
|---|---|---|
No noindex in the meta robots tag of pages that should be found | View the source code and search for noindex, or use URL Inspection | Yes |
No noindex in the X-Robots-Tag HTTP header | Network tab in your browser, response headers of the page | Yes |
The X-Robots-Tag is part of the server’s response, so it does not show up in the source code and is often missed. Robots.txt and noindex are also often confused:
Robots.txt or noindex?
| Disallow in robots.txt | noindex | |
|---|---|---|
| What it controls | Whether a search bot may fetch the page | Whether the page may be in the index |
| Can the URL appear in Google? | Yes, without a description, if other pages link to it | No, once Google has read the instruction |
| Does Google read the content? | No | Yes, the page has to be fetchable |
| Use it for | Parts search bots do not need to fetch, such as a basket | Pages that do not belong in search results |
Google explains this in its introduction to robots.txt and its documentation on noindex.
Canonicals
| Check | How to check it | Atlas |
|---|---|---|
| Every indexable page has a canonical that points to itself | Source code, search for rel="canonical" | Yes |
| The canonical is a full URL, not a relative path | Source code | Yes |
| The canonical URL itself returns status code 200 and is indexable | Open the canonical URL and check its status and noindex | Yes |
| Google picks the same canonical as you | URL Inspection, fields “User-declared canonical” and “Google-selected canonical” | No |
| Internal links point to the canonical version, not to variants | Sample the links in menus and body text | Yes |
Google calls the canonical a strong signal, not a directive. Conflicting signals, such as a sitemap listing different URLs, can lead Google to choose another version. What a canonical is, is explained under canonical URL.
Are your redirects and sitemap in order?
Redirects
| Check | How to check it | Atlas |
|---|---|---|
| Pages that have moved for good use a permanent redirect (301 or 308) | Network tab in your browser | Yes |
| Redirects are server-side, not done with JavaScript | Network tab: the status code of the first response | Yes |
| No chains: an old URL points straight to the final destination | Follow an old URL and count the steps in between | Yes |
When you move your site, Google advises keeping redirects in place for as long as possible, generally at least a year. More on this in redesigning your website without losing search visibility.
XML sitemap
| Check | How to check it | Atlas |
|---|---|---|
| There is a sitemap, listed in robots.txt or submitted in Search Console | Sitemaps report in Search Console | No |
| The sitemap contains only canonical, indexable URLs that return 200 | Compare a sample from the sitemap with the actual pages | No |
A sitemap helps Google discover pages, but does not guarantee that everything will be crawled and indexed.
Are hreflang and your internal links in order?
Hreflang
| Check | How to check it | Atlas |
|---|---|---|
| Each language version refers to itself and to all other versions | Source code of each language version | Yes, between the fetched pages |
| References go both ways | Check that version B also refers back to version A | Yes, between the fetched pages |
Language codes are valid, such as nl, nl-BE or en-GB | Source code | Yes |
If a page does not refer back, Google ignores the hreflang annotations.
Internal links
| Check | How to check it | Atlas |
|---|---|---|
Links are ordinary <a href> links with a real address | Source code, not just how the page looks in your browser | Yes |
| Every important page gets a link from another page | Check the menu and body text | Yes, between the fetched pages |
| Link text says where the link goes, so no “click here” | Read the link text in your menus and body text | Yes |
| No links to pages that no longer exist | Page indexing report, or follow links by hand | Yes, for followed links |
According to its link best practices, Google generally only follows <a> elements with an href.
Is the content properly in the HTML?
| Check | How to check it | Atlas |
|---|---|---|
Every page has its own descriptive <title> | Source code, or search for site:yourdomain.com | Yes |
| Every important page has its own meta description that summarises the content | Source code | Yes |
A clear main heading (<h1>) that says what the page is about | Look at the page and the source code | Yes |
The page language is set in the lang attribute of <html> | Source code, the opening tag | Yes |
| Images that carry content have descriptive alt text | Source code, search for alt= | No |
| Structured data is valid and not duplicated by a theme and a plugin | Rich Results Test, or search the source for application/ld+json | Yes, for supported JSON-LD |
| Important text and links are in the HTML the server sends | Page source (not the inspector) | Yes |
| Google sees the same content as your visitors | URL Inspection, live test, rendered HTML | No |
Google can change the title and description it shows. More on markup is in structured data explained.
Google runs JavaScript, but still recommends server-side rendering or pre-rendering and notes that not all bots can run JavaScript. How this works for AI crawlers is covered in can AI crawlers read your website?
Does your site work well on mobile, and is it fast and secure?
Mobile display
| Check | How to check it | Atlas |
|---|---|---|
| The mobile version has the same main content as the desktop version | Compare both versions on a phone and a computer | No |
Google uses the mobile version of your site for indexing and ranking.
Page speed
The three Core Web Vitals
| What it measures | Good when | |
|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the largest element becomes visible | Within 2.5 seconds |
| Interaction to Next Paint (INP) | How quickly the page responds to a click or tap | Within 200 milliseconds |
| Cumulative Layout Shift (CLS) | How much the page shifts while loading | Below 0.1 |
The thresholds come from Google’s explanation of Core Web Vitals. Google also says that relevance comes first and that good scores do not guarantee a top position.
HTTPS
| Check | How to check it | Atlas |
|---|---|---|
| All pages run on https | Open your site and look at the address | No |
| http addresses redirect permanently to https | Open the http version and check the status code | Yes, if that address is fetched |
How does Outseen approach a technical check?
At Outseen, Atlas fetches the public pages within the agreed research and checks, among other things, status codes, robots rules, indexing instructions in code and headers, canonicals and what their target page actually returns, internal links, hreflang and supported JSON-LD. For every finding, Atlas records what it observed, in which source, on which URL and when. After a change, Atlas can check the same page again. A specialist assesses the findings and sets the order of the work. More about the engine is on the Atlas page, and more about in-depth research with priorities on the audit page.
What does this mean for your business?
You do not need to work through the whole list at once. Five checks on your most important pages show whether something serious is wrong:
Start with these five checks
- Open three important pages in URL Inspection in Search Console and check whether they are indexed.
- Open yourdomain.com/robots.txt and read every Disallow rule.
- Search the source code of those pages for noindex and for rel="canonical".
- Open the Page indexing report and note the messages that affect the most pages.
- Check the Core Web Vitals report for pages marked as poor.
Many technical problems start with a change, such as a new theme, a plugin update or a domain move. Plan a check after every larger change and look in Search Console for new messages in between. If you are planning a redesign, read redesigning your website without losing search visibility first.