Technical SEO Audit Checklist: 21 Things to Check on Every Page

Why Technical SEO Audits Still Matter in 2026

Search engines have become remarkably sophisticated. Google's crawlers render JavaScript, interpret context, and rank pages with impressive nuance. So why bother with a technical SEO audit?

Because sophistication does not mean forgiveness.

A missing canonical tag splits your ranking signals across duplicate pages. A noindex directive left over from staging erases a page from search results entirely. A redirect chain adding 800ms of latency quietly tanks your Core Web Vitals. These happen on production sites every day, often without anyone noticing until organic traffic has dropped.

The difference between a site that ranks and one that languishes is rarely one dramatic failure. It is the accumulation of dozens of small technical issues, each shaving off a fraction of your visibility.

This checklist covers 21 specific checks you should run on every page of your site -- not once, but continuously. Your site is not a static artifact. Content changes, pages get added and removed, templates get updated, and every one of those changes can introduce new issues. A title tag that is 15 characters too long. An image without alt text. A broken internal link that sends users and crawlers into a dead end. None of these are catastrophic alone, but together they compound into a significant visibility deficit.

One-Time Audits vs. Continuous Monitoring

A one-time audit has a shelf life measured in weeks. The moment a developer pushes a template change, the moment a content editor publishes a page without a meta description -- your audit is stale.

Continuous monitoring treats technical SEO the way DevOps treats uptime: something that must be watched and alerted on in real time. Whether you run through this checklist manually or use a tool like SEO Monitor to automate the process, what matters is that these checks happen regularly.

The 21-Point Page Audit Checklist

1. Title Tag

Every page needs exactly one <title> tag, unique across the site and under 60 characters. The title tag is the single most important on-page ranking signal -- it is the clickable headline in search results.

What "bad" looks like: No title tag at all. A title over 60 characters like "The Ultimate Complete Comprehensive Guide to Everything About Technical SEO Audits in 2026 and Beyond" -- Google truncates unpredictably. Generic titles like "Home" or "Untitled." Duplicate titles across multiple pages.

Fix: Write a unique, descriptive title for every page. Front-load your target keyword. If your CMS generates titles from a template like "Page Name | Category | Site Name," check whether the resulting string exceeds the limit. If your title is "Home | My Company | Best Products | Buy Now" -- that is 52 characters of wasted opportunity that tells neither users nor search engines what the page actually offers.

2. H1 Tag

Each page should have exactly one <h1> tag describing the primary topic. While Google has said multiple H1 tags are not a penalty, having zero or multiple competing H1s signals confused page structure. Screen readers also rely on heading hierarchy for navigation.

What "bad" looks like: No H1 tag. Multiple H1s because logos or sidebar widgets are wrapped in <h1> by the template. An H1 that does not match the page's actual content.

Fix: Audit page templates to ensure only the main content heading uses <h1>. If your theme applies H1 styling to non-primary elements, change them to the appropriate heading level or a styled <div>.

3. Meta Description

Each page should have a <meta name="description"> tag, unique and under 160 characters. It does not directly influence rankings but heavily influences click-through rate -- it is your sales pitch in search results.

What "bad" looks like: No meta description (Google auto-generates one, often poorly). Description over 160 characters truncated mid-sentence. Duplicate descriptions across pages from a sitewide default.

Fix: Write unique descriptions for your most important pages. For large sites, use template-based generation that pulls page-specific information. Prioritize pages with the most Search Console impressions.

4. H2 Headings

Pages should use H2 tags to break content into logical sections. H2 headings help search engines understand topical structure and directly feed into featured snippet selection.

What "bad" looks like: A 2,000-word page with no H2 tags. H2 tags used for styling rather than structure. Vague headings: "More Information," "Details," "Other."

Fix: Structure content so H2 tags alone tell the story of the page. Someone reading only your H2s should understand what the page covers.

5. Full Heading Hierarchy

Headings should follow logical hierarchy: H1, then H2, then H3, without skipping levels. An H1 followed directly by an H3 (skipping H2) indicates broken document structure that confuses both assistive technologies and search engine parsers.

What "bad" looks like: H1 followed by H3 (skipping H2). H2 followed by H5. Headings chosen for visual size rather than semantic structure.

