Technical SEO
Technical SEO Checklist: What to Check, in What Order, and How to Fix It
A working checklist for auditing a site’s technical health, ordered so the problems that hide the most pages get fixed first.
Technical SEO is the part of search optimization that decides whether Google can find, fetch, render and index your pages at all. Great content on a page Google never indexes earns nothing, so technical checks come before keyword and content work.
This checklist follows the order in which problems usually block visibility: access first, then indexing, then duplication, then rendering and speed. Each item says what to look at, where to look, and what a healthy result looks like. You don’t need paid tools for most of it; Google Search Console and a browser cover the essentials.
Short answer: Start with access (robots.txt, server errors, HTTPS), then indexing (Search Console’s Page indexing report and URL Inspection), then duplication (canonicals, redirects, parameters), then discovery (sitemaps and internal links), then rendering (JavaScript content and links), and finally page experience (Core Web Vitals and mobile layout). Fix whatever blocks the most important pages first.
Key Takeaways
- Check access and indexing before anything else: a page Google can’t fetch or won’t index can’t rank.
- Search Console’s Page indexing report and URL Inspection tool answer most technical questions for free.
- robots.txt controls crawling, not indexing; use noindex to keep a page out of results.
- Canonicals, redirects and internal links should all point to the same preferred URL.
- Core Web Vitals are judged on real-user data at the 75th percentile, not on one lab test.
Before you start: set up the tools
You need three things: a verified Google Search Console property for the site (a Domain property is best because it covers every protocol and subdomain), access to the site’s CMS or hosting, and a list of the pages that matter most commercially. That list keeps the audit honest: a broken tag archive matters far less than a service page that won’t index.
- Search Console: Page indexing, Sitemaps, URL Inspection, Core Web Vitals and, for larger sites, Crawl stats.
- A crawler: any site crawler that lists status codes, canonicals, titles and internal links. Free tiers are enough for small sites.
- A browser: to view source, check redirects and test pages in a private window as a logged-out visitor.
Write down what you change and when. When indexing or traffic moves weeks later, a dated change log is the only reliable way to connect cause and effect.
1. Access: can Google fetch your pages?
If Googlebot can’t fetch a page, nothing else matters. Check these first.
| Check | Where | Healthy result |
|---|---|---|
| robots.txt loads and doesn’t block important paths | yourdomain.com/robots.txt | Returns 200 (or 404 if you don’t need one); no Disallow covering key pages, CSS or JS |
| Important pages return 200 | Crawler, URL Inspection live test | 200 status; no 4xx or 5xx on pages you want indexed |
| No login or firewall in front of public pages | Private browser window | Page loads without signing in; Googlebot isn’t challenged |
| HTTPS works everywhere | Browser, crawler | Valid certificate; HTTP redirects to HTTPS in one hop |
| Server stays up under crawling | Crawl stats (larger sites) | Host status green; few 5xx responses |
Google’s robots.txt rules have a few traps worth knowing: a robots.txt file that returns a 5xx error makes Google stop crawling for a while, and a 401 or 403 response for robots.txt is treated as “no restrictions”. See robots.txt mistakes for the full list.
2. Indexing: are the right pages in Google?
Open Search Console’s Page indexing report. It splits known URLs into indexed and not indexed, with a reason for each group. Don’t aim for 100% indexed: redirects, duplicates and intentionally noindexed pages belong in the not-indexed list. Look instead for important URLs in the wrong bucket. Our guide to fixing indexing problems walks through each reason.
- Spot-check your top 10–20 commercial pages in URL Inspection: “URL is on Google” and a Google-selected canonical that matches the page.
- Look for
noindexon pages you want indexed (a common leftover from staging sites and theme settings). - Check “Soft 404” and “Server error (5xx)” groups for real pages.
- Read “Crawled – currently not indexed” as a quality and duplication signal, not a technical bug.
Search for site:yourdomain.com only as a rough sanity check. Google says the site: operator doesn’t necessarily return every indexed URL.
3. Duplication: one preferred URL per page
Most sites can serve the same content at several addresses: with and without www, with tracking parameters, with trailing slashes, or through filters. Google picks one canonical; your job is to make your preference clear and consistent. Canonical tags are the main tool, backed by redirects and sitemaps.
- Pick one host version (www or not, always HTTPS) and redirect the others to it permanently.
- Give every indexable page a self-referencing canonical with an absolute URL.
- Point canonicals on duplicates (sorted, filtered or parameter versions) to the main page.
- Make internal links, sitemap URLs and canonicals all use the same preferred URL.
- Check URL Inspection for pages where Google chose a different canonical than you did.
4. Discovery: sitemaps and internal links
Google finds pages mainly through links and sitemaps. A sitemap should list only canonical, indexable URLs, use absolute addresses, and stay under 50,000 URLs or 50MB uncompressed per file. Submit it in Search Console and reference it in robots.txt. If the Sitemaps report shows errors, see XML sitemap troubleshooting.
Internal links matter as much as sitemaps. Google’s guidance is that every page you care about should be linked from at least one other page on your site, using normal <a href> links with descriptive anchor text. Pages with no internal links are hard to discover and look unimportant; here is how to find orphan pages.
5. Rendering: does Google see your content and links?
If your site relies on JavaScript to show content or links, check what Google actually renders. Use URL Inspection’s live test and open the tested page’s HTML and screenshot. Main text, headings, links and structured data should all be present. Our JavaScript SEO guide covers the common failures.
- Links are real
<a href="...">elements, not click handlers. - Titles, meta descriptions and canonicals are in the initial HTML where possible.
- CSS and JavaScript files needed to render the page aren’t blocked in robots.txt.
- Error views in single-page apps don’t return 200 with “not found” text (a soft 404).
6. Redirects and status codes
Use permanent server-side redirects (301 or 308) for content that has moved for good, and temporary ones (302, 307) only for genuinely temporary changes. Google treats permanent redirects as a signal that the target should be canonical; temporary redirects keep the original URL canonical.
- No redirect chains on internal links: link straight to the final URL.
- No redirect loops (Google reports these as “Redirect error”).
- Removed pages with no replacement return 404 or 410, not a redirect to the home page.
- Moved pages redirect to the closest equivalent page.
7. Page experience: speed, stability and mobile
Google recommends good Core Web Vitals: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. Search Console’s Core Web Vitals report uses real-user data, judged at the 75th percentile. Lab tools like Lighthouse help you diagnose, but only field data shows what visitors experience. See Core Web Vitals explained.
- Don’t lazy-load the main image at the top of the page.
- Give images and embeds width and height so the layout doesn’t jump.
- Remove unused CSS and defer non-critical JavaScript.
- Check every key template on a phone-sized screen: no horizontal scrolling, readable text, tappable buttons.
8. Structured data and on-page basics
Technical audits usually finish with page-level checks that are easy to get wrong at scale: duplicate or missing titles, missing meta descriptions, multiple H1s from theme templates, and structured data errors. Search Console’s Enhancements reports list structured data issues by type.
- Every indexable page has a unique, descriptive title.
- Structured data matches what’s visible on the page.
- Images have useful alt text; decorative images can use empty alt.
- Language and, for multi-country sites, hreflang annotations are consistent.
How to prioritize what you find
An audit can easily produce a hundred findings. Rank them by two questions: how many important pages does this affect, and does it stop those pages being indexed or just make them slightly weaker? A noindex on your service pages beats any number of missing alt attributes.
| Priority | Typical issues |
|---|---|
| Fix now | Key pages blocked, noindexed, returning errors or redirecting wrongly; site-wide canonical mistakes |
| Fix this month | Duplicate URL patterns, orphaned important pages, sitemap errors, rendering gaps |
| Plan | Core Web Vitals improvements, structured data, title and meta clean-up |
| Monitor | Small numbers of 404s for removed pages, crawl stats on large sites |
If you’re also planning a redesign or platform change, run this checklist before and after, alongside our website migration SEO checklist.
Frequently asked questions
How often should I run a technical SEO audit?
Run a full audit at least once a year and before and after any redesign, migration or platform change. Check Search Console’s Page indexing and Core Web Vitals reports monthly.
Can I do technical SEO without paid tools?
Yes for most small and medium sites. Google Search Console, a browser and a free crawler tier cover access, indexing, canonicals, sitemaps, rendering and Core Web Vitals.
What’s the most common technical SEO problem?
In our experience, leftover noindex tags, blocked resources and duplicate URL versions cause more lost visibility than anything exotic. Check those first.
Does fixing technical issues guarantee better rankings?
No. Technical fixes remove barriers so Google can crawl and index your pages; rankings still depend on relevance and quality compared with other pages.
Is robots.txt enough to keep a page out of Google?
No. Google says robots.txt is not a mechanism for keeping a page out of Google. Use a noindex rule or password protection instead, and don’t block the page in robots.txt or Google can’t see the noindex.
Want a second pair of eyes on your technical SEO?
We review crawling, indexing, rendering and speed issues by hand and give you a prioritized list of fixes, starting with a free manual audit.
Sources
- Search Console Help: Page indexing report
- Search Console Help: URL Inspection tool
- Google Search Central: Build and submit a sitemap
- Google Search Central: How to specify a canonical URL
- Google Search Central: Introduction to robots.txt
- Google Search Central: Link best practices for Google
- Google Search Central: Understand JavaScript SEO basics
- Google Search Central: Redirects and Google Search
- Google Search Central: Understanding Core Web Vitals and Google search results
- Google Search Central: Get your website on Google Search
Last reviewed October 12, 2026.
