onezlabs

0%

SEO

Technical SEO Audit Checklist: 50 Points to Check in 2026

A complete technical SEO audit checklist covering crawlability, Core Web Vitals, structured data, and indexation — with tools and fixes for each issue.

May 1, 202614 min read
#Technical SEO#SEO Audit#Core Web Vitals#Crawlability#Schema#Indexation
Technical SEO Audit Checklist: 50 Points to Check in 2026

Why Technical SEO Still Decides Rankings

Content and links get all the attention in SEO discussions, but technical SEO is the foundation that makes both matter. A perfectly written article with excellent backlinks will not rank if Googlebot cannot crawl it, if the page takes 8 seconds to load, or if a misconfigured canonical tag points all link equity at a 404. I have done SEO work for clients across dozens of industries, and the fastest ranking improvements I have ever achieved came from fixing technical issues — not from writing more content.

This checklist covers 50 points across every layer of technical SEO. Work through it top to bottom on any site and you will surface the issues that are costing you rankings. I have organized it into sections so you can tackle one area at a time rather than trying to audit everything at once.

Before you start: Set up Google Search Console, run a full crawl with Screaming Frog (free up to 500 URLs, paid for larger sites), and pull a Lighthouse report on your five most important pages. These three tools cover 80% of what you need for a thorough audit.

Crawlability & Indexation (10 Points)

1. robots.txt is accessible and correct. Fetch yourdomain.com/robots.txt directly. Confirm it is not blocking /wp-admin, /wp-includes, or any assets that Google needs to render your pages. Check that it is not accidentally blocking everything with Disallow: / — this happens more often than you think after migrations.

2. XML sitemap is submitted and valid. Your sitemap should be at /sitemap.xml or /sitemap_index.xml, submitted in Google Search Console, and contain only canonical, indexable URLs. No 301 redirects, no noindex pages, no 404s in the sitemap.

3. No accidental noindex on important pages. Screaming Frog: filter by "Indexability Issues." Look for noindex meta robots or X-Robots-Tag headers on pages you want indexed. This is the #1 technical mistake I find on client sites.

4. Canonical tags are correct and consistent. Every page should self-canonical or point to the definitive version. Check for canonical chains (page A canonicals to page B which canonicals to page C) — Google may ignore them. Check that paginated pages are not all canonicalizing to page 1 unless you intend to consolidate them.

5. No orphan pages. Pages with no internal links cannot be discovered by Googlebot even if they are in your sitemap. In Screaming Frog, compare your sitemap URLs against the crawl data to find pages with zero inlinks.

6. Crawl budget is not wasted. Check your GSC Coverage report for "Crawled — currently not indexed" URLs. If Google is crawling thousands of filter pages, session ID URLs, or search result pages, add noindex or block them in robots.txt to redirect crawl budget to your real content.

7. URL parameters are handled correctly. E-commerce sites especially: sorting, filtering, and session parameters create duplicate content at scale. Use canonical tags or the URL Parameters tool in GSC (legacy) to tell Google which parameters to ignore.

8. Redirect chains are resolved. Every redirect chain (301 → 301 → final URL) loses a small amount of link equity and slows Googlebot. Use Screaming Frog to find chains and flatten them to direct 301s.

9. No broken internal links. Screaming Frog will list every 4xx response code encountered during the crawl. Fix or redirect all broken internal links — they waste crawl budget and break user experience.

10. Google can render your pages. Use GSC's URL Inspection tool on five key pages and click "Test Live URL." Verify the rendered HTML matches what a user sees. If JavaScript is rendering critical content that does not appear in the rendered HTML, Google may not index it.

Site Architecture & Internal Linking (8 Points)

11. No page is more than 3 clicks from the homepage. Pages buried deep in site architecture get crawled less frequently and rank less well. If important content is 6+ clicks deep, flatten the structure or add internal links from higher-level pages.

12. Important pages have high internal link counts. Use Screaming Frog to check inlink counts. Your money pages (service pages, product pages, pillar content) should have the most internal links pointing at them. Link equity flows through internal links just as it does through backlinks.

13. Anchor text is descriptive. "Click here" and "read more" waste internal linking opportunities. Use keyword-rich descriptive anchor text that tells both users and Google what the linked page is about.

14. Breadcrumbs are implemented correctly. Breadcrumbs serve both UX and SEO — they create additional internal links, help Google understand site hierarchy, and often appear in SERPs. Implement them with BreadcrumbList schema.

15. Pagination is handled. For paginated content (blog archives, product listings), use proper rel="next"/rel="prev" signals or ensure each page is self-canonical if you want it independently indexed.

16. No duplicate content at the URL level. Check for www vs. non-www, HTTP vs. HTTPS, trailing slash vs. no trailing slash creating duplicate pages. All variants should 301 to a single canonical version.

