Technical SEO Guide:
Complete Audit Checklist

Verify Indexation in Google Search Console

Your first step in any technical SEO audit: check which pages Google has actually indexed. In Google Search Console, navigate to the Pages report (formerly Coverage report) to see the indexation status of every URL Google knows about. Pay special attention to pages marked “Crawled — currently not indexed” and “Discovered — currently not indexed” — these indicate pages Google found but chose not to include in its index.

Supplement this with a site:yourdomain.com search in Google to see what's actually appearing in results. If your important pages aren't indexed, investigate blocking directives (robots.txt, noindex tags), thin content issues, duplicate content, and internal linking deficiencies.

Optimize Crawl Budget Allocation

Direct Googlebot toward your most valuable pages and away from low-value URLs. Block crawling of admin pages, search results pages, faceted navigation URLs, and parameter-heavy duplicates using robots.txt. Strengthen internal linking to your most important pages so they get crawled more frequently. Remove or consolidate thin, low-value pages that consume crawl budget without providing search value.

Monitor your crawl stats in Google Search Console under Settings → Crawl Stats to understand how Googlebot is spending its budget on your site. If you see thousands of crawls on parameter URLs or low-value pages, you have a crawl budget efficiency problem.

Use Internal Linking to Aid Discovery

Googlebot discovers new pages primarily by following links from already-crawled pages. If a page has no internal links pointing to it (an “orphan page”), it may never be discovered or crawled — regardless of being in your sitemap. Ensure every important page receives at least 2-3 internal links from other pages on your site. Use descriptive anchor text that helps Google understand the linked page's topic.

Manage Noindex Directives Carefully

The noindex meta tag tells Google to crawl but not index a page. Use it for pages that should not appear in search results: thank-you pages, internal search results, admin pages, and tag/archive pages with thin content. Audit your noindex tags regularly — an accidentally applied noindex on a key page is one of the most common and damaging technical SEO errors. Use the URL Inspection tool in Search Console to verify a page's noindex status.

Allow Crawling of All Important Pages

The most important robots.txt rule: never block pages you want indexed. This sounds obvious, but it happens constantly — especially during site redesigns, staging environment transitions, and CMS migrations. Always verify that your robots.txt allows crawling of your homepage, product pages, category pages, blog content, and any other pages that should appear in search results. A single Disallow: / directive blocks your entire site.

Block Low-Value and Sensitive Paths

Use Disallow directives to prevent crawling of paths that waste budget or expose sensitive areas: admin panels (/admin/), staging environments, internal search results (/search?), cart and checkout pages, user account pages, and URL parameter variations that create duplicate content. Each blocked path frees crawl budget for your valuable content.

Include Your Sitemap Reference

Add a Sitemap: https://yourdomain.com/sitemap.xml directive to your robots.txt. This helps search engines discover your sitemap even if they haven't visited your site before or if you haven't submitted it through Search Console yet. It's a simple addition that ensures crawlers always know where to find your complete page inventory.

Test Before Deploying Changes

Always test robots.txt changes before deploying to production. Use the robots.txt Tester in Google Search Console to verify that your directives produce the intended results. Test specific URLs that should be allowed and URLs that should be blocked. A single mistyped directive can have site-wide consequences — this is not a file where you want to “deploy and see what happens.”

Include Only Indexable, Canonical Pages

Your sitemap should contain only pages that return a 200 status code, are not noindexed, and are the canonical version. Including redirected URLs, 404 pages, or noindexed pages sends confusing signals to search engines and wastes crawl resources. Audit your sitemap periodically to remove outdated entries and add newly published pages. Automated sitemap generation (built into most CMS platforms and frameworks like Next.js) prevents manual maintenance errors.

Use Sitemap Index Files for Large Sites

Individual sitemaps are limited to 50,000 URLs and 50MB uncompressed. For larger sites, use a sitemap index file that references multiple individual sitemaps, organized by content type or section (e.g., sitemap-products.xml, sitemap-blog.xml, sitemap-categories.xml). This organization helps you monitor crawl and indexation rates per content type in Search Console.

Submit to Google Search Console and Bing

Submit your sitemap through both Google Search Console and Bing Webmaster Tools. After submission, monitor the indexation report — Search Console shows how many submitted URLs are actually indexed versus excluded. A large gap between submitted and indexed URLs indicates quality or technical issues with those pages. Re-submit your sitemap after significant content additions or structural changes.

