The Complete Technical SEO Audit Guide (2026)

Every time a client shares their Google Search Console with me, I run through the same mental checklist before I open the Performance report. Indexing gaps, crawl budget waste, broken redirect chains — these are the silent traffic killers that no amount of content or link building can overcome. This guide walks through every step of a technical SEO audit the way I run them for clients: methodically, in priority order, with the actual tools and decisions involved at each stage.

What Is a Technical SEO Audit?

A technical SEO audit is a systematic review of your website’s infrastructure to identify everything that prevents search engines from crawling, indexing, and ranking your pages effectively. It does not cover content quality or backlinks — those are separate disciplines with their own audit processes. Technical SEO is exclusively about the foundation: site speed, crawlability, URL structure, HTTPS configuration, structured data, and how efficiently Googlebot can discover and process your content.

Think of it like a building inspection before renovation. You wouldn’t add new rooms to a structure without checking the foundation, wiring, and plumbing first. Publishing new content onto a site with unresolved crawl issues or widespread duplicate content is exactly that kind of mistake. I’ve seen clients spend three months producing content, only to discover a misplaced noindex tag had been blocking their entire blog from Google’s index. A technical audit catches that before it becomes a three-month loss.

Technical SEO covers three broad concerns:

• Crawlability: Can search engines discover and access your pages?
• Indexability: Once crawled, will Google decide to index those pages?
• Renderability: When Google renders the page, does it see the content you intend?

All three can fail independently. A page can be crawled but not indexed (thin content, duplicate content). A page can be indexed but rendered incorrectly (JavaScript-heavy content that Google can’t parse). A page can render correctly but be blocked from ranking by a crawl budget issue. A thorough audit checks all three layers.

When Should You Run a Technical SEO Audit?

Most site owners audit once, fix what they find, and assume the job is done. In practice, technical issues are introduced continuously — through plugin updates, new content, CMS configuration changes, and hosting migrations. I recommend a full technical audit at these specific triggers:

• Before any sustained content push: Catch blockers before you invest in writing. Publishing 50 articles onto a site with crawl budget issues means 50 articles competing for the same limited crawl attention.
• After any site migration: URL changes, CMS switches, domain moves, and HTTPS migrations all create redirect chains and orphaned URLs. Migrations are the single most common cause of catastrophic traffic drops I’ve investigated.
• After a Google algorithm update where rankings drop: Technical issues are rarely the direct cause, but they amplify the impact of algorithm changes. A site with poor Core Web Vitals takes a harder hit from a page experience update than a technically healthy one.
• Every 3–6 months as a health check: Particularly for sites that change frequently — ecommerce, news, or rapidly growing blogs.
• When organic traffic drops unexpectedly: A sudden drop with no obvious content cause is almost always a technical issue — an accidental noindex, a robots.txt change, or a server error.

Tools You Need for a Technical SEO Audit

You don’t need to spend thousands. Here’s the stack I use for client audits:

For most WordPress sites, Screaming Frog plus Google Search Console covers the full audit without any paid subscriptions. GSC is the most important tool on that list — it gives you real data from Googlebot itself, not a simulation. Lab tools like GTmetrix can lie; GSC field data cannot.

Before starting the crawl, configure Screaming Frog to mimic Googlebot’s user agent. Go to Configuration → User-Agent → select Googlebot (Desktop). This way you’re crawling as Google sees you, not as a generic browser.

Step 1: Crawl Your Website

Open Screaming Frog, enter your domain, and run a full crawl. For sites under 500 pages, the free version works. Once complete, work through these tabs systematically:

Response Codes

Filter for 4xx errors (client errors) and 5xx errors (server errors). Every 404 on an internal link represents a broken user experience and a wasted crawl budget signal. Export this list — you’ll need it for Step 3. Pay particular attention to 404s that have inbound internal links: those are the ones Google is actively trying to crawl and failing on.

Page Titles