Fix: Use CSS for visual styling and headings for document structure. Never choose a heading level based on how it looks.

6. Word Count

Measure body content word count only -- excluding navigation, footer, sidebar, and boilerplate. Pages with fewer than 300 words are flagged as thin content. Google's Helpful Content system specifically targets pages lacking satisfying depth.

What "bad" looks like: A blog post with 150 words. A product page with only the name and price. A category page with nothing but links.

Fix: Add substantive content to thin pages. Product pages need descriptions, specifications, and FAQs. Blog posts should be expanded or consolidated into comprehensive guides.

7. Canonical URL

Each page should have a <link rel="canonical"> tag pointing to the preferred URL version. Canonical tags tell search engines which version is the "real" one -- without them, search engines guess, especially with URL parameters and trailing slash variations.

What "bad" looks like: No canonical tag. Canonical pointing to a different page accidentally (template bug). Canonical using HTTP while the page is HTTPS. Canonical pointing to a non-existent URL.

Fix: Implement self-referencing canonical tags on all pages. For legitimate duplicate content, choose one canonical and point all variations to it. Audit regularly -- canonical mismatches are among the most common template bugs.

8. Meta Robots

Check for <meta name="robots"> directives, particularly noindex and nofollow. A noindex directive immediately removes a page from search results -- useful for admin panels but devastating when applied accidentally. This is one of the most common causes of sudden traffic drops, almost always caused by staging configuration leaking into production.

What "bad" looks like: Important pages with noindex (staging leftover). Pages that changed from index to noindex without explanation. Conflicting directives between meta tag and X-Robots-Tag HTTP header.

Fix: Audit meta robots after every deployment. Set up content change detection so you are alerted when index status changes.

9. Open Graph Tags

Pages should have og:title, og:description, and og:image at minimum. These control how pages appear when shared on social media and messaging apps. Without them, platforms guess -- often pulling the wrong image or a truncated description.

What "bad" looks like: No OG tags (shared links look plain). og:image pointing to a broken image. Image dimensions too small (minimum 1200x630 for most platforms).

Fix: Add OG tags to page templates. Use the page's title and meta description as defaults. Create social sharing images for key pages.

10. Twitter Card Tags

Pages should have twitter:card, twitter:title, and twitter:description. While Twitter (X) falls back to Open Graph tags, explicit Twitter Card tags let you specify summary_large_image for more prominent visuals.

What "bad" looks like: No Twitter Card tags and no Open Graph fallback. Using summary card type when summary_large_image would be more effective.

Fix: At minimum, add twitter:card with the appropriate type. For title and description, you can rely on Open Graph tags as fallback.

11. Hreflang Tags

If your site serves content in multiple languages or targets multiple regions, each page needs <link rel="alternate" hreflang="x"> tags for all variants, including a self-referencing tag and x-default fallback. Without them, Google might suppress regional pages as duplicates.

What "bad" looks like: Missing x-default tag. Hreflang pointing to non-existent pages. Non-reciprocal implementation (page A links to B, but B does not link back to A).

Fix: Implement hreflang consistently across all variants. Always include x-default. For large sites, use the sitemap-based approach to reduce page bloat.

12. Schema.org / JSON-LD

Pages should include structured data using JSON-LD format with the correct schema type (Article, Product, FAQPage, etc.) and all required fields. Structured data enables rich results -- star ratings, FAQ accordions, product prices -- which significantly increase click-through rates.

What "bad" looks like: No structured data on pages that qualify for rich results. Wrong schema type (Article schema on a product page). Required fields missing (Article without datePublished or author). Invalid JSON-LD syntax.

Fix: Implement JSON-LD with appropriate types and required fields. Validate with Google's Rich Results Test. Monitor the Enhancements section in Search Console.

13. HTTP Status Code

Every page should return 200. Track pages returning 301/302 redirects, 404, or 5xx errors. A page returning 404 will be deindexed. Intermittent 5xx errors reduce crawl frequency.

What "bad" looks like: Sitemap pages returning 404. Intermittent 5xx on important pages. Soft 404s (200 status but "page not found" content). 302 redirects where 301 is appropriate.

