You’ve read The Tech SEO Manual.
Thirteen articles. Every layer of technical SEO from robots.txt to hreflang, from Core Web Vitals to JavaScript rendering. You now know more about how Google crawls and evaluates websites than most people in any room you’ll walk into today.
Now here’s the practical problem.
Knowing what technical SEO covers and systematically checking whether your site is actually doing all of it correctly are two very different things. Technical SEO problems have an inconvenient habit of not announcing themselves. Your site loads fine. Your analytics look roughly normal. Nobody is sending you an email saying “hey, your robots.txt is blocking five hundred important pages.”
That’s what audits are for. Systematic, repeatable checks that catch what daily browsing misses.
This is the checklist I run. Before every site launch. After every migration. After every major template change. After every time a developer says “I just made a small update to the site.” Especially then.
Table of Contents
When to Run This Audit
Before a site launch: mandatory. Every item below. No exceptions. The most expensive technical SEO fixes are the ones discovered after a site has been live and underperforming for three months.
After a site migration: mandatory. URL changes, domain changes, CMS changes, platform changes. Any migration that touches URLs, redirects, or template code needs a full technical audit within the first week.
After major template changes: check the sections relevant to what changed. A template update that touches the <head> needs a canonical, hreflang, and structured data check. A template update that touches navigation needs an internal linking check. A template update that touches page speed resources needs a Core Web Vitals check.
Quarterly, for established sites: run a lighter version covering crawlability, indexing, and Core Web Vitals at minimum. Technical debt accumulates quietly. Quarterly checks stop small issues before they compound.
Crawlability
Start here. Everything else depends on Google being able to access your site.
Go to yoursite.com/robots.txt right now. Read every line. Look specifically for Disallow: / which blocks your entire site. Check that CSS and JavaScript files are not blocked (a blocked resources crawl is a rendered page that looks nothing like your actual site). Check that your sitemap URL is listed.
Use Subu’s Robots.txt Checker to run an instant check on your live file. Then use the Robots.txt tester in Google Search Console (Settings section) to test specific URLs against your current rules.
Confirm that all important pages return a 200 status code by crawling your site with an SEO crawler tool and filtering by response code. Any important page returning a non-200 response is a problem.
Check that important pages are not accidentally tagged with noindex meta robots tags. A crawl in the SEO crawler tool filtered for noindexed pages will show you everything currently excluded from indexing.
Checks:
- No
Disallow: /in robots.txt - CSS and JavaScript are crawlable
- Sitemap URL listed in robots.txt
- All important pages return 200
- No accidental noindex on pages that should be indexed
- CSS and JavaScript load correctly when Google renders the page (test via URL Inspection in Search Console)
XML Sitemap
Your sitemap should be a curated list of your most important, indexable URLs. Not a dump of everything that exists on the site.
Submit your sitemap in Google Search Console if it isn’t already. Check the submitted vs indexed number. A large gap between the two warrants investigation into content quality and indexing issues.
Run your sitemap URL through an SEO crawler tool to check for any listed URLs that return 404s, 301 redirects, or have noindex tags. Every URL in your sitemap should be a live, canonical, indexable page. If it isn’t, remove it.
Checks:
- Sitemap exists and is submitted in Search Console
- Sitemap contains only live, canonical, indexable URLs (no 404s, 301s, or noindex pages)
- Sitemap is current and reflects recently published or updated content
- Large sites use a sitemap index to manage multiple sitemaps
- Sitemap auto-updates when new content is published (verify your CMS plugin settings)
HTTPS and Security
Open your site in Chrome. Look at the address bar. The padlock must be present on every page, including any parameter-generated or deep-linked URLs.
Open browser DevTools on your most important pages and check the Console for mixed content warnings. Any HTTP asset loading on an HTTPS page triggers a warning and weakens your security posture.
Check your SSL certificate expiry date. Use an external SSL checker tool to get a full certificate health report including expiry date and protocol support. Set a calendar reminder to check 30 days before expiry.
Check Google Search Console’s Security Issues report. If Google has detected hacked content or malware on your site, it will be reported here.
Checks:
- SSL certificate is valid and not expiring within 30 days
- All HTTP URLs 301 redirect to HTTPS
- No mixed content warnings in DevTools console
- HSTS header is set
- No security issues flagged in Search Console
- WordPress core, themes, and plugins are all up to date
Mobile Usability
Open your key pages on an actual mobile device. Not a resized browser window. An actual phone.
Check that text is readable without pinching to zoom. Check that all buttons and links are tappable without accidentally hitting adjacent elements. Check that no popups or interstitials are covering the entire screen on load.
In Search Console, check the Mobile Usability report. Any flagged pages with mobile usability errors should be fixed before they accumulate.
Use the URL Inspection tool to check a sample of your most important pages. View the rendered page in mobile view and confirm all content is present, all tags are loading correctly, and structured data is visible.
Checks:
- Mobile Usability report in Search Console shows no errors
- All important pages have the viewport meta tag set to
width=device-width, initial-scale=1 - Body text is readable at native mobile size (minimum 16px)
- Touch targets are at least 44px with adequate spacing between adjacent interactive elements
- No full-screen interstitials blocking content on mobile load
- Mobile version contains the same content as desktop (no stripped-down mobile content)
Core Web Vitals
Run Subu’s SEO Audit Tool for a consolidated starting point. Then go into Search Console’s Core Web Vitals report for your field data by page.
Field data is what matters for rankings. If your lab data (PageSpeed Insights, Lighthouse) shows good scores but your field data shows Poor, the field data is what Google uses. Investigate the gap.
For any pages scoring Poor or Needs Improvement on LCP, check the LCP element in PageSpeed Insights and identify what is causing the delay. For CLS, check the DevTools Layout Shift Regions visualisation to identify which elements are causing shifts.
Checks:
- LCP under 2.5 seconds (field data)
- INP under 200ms (field data)
- CLS under 0.1 (field data)
- Hero images are correctly sized, compressed, and in WebP or AVIF format
- LCP image has
fetchpriority="high"and is not lazy-loaded - No render-blocking scripts in
<head>withoutdeferorasync - All images have explicit
widthandheightattributes set - No content injected above the fold after page load (ads, banners, notification bars)
Indexing
Search Console’s Coverage report is your indexing dashboard. Check the Valid tab for total indexed pages. Check the Excluded tab for any unexpected exclusions. Specifically look for “Duplicate without canonical selected by Google” entries and “Soft 404” flagged pages.
The “Discovered, currently not indexed” category tells you about the backlog of pages Google knows exist but hasn’t crawled yet. A large and growing backlog on a site that publishes regularly suggests crawl budget is being wasted somewhere.
Checks:
- No important pages flagged as Soft 404s in Search Console
- No valuable pages appearing in “Excluded” with unexpected reasons
- “Discovered, currently not indexed” list is not growing faster than you’re publishing
- No pages with noindex accidentally left in place after publication (common post-launch issue on new builds)
- Cover page report shows no unexpected spikes in error count after site changes
Canonicalization
View the source on a sample of key pages and search for rel="canonical". Every page should have a self-referencing canonical tag in the <head>. The canonical URL should match the page URL exactly, including protocol (https://), subdomain preference, and trailing slash convention.
Run a crawl in an SEO crawler tool and check the Canonicals report for pages with missing canonicals, canonicals pointing to different URLs (intentional cross-page canonicals should be documented), and canonicals pointing to 404s or redirect URLs.
Use the URL Inspection tool for key pages to check whether Google’s selected canonical matches your declared canonical. A discrepancy between the two means Google found something contradictory.
Checks:
- Every page has a self-referencing canonical tag in
<head> - No canonical tags pointing to 404 pages, redirect URLs, or noindexed pages
- WWW and non-WWW consistently redirect to one version
- HTTP consistently redirects to HTTPS
- Trailing slash is consistent site-wide
- No canonical-hreflang conflicts on international pages (every international variant self-references in both tags)
Redirects
Export your full redirect list from your CMS redirect manager or your server configuration. Cross-reference with your URL list from an SEO crawler tool crawl.
Specifically check for redirect chains longer than one hop. Any URL that redirects to another URL that also redirects should be updated to redirect directly to the final destination.
Check for 302 redirects that are being used for permanent moves. These should be 301s.
Checks:
- No redirect chains longer than one hop
- No redirect loops
- All site-wide redirects use 301 for permanent moves (not 302)
- All high-traffic, high-value old URLs from previous site versions or migrations have redirect coverage
- Deleted pages with no relevant replacement return 410 (not 404 or 200)
- Redirect configuration is reviewed after every URL or structural change
JavaScript Rendering
View the source code of your most important page templates (homepage, key category pages, a post or product page template). Search for your <title> tag, <meta name="description">, rel="canonical", and your main H1 content. All of these should be visible in the raw source, not just in the rendered DOM.
If any of these are missing from the page source but visible in the DevTools Inspect panel, they are JavaScript-rendered and subject to Wave 2 crawling delays and reliability issues.
Use the URL Inspection tool in Search Console for key pages. Click “Test Live URL” then “View Tested Page.” Compare the rendered DOM to what you saw in View Page Source. Missing content is content at risk.
Checks:
- Title tags and meta descriptions present in raw HTML source
- Canonical tags present in raw HTML source
- H1 and main body content present in raw HTML source
- Internal navigation links are real
<a href>links (not JavaScript-only navigation) - Structured data/schema markup is in raw HTML source
- Hreflang tags (if applicable) are in raw HTML source
- No critical content hidden behind click, hover, or scroll interactions
Crawl Budget (For Large Sites)
Check the Crawl Stats report in Search Console (Settings section). Look for unusual spikes in crawl volume, high rates of non-200 response codes, and average response sizes that suggest thin or empty pages being crawled at volume.
Run a crawl using an SEO crawler tool and export the full URL list. Look for large volumes of parameter-generated URLs, faceted navigation combinations, internal search result pages, and session ID URLs that are being crawled.
Checks:
- No parameter-generated or faceted navigation URLs being indexed (canonical to base category URL or blocked in robots.txt)
- No session IDs or tracking parameters in indexed URLs
- Internal search result pages are noindexed or blocked from crawling
- Crawl Stats report shows no unusual spikes in crawl volume after recent changes
- “Discovered, currently not indexed” backlog is manageable relative to site size
URL Structure
Export your full URL list from an SEO crawler tool crawl. Check for uppercase letters in URLs, underscores instead of hyphens, unnecessary parameters in indexable URLs, and inconsistent trailing slash usage.
Checks:
- All URLs are lowercase
- Word separators are hyphens (not underscores or encoded spaces)
- No dynamic parameter URLs for content that should have clean slugs
- Trailing slash usage is consistent across all page types
- URL slugs are descriptive and include primary keyword where natural
- No post IDs in URLs (WordPress default permalink structure changed to Post Name)
Structured Data
For every key page type on your site (homepage, articles, products, local business, FAQ-containing pages), test a representative URL in Google’s Rich Results Test. Check for detected schema types, errors, and warnings.
Check Search Console’s Enhancements reports for each schema type you’ve implemented. Any pages with schema errors should be prioritised for fixing.
Use the Schema Markup Generator to generate or regenerate correct schema for any page types that are currently missing or producing errors.
Checks:
- Article or BlogPosting schema on all blog/editorial content
- FAQPage schema on any pages containing FAQ sections
- Product schema on e-commerce product pages (with accurate price and availability)
- LocalBusiness schema on contact or about page (if applicable)
- BreadcrumbList schema generating correctly
- Person schema on author pages (supports E-E-A-T)
- No schema errors in Rich Results Test
- No pages where schema markup is JavaScript-rendered rather than in static HTML
International (If Applicable)
Check Search Console’s International Targeting report for hreflang errors.
Run a crawl on a sample of international page variants. For each variant, verify that the raw HTML source contains hreflang annotations for every other variant (bidirectional), a self-referencing hreflang annotation, and a self-referencing canonical tag.
Checks:
- Hreflang is bidirectional on all variants (every variant references every other variant)
- Every page has a self-referencing hreflang annotation
- x-default hreflang is set on the fallback version
- All hreflang URLs are canonical, live, and return 200
- No canonical tags pointing cross-language on any international variant
- No hreflang errors reported in Search Console’s International Targeting report
- All language and region codes follow ISO 639-1 and ISO 3166-1 Alpha-2 standards
After Every Site Change: The Quick Check
Not every update warrants a full audit. But every site change warrants at minimum:
Check robots.txt is still intact and unchanged. Check that the changed pages still return 200. Check that canonical tags on changed pages are still correct. For any template changes to the <head>, test a representative URL in the Rich Results Test and URL Inspection tool.
Thirty minutes of checking after a “small update” prevents months of diagnosing an invisible problem.
The TL;DR
This checklist covers fourteen areas: crawlability, sitemap, HTTPS, mobile usability, Core Web Vitals, indexing, canonicalization, redirects, JavaScript rendering, crawl budget, URL structure, structured data, and international implementation.
Run it before every launch. Run it after every migration. Run it quarterly on established sites. Run the relevant sections after every significant template or structural change.
Technical SEO doesn’t break dramatically. It degrades quietly. Regular audits catch quiet degradation before it becomes a visible traffic problem.
Save this page. Share it with your developer before the next deployment. And if you’re running through this right now and finding problems you didn’t know existed, welcome to technical SEO. There are always more problems than the last audit found.
That’s not discouraging. That’s the job.
Questions about specific audit findings you don’t know how to interpret or fix? The comments are open. Subu reads everything.
— Subu, SEO by Subu