Keep lastmod Dates Accurate

The lastmod tag tells search engines when a page was last meaningfully updated. Only update this value when the page content actually changes — not on every build or deployment. Accurate lastmod dates help Googlebot prioritize crawling recently updated content. Inaccurate dates (setting everything to today's date) erode Google's trust in your sitemap signals over time.

Optimize and Compress Images

Images are the single largest contributor to page weight on most websites. Convert images to modern formats (WebP or AVIF) which are 25-50% smaller than JPEG/PNG at equivalent quality. Implement responsive images with the srcset attribute to serve appropriately-sized images for each device. Use lazy loading for below-the-fold images. Set explicit width and height attributes to prevent layout shift. Compress all images — even a 10% reduction across hundreds of images adds up dramatically.

Minify and Bundle CSS and JavaScript

Remove unnecessary characters from CSS and JavaScript files — comments, whitespace, and unused code. Bundle multiple files where possible to reduce HTTP requests. Use code splitting to load only the JavaScript needed for the current page. Defer non-critical JavaScript with the defer or async attribute. Move render-blocking CSS inline for above-the-fold content and load the rest asynchronously.

Implement a Content Delivery Network (CDN)

A CDN distributes your content across servers worldwide, serving pages from the location closest to each visitor. This dramatically reduces latency — especially for geographically distributed audiences. Major CDN providers (Cloudflare, Fastly, AWS CloudFront) also provide edge caching, DDoS protection, and automatic image optimization. For most sites, CDN implementation is one of the highest-impact, lowest-effort speed improvements available.

Enable Browser Caching

Configure cache-control headers to tell browsers to store static assets (images, CSS, JavaScript, fonts) locally for repeat visits. Set long cache durations (at least 1 year) for versioned assets and shorter durations for HTML pages. Proper browser caching means returning visitors experience near-instant page loads because most resources are already stored on their device. Use cache-busting techniques (file hashing) to ensure updated assets are served when you deploy changes.

Reduce Server Response Time (TTFB)

Time to First Byte (TTFB) measures how quickly your server responds to a request. Target TTFB under 200ms. Slow TTFB is usually caused by slow database queries, inefficient server-side code, inadequate hosting resources, or missing server-side caching. Upgrade hosting if needed — a $5/month shared hosting plan cannot deliver the performance Google expects. Use server-side caching (Redis, Varnish) for dynamic content and consider static generation for pages that don't change frequently.

Largest Contentful Paint (LCP) — Under 2.5 Seconds

LCP measures how quickly the largest visible content element loads — typically a hero image, featured banner, or large heading block. A good LCP is under 2.5 seconds on mobile. The most common causes of poor LCP: unoptimized hero images, slow server response times, render-blocking CSS/JavaScript, and client-side rendering that delays content visibility.

Fix poor LCP by: preloading hero images with <link rel="preload">, using responsive images at appropriate sizes, implementing a CDN, inlining critical CSS, and server-side rendering above-the-fold content. If your LCP element is an image, WebP/AVIF conversion alone often brings LCP under the 2.5-second threshold.

Interaction to Next Paint (INP) — Under 200ms

INP measures how quickly your page responds to user interactions — clicks, taps, and keyboard input. INP replaced First Input Delay (FID) in March 2024 and is a more comprehensive metric because it measures all interactions throughout the page lifecycle, not just the first one. Target under 200ms.

Poor INP is usually caused by heavy JavaScript execution blocking the main thread. Fix it by: breaking up long JavaScript tasks (over 50ms) into smaller chunks, using requestAnimationFrame or setTimeout to yield to the browser, minimizing third-party scripts, debouncing frequent event handlers, and using web workers for computation-heavy operations.

Cumulative Layout Shift (CLS) — Under 0.1

CLS measures how much the page layout shifts during loading. Those annoying moments when you're about to click a button and it jumps because an image or ad loaded above it — that's layout shift. A good CLS score is under 0.1.

The most common CLS culprits: images without width/height attributes, ads or embeds that inject content, fonts that cause text to reflow (FOUT/FOIT), and dynamically injected content above the viewport. Fix these by: always setting explicit dimensions on images and video embeds, reserving space for ads with CSS, using font-display: swap or preloading fonts, and avoiding inserting content above existing content after initial render.

Ensure Responsive Design Across All Devices

Use responsive CSS that adapts to any screen size — phones, tablets, laptops, and desktops. Test on actual devices, not just browser developer tools (which can miss touch interaction issues, actual rendering performance, and real-world network conditions). Verify that all content, images, and functionality available on desktop are equally accessible on mobile. Google penalizes mobile experiences that hide content or features behind “desktop only” gates.

Optimize Touch Targets and Readability

All clickable elements need minimum 48x48 pixel touch targets with adequate spacing between them. Text should be readable without zooming — minimum 16px body font size. Line height should be at least 1.5 for comfortable reading on small screens. Form fields should be appropriately sized and use the correct input types (email, tel, number) to trigger the right mobile keyboard.

Eliminate Horizontal Scrolling and Overflow

No element should cause horizontal scrolling on mobile. This includes images wider than the viewport, tables without responsive handling, code blocks without overflow wrapping, and fixed-width elements. Use max-width: 100% on images, responsive table patterns (horizontal scroll within the table container, not the page), and media queries to adjust layouts at breakpoints.

Avoid Intrusive Interstitials

Google penalizes mobile pages with intrusive interstitials — popups, overlays, and modal dialogs that cover the main content immediately on page load. This includes email signup popups, cookie banners that cover most of the screen, and app install prompts. Small banners that use a reasonable amount of screen space are acceptable. Full-screen popups triggered by user interaction (rather than on page load) are also generally acceptable.

Implement SSL/TLS Across All Pages

Every page on your site must load over HTTPS — not just checkout or login pages. Most hosting providers (Vercel, Netlify, AWS, Cloudflare) offer free SSL certificates. After implementation, verify that all HTTP URLs redirect to their HTTPS equivalents with 301 permanent redirects. Check for mixed content warnings — a single HTTP resource (image, script, stylesheet) loaded on an HTTPS page triggers browser security warnings.

Update All Internal References to HTTPS

After migrating to HTTPS, update all internal links, canonical tags, sitemap URLs, and hreflang annotations to use HTTPS. Outdated HTTP references create unnecessary redirect chains (HTTP → HTTPS) that slow down page loads and waste crawl budget. Search through your codebase, database, and CMS for any remaining http:// references to your own domain and update them.

Implement Security Headers

Beyond HTTPS, implement security headers that protect your visitors and improve your site's trust signals: Strict-Transport-Security (HSTS) forces browsers to always use HTTPS, X-Content-Type-Options: nosniff prevents MIME type sniffing, X-Frame-Options: DENY prevents clickjacking, and Content-Security-Policy controls which resources the browser is allowed to load.

Add Self-Referencing Canonical Tags

Every indexable page should include a <link rel="canonical" href="..."> tag pointing to its own URL. Self-referencing canonicals protect against duplicate content created by URL parameters, trailing slashes, session IDs, and tracking tags. Without them, Google may index multiple URL variations of the same page and split your ranking signals. Implement canonical tags in your page template so every new page gets one automatically.

Resolve Common Duplicate Content Sources

The most common sources of duplicate content: www vs non-www, HTTP vs HTTPS, trailing slash vs no trailing slash, URL parameters (?ref=, ?utm_), and pagination. Choose one canonical version for each case and implement 301 redirects for all other versions. For example, if your canonical format is https://www.example.com/page (HTTPS, www, no trailing slash), redirect all other variations to this format.

Handle Pagination Correctly

For paginated content (blog archives, product listings), each paginated page should have a self-referencing canonical pointing to itself — not to page 1. Page 2 of results is distinct content, not a duplicate of page 1. Google deprecated rel="prev"/"next" as an indexing signal in 2019, so canonical tags and internal linking are now your primary pagination tools. Consider infinite scroll or “load more” patterns that keep all content on a single URL where possible.

Consolidate Thin and Similar Pages

If you have multiple pages covering nearly identical topics, consolidate them into one comprehensive page and 301 redirect the others. Two thin pages competing for the same keyword will both rank poorly, while one comprehensive page combining their content can rank well. This is especially common with blog posts, location pages, and product variations.

Implement Hreflang Tags Correctly

Hreflang uses the format <link rel="alternate" hreflang="en-us" href="..."> to specify language-region targeting. Every page must include hreflang tags for all its language/region versions, including a self-referencing tag. Add an x-default hreflang tag pointing to your default version (usually the English page) for users whose language or region does not match any specific version. Hreflang annotations must be reciprocal — if page A references page B, page B must reference page A.

Choose Your International URL Structure

Three options: ccTLDs (example.fr, example.de) provide the strongest geo-targeting signal but require managing separate domains. Subdirectories (example.com/fr/, example.com/de/) keep everything on one domain and are easiest to manage. Subdomains (fr.example.com) offer a middle ground. For most businesses, subdirectories are the recommended approach — they consolidate domain authority and simplify technical management while still allowing effective hreflang implementation.

Avoid Common Hreflang Mistakes

The most common hreflang errors: non-reciprocal annotations (page A references page B but not vice versa), incorrect language codes (using “uk” instead of “en-gb”), hreflang on non-canonical URLs, missing self-referencing tags, and pointing hreflang to redirected URLs. Google's International Targeting report in Search Console flags many of these errors — check it regularly if you use hreflang.

Use Server-Side Rendering (SSR) for SEO Content

For all pages that need to rank in search, render content on the server so it's present in the initial HTML response. Frameworks like Next.js (with SSR or SSG), Nuxt.js, and Remix make this straightforward. Server-rendered pages are visible to Googlebot immediately upon crawling, without waiting for the rendering queue. Reserve client-side rendering for interactive elements that don't need to be indexed — like shopping carts, user dashboards, and configuration tools.

Ensure Metadata Is in the Initial HTML

Title tags, meta descriptions, canonical tags, hreflang annotations, and structured data must be present in the server-rendered HTML, not injected by JavaScript after load. While Google's renderer can pick up JS-injected metadata, there's a risk of it being missed or delayed. Server-rendering metadata eliminates this risk entirely and ensures instant availability for crawlers.

Test Rendering with Google's Tools

Use the URL Inspection tool in Google Search Console to see exactly how Googlebot renders your pages. Click “Test Live URL” and then “View Tested Page” to see the rendered HTML and a screenshot. Compare the rendered output to what you see in a browser — if critical content is missing, you have a JavaScript rendering issue. Google's Mobile-Friendly Test also shows a rendered screenshot that can reveal rendering problems.

Handle JavaScript-Dependent Links Properly

Googlebot follows standard <a href="..."> links but may not reliably follow JavaScript-triggered navigation like onClick handlers or router-based navigation without server-side rendering. Use standard HTML anchor tags for all links that should be discoverable by search engines. This applies to navigation menus, internal content links, breadcrumbs, and pagination — all should use proper <a> tags with valid href attributes.

Identify Googlebot Crawl Patterns

Filter your server logs for Googlebot requests (user agent contains “Googlebot”). Map out which pages Googlebot crawls most frequently and compare this to your most important pages. If Googlebot is spending most of its crawl budget on low-value pages (parameter URLs, tag pages, old blog posts) while rarely visiting your key product or service pages, you have a crawl priority problem that needs addressing through robots.txt, internal linking, or sitemap optimization.

Find Orphan Pages and Crawl Gaps

Cross-reference pages in your sitemap with pages actually crawled by Googlebot in your logs. Pages in your sitemap that Googlebot never crawls are effectively orphaned from a crawl perspective — they need stronger internal linking or may have crawl barriers you haven't detected. Conversely, pages that Googlebot crawls frequently but aren't in your sitemap may be discoverable only through internal links and deserve sitemap inclusion.

Detect Status Code Issues

Log files reveal every HTTP status code Googlebot encounters: 200 (success), 301/302 (redirects), 404 (not found), 410 (gone), and 5xx (server errors). A spike in 5xx errors indicates server stability problems that directly impact crawling. Chains of 301 redirects waste crawl budget. Persistent 404s on pages with external backlinks waste link equity. Monitoring these patterns weekly helps you catch and fix issues before they impact rankings.

Monitor Crawl Budget Efficiency Over Time

Track total Googlebot requests per day/week and the ratio of important vs. non-important pages crawled. If your site grows significantly (adding thousands of products or pages), verify that Googlebot's crawl rate scales proportionally. A stagnant crawl rate on a growing site means new content takes longer to be discovered and indexed. Improving crawl efficiency (blocking low-value pages, strengthening internal linking to important pages) can increase the effective crawl rate for your valuable content.