Look for: missing titles, duplicate titles across different pages, titles exceeding 60 characters (Google typically rewrites these), and titles that don’t include the target keyword. Duplicate titles are a significant issue on WooCommerce sites where product variants often share identical title tags.

Meta Descriptions

Missing or duplicate meta descriptions don’t directly affect rankings, but they affect click-through rate. Google will auto-generate a snippet if the meta description is missing, and it rarely picks the most compelling text. Review and write custom meta descriptions for your most important pages first.

H1 Tags

Every page should have exactly one H1. Flag: missing H1s, multiple H1s on the same page (common in Elementor builds where the hero section and the main content area both use H1 styling), and H1s that are significantly different from the page title.

Images

Missing alt text is the most common image issue I find on WordPress sites. Filter the Images tab for alt text missing or empty. On Elementor-built pages, background images added via the widget Background settings don’t generate an <img> tag at all — they’re purely decorative from an SEO perspective. Only foreground images in the Image widget or text blocks contribute to image SEO.

Links

Check the Inlinks tab for your most important pages. Any page with zero or very few internal links pointing to it is an orphan — Googlebot discovers it less frequently and it receives minimal PageRank flow from the rest of the site. Building internal links to these pages is a quick win.

Step 2: Check Indexing and Crawlability in GSC

In GSC, navigate to Indexing → Pages. This view shows exactly why Google hasn’t indexed certain pages. The categories that need immediate investigation:

Crawled — Currently Not Indexed

Google visited the page but decided not to index it. Most common causes: thin content (a page with fewer than 300 words of unique content), near-duplicate content (a page covering the same topic as a stronger existing page), or pages without sufficient incoming links. These are content quality issues, not technical ones — but they show up in a technical audit.

Discovered — Currently Not Indexed

Google knows about the page from your sitemap or internal links, but hasn’t crawled it yet. This is a crawl budget problem. Common on sites with thousands of pages, or sites that produce content faster than Googlebot can keep up. Improving site speed, reducing low-quality pages, and tightening internal linking structure all help here.

Excluded by noindex Tag

Verify every page in this list is intentionally excluded. I’ve found client WordPress staging environments where a developer left Settings → Reading → Discourage search engines enabled when pushing to production. That one checkbox noindexes your entire site. It’s the first thing I check when a client reports that their whole site disappeared from search results.

Alternate Page with Proper Canonical Tag

Expected for paginated archives and duplicate parameter URLs — but open a sample and verify the canonical tag is pointing where you intend. A self-referencing canonical is correct on most pages. A canonical pointing to a different URL means you’re telling Google to treat this page as a duplicate of another.

Crawl Stats

Under Settings → Crawl Stats, review the response code breakdown over the past 3 months. A growing volume of 5xx server errors means Googlebot is hitting your server and getting refused — it will reduce crawl frequency over time. A spike in 404s following a content cleanup or migration means redirect handling is incomplete.

Step 3: Fix Crawl Errors and Redirect Chains

In Screaming Frog, go to Reports → Redirect Chains. A redirect chain is when A redirects to B, which redirects to C, when it could go directly from A to C. Chains add latency, dilute PageRank flow, and are a sign of accumulated technical debt. The fix is simple: update the original redirect to point directly to the final destination URL.

Handling 404 Errors

For every 404 in your list, make a decision:

1. Content has moved to a new URL: 301 redirect the old URL to the new one.
2. Content is permanently gone: Leave it as a 404. Do not redirect to the homepage — Google recognises this as a soft 404 and treats it the same as a real 404, just with extra steps.
3. The 404 URL has inbound backlinks: Prioritise a 301 to the most topically relevant live page to preserve the link equity.

On WordPress, I manage 301s with the Redirection plugin rather than .htaccess rules. It logs 404s automatically once installed, which means you can monitor for new broken URLs without running Screaming Frog every week. The plugin’s log view shows exactly which pages visitors (and bots) are trying to reach — an invaluable signal for redirect decisions.