Fix: Monitor status codes on every crawl. Remove 404 pages from your sitemap. Convert temporary redirects to permanent when the move is indeed permanent.

14. Redirect Detection

Track redirect chains -- multiple redirects before reaching the final destination. Each hop adds latency and dilutes link equity. Google follows up to 10 redirects but efficiency drops after 4 or 5.

What "bad" looks like: Chains with 3+ hops. Redirect loops. Mixed protocol redirects (HTTP to HTTPS to HTTP). Redirects landing on 404 pages.

Fix: Flatten chains so every redirect points directly to the final destination. Update internal links to use the final URL. After migrations, periodically audit your redirect map for accumulated chains.

15. Broken Internal Links

Crawl every internal link on each page and verify the target returns 200. Broken links waste crawl budget, create dead ends for users, and waste link equity flowing through your internal linking structure.

What "bad" looks like: Links to deleted or moved pages. Links with typos. Links to draft content. Links using old URL patterns after a migration.

Fix: Run crawls that check every internal link. Fix or remove broken ones. After migrations, set up redirects and update internal links. For large sites, automated broken link detection is essential.

16. Image Alt Text

Every content image should have an alt attribute. Alt text makes images accessible to visually impaired users and gives search engines text to index in Image Search. Decorative images should use empty alt="".

What "bad" looks like: Images with no alt attribute. Generic alt text: "image," "photo," "IMG_4532.jpg." Keyword-stuffed alt: "best cheap shoes buy shoes online discount shoes."

Fix: Write descriptive alt text conveying the image's content and purpose. "Red leather running shoe with white sole, side view" is better than "shoe."

17. Sitemap Membership

Verify whether each page is included in your XML sitemap. The sitemap is your explicit declaration of which pages matter. Missing pages may be crawled less frequently. Pages in the sitemap returning 404 waste crawl budget.

What "bad" looks like: Important pages missing from the sitemap. Sitemap containing 404 or redirect URLs. Sitemap containing noindexed pages (contradictory signals).

Fix: Generate sitemaps dynamically. Include only canonical, indexable pages returning 200. Submit through Search Console and Bing Webmaster Tools.

18. Robots.txt Compliance

Verify each page is allowed by robots.txt. A single overly broad Disallow rule can block entire sections from crawling. Unlike noindex, robots.txt prevents access entirely -- crawlers cannot even see directives on the blocked page.

What "bad" looks like: Important sections blocked. CSS/JS files blocked (prevents rendering). Wildcard rules matching important URLs. Leftover Disallow: / from staging.

Fix: Keep rules simple and specific. Test changes with Search Console's robots.txt tester before deploying. Never rely on robots.txt for security -- it is a crawling directive, not an access control mechanism.

19. Core Query Presence

For pages targeting specific keywords, verify those keywords appear in the body text. This happens more often than you would think: a page is supposed to rank for a term, but the term never appears in the content -- common on heavily visual pages or after rewrites.

What "bad" looks like: Target phrase absent from body text entirely. Keywords appearing only in navigation or footer, not main content. Content using only synonyms, never the target phrase.

Fix: Define target keywords for important pages. Verify they appear naturally in body content. Once or twice in a substantial piece is sufficient.

20. Content Hash

Generate a SHA-256 hash of body content on every crawl. Compare hashes between crawls to detect changes. This lets you correlate content modifications with ranking changes.

What "bad" looks like: No change tracking (you discover removed content only after rankings drop). Tracking full-page HTML instead of body content (session tokens and ad rotations create false positives).

Fix: Hash extracted body content (after stripping boilerplate) on every crawl. When the hash changes, flag for review. This requires automated crawling -- it is nearly impossible manually at scale.

21. URL Normalization

Verify URLs are tracked in normalized form -- tracking parameters stripped (UTM, fbclid, gclid) and trailing slashes treated consistently. Without normalization, /products/widget, /products/widget/, and /products/widget?utm_source=newsletter look like three different pages.

What "bad" looks like: Same page tracked under 5 URLs because of query parameters. Inconsistent trailing slashes creating duplicates. Tracking parameters polluting canonical tags.