17. Navigation links important pages. Your main navigation is the most powerful source of internal links because it appears on every page. Ensure your highest-priority pages are accessible from the nav, even if buried in a dropdown.

18. Footer links are not over-optimized. Keyword-stuffed footer navigation with dozens of city + service links is a known spam pattern. Keep footer links to genuinely useful navigation — legal pages, top-level service categories, contact.

Core Web Vitals & Page Speed (10 Points)

19. LCP is under 2.5 seconds. Largest Contentful Paint measures when the main content appears. Check PageSpeed Insights on your five most important pages. The most common LCP culprit is an unoptimized hero image — convert to WebP/AVIF, add a preload link in the HTML head, and size it correctly. Check my website speed optimization service for what I do in practice.

20. INP is under 200ms. Interaction to Next Paint (replaced FID in 2024) measures responsiveness. High INP is usually caused by heavy JavaScript on the main thread — long tasks, unoptimized event listeners, or large third-party scripts. Use Chrome DevTools Performance panel to identify long tasks.

21. CLS is under 0.1. Cumulative Layout Shift measures visual stability. The most common causes: images without width/height attributes, web fonts causing layout shifts (use font-display: swap), and ads or embeds that push content down on load.

22. TTFB is under 800ms. Time to First Byte is not a Core Web Vitals metric but it directly affects all of them. High TTFB usually means slow server response, no caching, or a distant hosting location. A CDN like Cloudflare resolves most TTFB issues without changing your application.

23. Images are properly sized and in modern formats. Every image should be served in WebP or AVIF, sized to its display dimensions (not larger), and lazy-loaded below the fold. The hero image should be eager-loaded and preloaded.

24. Render-blocking resources are minimized. CSS and JavaScript in the <head> block rendering. Move non-critical scripts to deferred or async loading. Critical CSS should be inlined; non-critical CSS should be loaded asynchronously.

25. Third-party scripts are managed. Google Tag Manager, chat widgets, ad pixels, and A/B testing scripts all add JavaScript weight and can cause significant CLS and INP issues. Audit every third-party script and remove ones that are no longer needed.

26. Font loading is optimized. Use font-display: swap to prevent invisible text during font load. Preconnect to Google Fonts or self-host fonts to eliminate a DNS lookup on every page load. Limit the number of font weights you load.

27. Server-side caching is enabled. Full-page caching (via WP Rocket for WordPress, or HTTP cache headers for custom applications) dramatically reduces server response time. Verify that caching is working with browser DevTools — look for Cache-Control headers on HTML responses.

28. Resource hints are used correctly. Use <link rel="preconnect"> for third-party origins, <link rel="preload"> for the LCP image and critical fonts, and <link rel="prefetch"> for likely next-page resources. Over-use of preload is as bad as not using it — it competes for bandwidth.

On-Page Technical Signals (8 Points)

29. Every page has a unique, optimized title tag. Title tags should be 50-60 characters, include the primary keyword near the front, and be unique across the site. Screaming Frog can export all title tags for bulk review.

30. Meta descriptions are compelling and unique. Meta descriptions do not directly affect rankings but they do affect click-through rate from SERPs. Write unique, action-oriented meta descriptions of 150-160 characters for every important page.

31. H1 tags are present, unique, and contain the target keyword. One H1 per page. It should be the first heading and contain the primary keyword in a natural way. Check for pages with no H1 or multiple H1s in Screaming Frog.

32. Heading hierarchy is logical. H2s are section headings, H3s are subsections within H2s. Do not skip levels. A logical heading hierarchy helps both accessibility and how Google understands your content structure.

33. Images have descriptive alt text. Every meaningful image should have alt text that describes the image and includes relevant keywords where natural. Decorative images should have empty alt attributes (alt=""). Screaming Frog can identify images with missing alt text.

34. URLs are clean and keyword-rich. URLs should be lowercase, use hyphens (not underscores), contain the target keyword, and be as short as possible while remaining descriptive. Avoid dates, IDs, and irrelevant parameters in URLs.

35. Page content is unique and substantial. Check for thin content pages (under 300 words with little value) and near-duplicate pages. GSC Coverage report will show pages "Crawled — currently not indexed" which often signals thin content issues.

36. Open Graph and Twitter Card tags are set. While not a direct ranking factor, proper OG tags ensure your content looks good when shared on social media, which drives traffic and indirectly supports link building.

Structured Data & Schema (6 Points)

37. Organization or LocalBusiness schema is on the homepage. At minimum, your homepage should have Organization schema with your name, URL, logo, and contact information. Local businesses should use LocalBusiness (or a more specific type like ProfessionalService) with address, phone, and business hours.

38. Article/BlogPosting schema on blog posts. Every blog post should have Article or BlogPosting schema with headline, author, datePublished, and dateModified. This enables rich results in Google Discover and news surfaces.

39. FAQPage schema for FAQ sections. Any page with a true Q&A section should have FAQPage schema. This can unlock FAQ rich results in SERPs, adding significant visual real estate to your listing.