Redirect Loop Detection

Screaming Frog flags redirect loops (A → B → A) in red. These are severe — Googlebot will abort the crawl of the affected URLs and stop trying. Fix them immediately by tracing the chain and breaking the cycle.

Step 4: Audit Site Speed and Core Web Vitals

Core Web Vitals became a confirmed Google ranking signal in 2021 and have been refined since. As of 2024, the three metrics that matter for ranking:

• LCP (Largest Contentful Paint): Time until the main content element loads. Target: under 2.5 seconds. Common culprits: unoptimised hero images, slow server response times, render-blocking resources.
• INP (Interaction to Next Paint): Replaced FID in March 2024. Measures how quickly the page responds to user interactions like clicks and taps. Target: under 200ms. Common culprits: heavy JavaScript, third-party scripts, long tasks on the main thread.
• CLS (Cumulative Layout Shift): Measures unexpected visual shifts during page load. Target: under 0.1. Common culprits: images without explicit dimensions, ads that load and push content down, web fonts causing text reflow.

Always check PageSpeed Insights for field data first, not lab data. Field data comes from real Chrome users (the Chrome User Experience Report) and is what Google actually uses for ranking decisions. Lab scores are useful for debugging specific optimisations, but a perfect lab score with poor field data still means a poor ranking signal.

Common WordPress Speed Issues and Fixes

After auditing dozens of WordPress sites, the same performance bottlenecks appear repeatedly:

• No server-side caching: Every uncached page request requires PHP and database processing. On shared hosting, this adds 800ms to 2+ seconds per page. Fix: WP Rocket, LiteSpeed Cache, or WP Super Cache depending on your hosting stack.
• Uncompressed images: A JPEG hero image over 500KB will single-handedly fail your LCP on mobile. Fix: convert to WebP, compress with ShortPixel or Imagify, and add explicit width/height attributes to prevent CLS.
• Render-blocking resources: CSS and JavaScript loaded in the <head> block rendering. Page builders like Elementor load significant CSS upfront. Fix: defer non-critical JS, inline critical CSS above the fold, lazy-load below-fold scripts.
• No CDN: If your server is in the US and your visitors are in Australia, every uncached asset takes 200ms+ just in network latency. Fix: Cloudflare (free tier) handles most sites adequately.
• Too many HTTP requests: Each plugin adding its own CSS and JS file compounds the load time. Fix: use a caching plugin that concatenates and minifies assets, and audit active plugins — remove any that aren’t actively earning their performance cost.

My default speed stack for WordPress: LiteSpeed Cache on LiteSpeed-powered hosting, or WP Rocket + Cloudflare on Apache/Nginx. That combination resolves the majority of performance issues without requiring theme file customisation.

Step 5: Mobile-Friendliness Check

Google uses mobile-first indexing for all sites, which means the mobile version of your site is what Google primarily crawls and uses for indexing and ranking. If your mobile site has less content than your desktop site, Google is effectively ranking an incomplete version of your content.

In GSC, go to Experience → Mobile Usability. Common issues I find on WordPress sites:

• Text too small to read: Font sizes below 12px on mobile, often caused by desktop-only font size settings in Elementor that weren’t overridden for mobile breakpoints.
• Clickable elements too close together: Navigation links or CTA buttons with less than 48px tap target size, making them difficult to interact with on touchscreens.
• Content wider than screen: Elements with fixed pixel widths that exceed the viewport width on mobile, causing horizontal scroll — a near-guaranteed negative ranking signal.
• Elementor tabs/accordions hiding content: Content inside collapsed accordions is visible in the DOM and indexed by Google, but interactive elements that fail to initialise on certain mobile browsers can cause content to be invisible to users.

For Elementor sites specifically: always review the design at every breakpoint in the Elementor editor itself, not just in Chrome DevTools device emulation. The two don’t always produce identical results, and Elementor’s responsive overrides are set per-breakpoint in the widget settings panel, not in the site’s CSS.

