The technical SEO checklist, in the order that matters.

What is technical SEO?

Technical SEO is the work that lets search engines reach, read and store your pages correctly: server access, status codes, indexing rules, sitemaps, duplicate URLs, redirects, internal links, structured data, speed and security. It does not write your content. It makes sure the content you already have can actually compete in search.

Google Search Essentials lists only three technical requirements: Googlebot is not blocked, the page works and returns an HTTP 200 status, and the page has indexable content. Google adds that most sites pass them without realizing it. The trouble is the sites that do not, because their owners rarely find out until traffic drops.

In what order should you check things?

Start with access, because nothing else matters if Google cannot reach the page. Then indexing, then duplicates and canonicals, then redirects and broken links, then internal links, structured data and finally speed, mobile and security. Each step depends on the one before it, so fixing speed first often wastes budget.

Step 1: crawl access

Can Google actually load your pages? Check robots.txt for rules that block important folders, and use the URL Inspection tool in Search Console to see the page as Googlebot sees it. Look beyond robots.txt too: firewalls, bot protection and security plugins can block crawlers without anyone noticing.

That is exactly what happened to a medical clinic I worked with. An old firewall showed a "please wait while your request is being verified" screen to every visitor. Crawlers do not pass that check, so Google saw an empty page, and the clinic had lost about 70% of its organic traffic. Once the site loaded directly again, average position moved from 13.5 to about 9. The whole story is in the clinic technical SEO case study.

Step 2: indexing and sitemaps

Next, confirm that the pages you want in Google are indexed and the ones you do not want are kept out. The Pages report in Search Console shows which URLs are excluded and why. Common causes: a noindex tag left from development, pages that return errors, and thin pages Google chose not to keep. On the same clinic site, 310 thin tag archives were cluttering the index, and we set them to noindex.

A sitemap helps Google find your URLs. Google's sitemap overview says a site of about 500 pages or fewer that is well linked may not need one, but that most sites benefit from it. It also warns that a sitemap does not guarantee that every URL will be crawled and indexed. Keep only live, indexable, canonical URLs in it.

Step 3: duplicates and canonicals

The same page often lives at several addresses: with and without www, with tracking parameters, through filters or print versions. Google's guide to specifying a canonical URL ranks the signals: redirects and rel="canonical" are strong signals, a sitemap is a weak one. It also says not to use robots.txt or noindex to choose a canonical within a site. Pick one address per page and point every signal to it.

Step 4: redirects and broken links

Every old URL that still gets visits or links should return a permanent redirect to its closest new equivalent, in one hop. Chains of redirects and links to deleted pages waste crawling and frustrate visitors. On the clinic site I fixed 5 broken internal links and repointed or removed 16 links to an expired old website. If you are about to change URLs, read website redesign without losing SEO first.

Step 5: internal links

Google's link best practices say it can only reliably crawl links that are an HTML <a> element with an href, and that every page you care about should have a link from at least one other page on your site. Menus built only with JavaScript, orphan pages and vague anchor text like "click here" all make your structure harder to understand.

On a large recovery directory with more than 70,000 location pages, much of the growth came from this step: fixing crawl and indexing problems and linking states, cities and meetings in a logical order. Daily organic clicks grew from about 700 to more than 2,300. See the recovery directory case study.

Step 6: structured data

Structured data tells search engines what a page is about: a business, a product, a service, an article. Google's introduction to structured data recommends JSON-LD, asks you to mark up only content that visitors can see, and is clear that valid markup does not guarantee a rich result. Validate it with the Rich Results Test after every template change.

Step 7: speed and mobile

Check Core Web Vitals in Search Console and test your main templates on a real phone. Can someone read, tap the phone number and fill the form without zooming or waiting? The thresholds and the usual culprits are explained in Core Web Vitals and INP for business owners.

Step 8: security and honesty

Serve every page over HTTPS with a valid certificate, redirect the http version and keep your CMS and plugins updated. A hacked site can be flagged and lose visibility fast. And never show search engines different content from what people see: Google's spam policies treat that as cloaking. Security tools should protect the site without hiding it from legitimate crawlers.

The checklist

• robots.txt does not block pages, CSS or JavaScript that matter.
• URL Inspection shows the real content for your key pages, not a security screen.
• Important pages return 200. Deleted pages return 404 or 410, or redirect to a close match.
• No stray noindex on pages that should rank.
• The sitemap lists only live, indexable, canonical URLs and is submitted in Search Console.
• One canonical address per page, with redirects and the canonical tag pointing to it.
• Redirects are permanent and go to the final URL in one hop.
• No broken internal links and no orphan pages.
• Menus and links are real HTML links with descriptive anchor text.
• Structured data is valid, matches visible content and passes the Rich Results Test.
• Core Web Vitals pass on the templates that bring traffic, on mobile first.
• HTTPS everywhere, updated software and no cloaking.

Tools for each check

How often should you run a technical audit?

Run a full technical audit once a year, and a quick one after any redesign, platform change, new plugin or sudden drop in traffic. In between, check the Pages and Core Web Vitals reports in Search Console every month. Most serious problems appear right after a change, so that is when to look.

When should you hire help?

Hire help when traffic falls and nobody can explain why, before a redesign or migration, when your site has thousands of pages, or when the checklist points to problems you cannot fix inside your platform. A good audit gives you a prioritized list of fixes your developer can execute, not a hundred-page PDF.

That is how I run every SEO audit and technical SEO project. It is also the foundation of the approach on my SEO consultant home page. Audits start at $450 (see pricing), and you can book a free 30-minute diagnosis to see what I would check first on your site.

Frequently asked questions

About the author

Juan José Giraldo is an SEO consultant in Medellín, Colombia, with 5+ years of experience. He works on technical and local SEO for 600+ US car dealerships at an Inc. 5000 agency and supervises the SEO of 18 US online stores with more than 3 million products. Read more · LinkedIn.

Sources

1. Google Search Central, Google Search Essentials
2. Google Search Central, What is a sitemap
3. Google Search Central, How to specify a canonical URL
4. Google Search Central, Link best practices for Google
5. Google Search Central, Spam policies for Google web search
6. Google Search Central, Introduction to structured data