Fix: Strip known tracking parameters before storing or comparing URLs. Choose a trailing slash convention and enforce it with redirects. Ensure canonical tags point to the clean URL.

Site Infrastructure Checks

Beyond per-page audits, several site-wide elements affect your entire site's SEO performance.

HTTPS and Redirects

Every page should be served over HTTPS with HTTP versions 301-redirecting to HTTPS. Check that your SSL certificate is valid and covers all subdomains. Eliminate mixed content warnings (HTTPS pages loading HTTP resources).

robots.txt Analysis

Your robots.txt should be accessible at the site root, syntactically valid, and not overly restrictive. Validate it references your sitemap and does not block CSS/JS files that crawlers need to render pages.

sitemap.xml Validation

Your XML sitemap should be valid, contain only canonical and indexable URLs returning 200, and be referenced in robots.txt and submitted in Search Console. For large sites, use a sitemap index referencing multiple files.

llms.txt Detection

llms.txt is an emerging standard for declaring how large language models should interact with your content, similar to how robots.txt guides traditional crawlers. Checking for its presence keeps you aware of this developing standard.

Viewport Meta, Charset, Lang Attribute, and Favicon

Verify that the viewport meta tag is present for responsive design, charset is declared, the <html lang> attribute matches content language, and a favicon is defined. Missing these does not cause dramatic ranking drops, but their absence affects user experience and mobile usability scores.

The Audit Is Not a Project. It Is a Process.

There is a tempting narrative around technical SEO audits: run one, fix everything, done. Check the box.

This narrative is wrong. Your site is a living system. Developers push code weekly. Editors publish daily. Integrations update, plugins change behavior, hosting configurations drift. Every change can introduce issues.

Consider what can go wrong between audits:

• A developer removes canonical tags from 200 pages during a template change
• A content editor publishes 15 posts without meta descriptions
• Migration redirects expire, creating hundreds of 404 errors
• Staging configuration deploys to production with noindex tags
• A CDN migration breaks image URLs, eliminating alt text

If you audit quarterly, each issue has up to three months to damage organic performance before you notice. The alternative is continuous automated monitoring. Tools like SEO Monitor crawl your pages on a schedule, run all 21 checks automatically, track changes between crawls, and alert you when something breaks. Issues get caught in days instead of months.

This is not about replacing human judgment. It is about ensuring that when you make strategic SEO decisions, you are working from accurate, current data -- not from a snapshot that was already stale before the report was finished.

FAQ

How often should I run a technical SEO audit?

Quarterly is the minimum for most sites, monthly is better — even a DIY audit for a small business should follow this cadence. But the real answer is that important checks should run on every crawl -- weekly or daily for pages that change frequently. Automated tools make this practical even for large sites.

Do I need to check all 21 items on every page?

For a comprehensive audit, yes. In practice, your top 50 pages by organic traffic deserve full scrutiny. For deeper pages, focus on checks most likely to surface issues: broken links, missing titles, thin content, and status code errors.

What is the difference between a technical SEO audit and a content audit?

A technical audit focuses on how pages are structured and served: markup, status codes, and crawlability. A content audit evaluates what pages say: relevance, quality, keyword targeting. Both are necessary. This checklist covers the technical side, though checks like word count and core query presence bridge the gap.

Can I do this with free tools?

You can check individual items with free tools -- Search Console for indexing, Chrome DevTools for markup, Screaming Frog (free up to 500 URLs) for crawling. The challenge is doing all 21 checks consistently, across all pages, on a regular schedule, tracking changes over time. That is where SEO Monitor or similar automated platforms earn their value.

Which checks matter most for e-commerce sites?

For e-commerce, focus on product page schema markup (Product schema with price, availability, and reviews), canonical URLs (products accessible via multiple category paths create rampant duplication), image alt text (crucial for Google Shopping visibility), and status codes (out-of-stock products returning 404 instead of staying live with an availability signal). Thin content is also common on product pages that rely entirely on images with no descriptive text.

What should I fix first?

Prioritize by impact: pages with accidental noindex (immediate traffic recovery), broken links on high-traffic pages, missing or duplicate title tags on pages with ranking potential, and redirect chains on pages with significant backlink profiles. Then work through remaining issues systematically, starting with your highest-traffic pages.