Step 6: HTTPS and Security

Every site should be on HTTPS. If yours isn’t, that’s the highest priority fix before anything else — it’s a direct ranking factor, it activates modern web features, and it’s a trust signal that affects conversion rates alongside rankings.

Even if you’re fully on HTTPS, check for mixed content: pages that load via HTTPS but reference HTTP resources (images, stylesheets, scripts). Mixed content causes browser security warnings and can silently break functionality. In Screaming Frog, use the Security tab to identify any HTTP resources loaded on HTTPS pages.

Additional checks:

• SSL certificate expiry: Check via your hosting control panel or a tool like SSL Checker. An expired certificate takes your site offline for HTTPS visitors instantly.
• HTTP → HTTPS redirect: Every HTTP URL should 301 redirect to its HTTPS equivalent. Test by typing http://yourdomain.com in a browser — it should automatically redirect to HTTPS.
• www vs non-www canonicalisation: Pick one version (www or non-www) and ensure all traffic redirects to it. Both versions being accessible creates duplicate content at the domain level.
• HSTS header: HTTP Strict Transport Security tells browsers to always use HTTPS for your domain. Cloudflare enables this automatically; on other stacks, it may need manual configuration.

Step 7: URL Structure and Site Architecture

Good URL structure serves two purposes: making URLs readable and meaningful for users, and structuring the site in a way that helps search engines understand content relationships and efficiently distribute PageRank.

Principles I Apply

• Flat architecture: Most content should be reachable within 3 clicks of the homepage. Deeply nested pages (e.g., /blog/category/subcategory/year/month/post-name/) receive less crawl budget and minimal internal PageRank. Flatter structures keep authority concentrated.
• Focus keyword in the slug: Use the primary keyword phrase, keep it to 3–5 words, use hyphens not underscores. Never use stop words (the, a, an, of) unless the keyword specifically requires them.
• Consistent permalink structure: Set your WordPress permalink structure in Settings → Permalinks and don’t change it later. Changing permalink structure on an established site requires a comprehensive redirect strategy — I’ve seen this mistake wipe out months of ranking progress.
• Clean parameter URLs: Session IDs, tracking parameters, and faceted navigation parameters should not generate indexable URLs. Use rel="canonical" to point parameter variants to the canonical version.

Silo Structure for Topical Authority

For a content-heavy site, organising content into topic silos helps search engines understand your site’s expertise in specific areas. A silo groups a pillar page with all its supporting articles under a shared category. All articles in the silo link to the pillar; the pillar links back to all supporting articles. This internal linking pattern concentrates topical authority on the pillar and signals cluster coverage to Google. You can read more about how I implement this in the SEO guides section.

Step 8: Duplicate Content and Canonical Tags

Duplicate content doesn’t trigger a penalty in most cases, but it causes Google to divide indexing and ranking signals across multiple versions of the same content — weakening all of them. Common sources on WordPress:

• Category and tag archives: WordPress by default shows full post content in archives. Switch to excerpts (Settings → Reading → For each article in a feed, show: Summary) or add a noindex to archive pages if they have no standalone value.
• Paginated archives: /page/2/, /page/3/ etc. These are expected and handled by Google’s pagination understanding — don’t noindex them, but don’t expect them to rank independently either.
• WooCommerce product variants: Products available in multiple colours/sizes can generate duplicate or near-duplicate pages. Use canonical tags pointing to the main product page.
• www/non-www and HTTP/HTTPS versions: All four combinations of your URL (http://, https://, with www, without www) should redirect to a single canonical version. Any that don’t are creating duplicate domains.
• Printer-friendly pages: Some themes or plugins generate ?print=1 or similar parameter versions. Block with robots.txt or canonicalise to the original.

In Screaming Frog, use the Canonicals tab to find pages where the canonical URL differs from the page’s own URL. Review each one to confirm the canonical is intentional and correct.

Step 9: Structured Data and Schema Markup

Structured data is JSON-LD markup embedded in your page HTML that explicitly tells search engines what type of content a page contains and what its properties are. It doesn’t directly improve rankings, but it can unlock rich results in SERPs — star ratings, FAQ accordions, breadcrumb trails, article metadata — all of which improve click-through rate.

Common schema types for a WordPress/freelancer site:

• Article or BlogPosting: Applied automatically by RankMath on posts. Defines author, datePublished, dateModified.
• FAQPage: Added manually as a JSON-LD block in posts with FAQ sections. Eligible for FAQ rich results that expand the SERP listing and take up significantly more screen space.
• Person: For the About page — links to social profiles, defines expertise areas.
• ProfessionalService or LocalBusiness: For Services pages — includes service area, contact details, review aggregation.
• BreadcrumbList: RankMath generates this automatically based on your post hierarchy.

Validate every schema implementation using the Google Structured Data documentation and the Rich Results Test tool. Errors in schema markup cause Google to ignore the entire markup block — so a JSON-LD syntax error silently removes any rich result eligibility.

In GSC, check Search appearance → Rich results after implementation. It takes a few weeks for Google to recognise and validate new structured data — monitor for errors and warnings in this section regularly.

Step 10: XML Sitemap and Robots.txt

XML Sitemap Health

Your XML sitemap tells search engines which pages exist on your site and hints at update frequency and relative priority. With RankMath on WordPress, the sitemap is auto-generated at /sitemap_index.xml. Key checks:

• Submitted to GSC: Under Indexing → Sitemaps. GSC reports on how many URLs were submitted vs. how many were successfully indexed — any large gap is worth investigating.
• No 4xx or redirect URLs in the sitemap: Your sitemap should only contain live, 200-status pages. A sitemap full of redirect URLs signals poor maintenance and wastes crawl budget.
• Noindex pages excluded: Pages with a noindex tag should not appear in your sitemap. RankMath handles this automatically, but verify if you’ve manually added pages to the sitemap.
• Images included: If you’re targeting image search or have visually rich content, RankMath’s image sitemap helps Google discover and index your images.

Robots.txt Audit

Your robots.txt file at yourdomain.com/robots.txt controls which areas of your site crawlers are allowed to access. The most critical check: nothing you want indexed is accidentally blocked.

The most damaging robots.txt mistake I’ve encountered on WordPress sites: Disallow: /wp-content/uploads/ or Disallow: /wp-content/. This blocks Googlebot from accessing your CSS and JavaScript files, which prevents it from rendering your pages correctly. Google renders pages like a browser — it needs CSS and JS to understand the page layout and content. Block those files and Google renders your pages as a wall of unstyled text.

Test your robots.txt in GSC’s URL Inspection tool. Fetch a specific page as Google and look at the “Page fetch” details — it will show you exactly what resources were blocked during the crawl.

Step 11: Log File Analysis (Advanced)

Server log files record every request made to your server, including requests from Googlebot. Log analysis is the most underused tool in technical SEO, but it answers questions that no other method can: How often is Googlebot actually visiting your key pages? Which sections of the site is it spending time on? Is it hitting pages you don’t want crawled?

To access logs: contact your hosting provider, or if you’re on cPanel, find them under Metrics → Awstats / Raw Access. Filter the log for requests where the user agent contains “Googlebot”.

What to look for:

• High-value pages being crawled infrequently: If Googlebot visits your key landing pages less than once a week on a site that updates regularly, you have a crawl budget issue.
• Googlebot spending time on unimportant pages: Parameter URLs, admin pages, or search result pages eating crawl budget that should go to your content.
• Crawl rate drops: A sudden reduction in Googlebot visits often precedes a ranking drop. It can indicate server errors that discourage Googlebot from returning.

Log analysis is particularly valuable for larger sites (500+ pages) or sites that have experienced unexplained ranking volatility. For small sites, GSC crawl stats provide sufficient visibility without the complexity of raw log parsing.

If you’d like a technical audit that includes log file analysis along with all the steps above, take a look at my technical SEO services — I include log analysis as part of full site audits for sites over 200 pages.

How to Prioritise Your Fix List

After a full audit, you’ll typically have more issues than you have time to fix immediately. Triage by impact and effort:

Document your audit findings in a spreadsheet with columns for: issue type, affected URL(s), priority level, fix action, and owner. Without a documented fix list, audits turn into one-time exercises rather than an ongoing improvement process.

For a fresh pair of eyes on your site’s technical health, get in touch. I run technical audits for WordPress businesses regularly and can identify the highest-impact issues within the first hour of analysis.

Also worth reading alongside this guide: the WordPress SEO Complete Guide for the on-page and content side of SEO, and the Local SEO Guide if you’re targeting location-specific searches.

Frequently Asked Questions

How long does a technical SEO audit take?

For a small site under 100 pages, a thorough technical audit takes 4–6 hours. Medium sites between 100 and 1,000 pages typically take 1–2 days, including time to compile and prioritise findings. Enterprise sites with tens of thousands of pages may require a week or more. The crawl itself is automated; the time investment is in interpreting the data, cross-referencing GSC findings, and building a prioritised fix roadmap that’s actually actionable.

How often should you run a technical SEO audit?

A full audit every 3–6 months is a sensible baseline for most sites. For sites that publish content frequently or run promotional campaigns that add and remove pages regularly, a monthly Screaming Frog crawl to catch new issues is worth the hour it takes. GSC monitoring should be continuous — set up email alerts for new crawl errors so you catch issues as they arise rather than during quarterly audits.

Can I do a technical SEO audit myself without an agency?

Yes — the tools are free and the process is learnable. Where an experienced auditor adds value is in knowing which issues are actually causing ranking problems versus which are cosmetically imperfect but functionally fine. A common mistake I see is site owners spending days fixing duplicate tag archive pages while a misconfigured robots.txt is blocking their most important landing pages from being crawled. The audit process reveals the issues; experience determines which ones to fix first.

What is the difference between a technical SEO audit and an on-page SEO audit?

A technical SEO audit examines infrastructure: crawlability, indexing, speed, HTTPS, URL structure, sitemaps, and structured data. An on-page SEO audit examines individual page content: keyword targeting, heading structure, meta tags, internal linking, content depth, and E-E-A-T signals. Both are necessary for ranking success, but technical issues take priority — a well-optimised page that can’t be crawled or indexed ranks nowhere.

Does a technical SEO audit guarantee better Google rankings?

No — but it removes the ceiling on your rankings. Technical issues are blockers. If Google can’t access or understand your content, no amount of link building or content optimisation will overcome that. Fixing a crawl error that was preventing 30 pages from being indexed doesn’t create rankings out of thin air — it unlocks the potential already built into those pages through content and authority. Think of it as clearing the path, not building the road.

What is the most important thing to fix in a technical SEO audit?

Anything that prevents your key pages from being crawled and indexed. Specifically: noindex tags applied to pages you want ranked, robots.txt rules blocking important directories, and widespread 5xx server errors discouraging Googlebot. After those — Core Web Vitals failures, because they have the most measurable relationship to ranking and user experience simultaneously. Everything else is important but secondary to ensuring Google can actually access and index your content.

Need help implementing this? I’m Daniyal — freelance SEO & WordPress expert. Contact me or find me on Upwork.

Related Guides

• SEO Marketing: Everything You Need to Know
• How Long Does SEO Take To Work?
• Technical SEO Checklist: Free 2026 Guide (Printable)
• How to Improve Technical SEO (Step-by-Step Guide)
• Best SEO Strategies for Small Business: Tested & Ranked (2026)