40. BreadcrumbList schema matches visible breadcrumbs. If you display breadcrumbs on the page, add matching BreadcrumbList schema. Google may show breadcrumb paths in search results instead of the raw URL.

41. No schema errors in Google Rich Results Test. Run every schema implementation through Google's Rich Results Test. Fix all errors before worrying about warnings. Invalid schema is worse than no schema in some cases.

42. Product schema for e-commerce pages. Product pages should include Product schema with name, image, description, offers (price, currency, availability), and ideally AggregateRating. This enables price and rating rich results.

Mobile & HTTPS (5 Points)

43. Site is fully HTTPS with no mixed content. All resources (images, scripts, stylesheets) must be loaded over HTTPS. Mixed content (HTTP resources on HTTPS pages) triggers browser warnings and can affect rankings. Check the browser console for mixed content errors.

44. Site passes Google's Mobile-Friendly Test. Use Google's Mobile-Friendly Test tool on your key pages. Common issues: text too small to read without zooming, clickable elements too close together, content wider than the screen.

45. Viewport meta tag is set correctly. Every page needs <meta name="viewport" content="width=device-width, initial-scale=1">. Missing or incorrect viewport settings cause mobile rendering issues that kill mobile UX and rankings.

46. Touch targets are large enough. Buttons and links should be at least 44x44 CSS pixels for comfortable mobile tapping. Use Chrome DevTools Device Mode to test tap target sizes.

47. No intrusive interstitials. Pop-ups that cover the main content immediately on mobile load are a Google penalty trigger. Cookie consent banners, age verification, and app install banners that cover content have all been used as penalty examples.

International & Hreflang (3 Points)

48. Hreflang is implemented if serving multiple languages/regions. Hreflang tells Google which version of a page to serve to which audience. If you serve English for UK and US separately, or have translated content, hreflang is essential. Each language/region pair must reference all other variants, and all must be consistent across the sitemap and page headers.

49. No hreflang errors. Use Screaming Frog or hreflang.com to validate your implementation. Common errors: missing return links (if page A hreflang points to page B, page B must point back to page A), broken URLs in hreflang, and incorrect language codes.

50. Correct country targeting in GSC. If your site serves a single country with a generic TLD (.com, .net), use the International Targeting report in GSC to set the target country. This helps Google understand your primary audience without requiring ccTLDs.

Tools & Audit Workflow

My standard audit workflow takes one to two days for a site under 10,000 pages. Day one: crawl with Screaming Frog, export all issues, check GSC for manual actions and coverage errors, run PageSpeed Insights on five key pages. Day two: validate structured data, check mobile usability, and prioritize the issue list by impact.

ToolWhat It CoversCost
Screaming FrogCrawlability, redirects, meta tags, canonical, imagesFree up to 500 URLs / £259/yr
Google Search ConsoleIndexation, coverage, Core Web Vitals field dataFree
PageSpeed InsightsCore Web Vitals lab + field data, specific recommendationsFree
Rich Results TestSchema validationFree
Ahrefs / SemrushBacklinks, organic traffic, site audit$99–$129/mo
Chrome DevToolsPerformance profiling, rendering, network waterfallFree

If you need help working through this checklist or want a professional technical SEO audit done for your site, I offer full audits with prioritized fix lists and implementation support. See my project portfolio for examples of past SEO work.

Frequently Asked Questions

How often should I run a technical SEO audit?

Run a full audit every quarter for active sites, and after every major site migration, CMS upgrade, or redesign. Set up continuous monitoring with Google Search Console and a crawl tool like Screaming Frog on a weekly schedule so you catch new issues between full audits.

What is the single most impactful technical SEO fix?

Fixing crawlability issues — specifically, ensuring that your most important pages are not accidentally blocked by robots.txt, noindex tags, or canonical tags pointing to the wrong URL. I have seen sites lose 80% of organic traffic from a single misconfigured robots.txt pushed in a deployment.

Do I need to fix every issue on the checklist?

No. Prioritize by impact and effort. Fix crawlability and indexation issues first — they block everything else. Then Core Web Vitals if you are failing them. Then structured data and on-page signals. Low-effort, high-impact wins first. Some issues on the list (like hreflang for a single-language site) simply do not apply to your situation.

Share:TwitterLinkedIn

Get the newsletter

Practical articles on AI development, full stack engineering, and WordPress — delivered whenI publish, not on a schedule. No spam, ever.

JO

Johnbert Oñez

AI Solutions Engineer & Full Stack Developer

Johnbert builds AI systems, web applications, and WordPress solutions for clients worldwide. Based in Davao City, Philippines. 6+ years, 50+ projects.

More Like This

Enjoyed the article? Let's build something together.

From AI chatbots to SaaS products — I turn ideas into working software. Based in Davao City, available worldwide.