Technical SEO Audit Checklist: A Step-by-Step Process for Business Sites

A practical technical SEO audit checklist: crawlability, indexing, site structure, redirects, canonicals, speed, mobile, structured data, international SEO and how to prioritise the fixes.

A technical SEO audit checklist verifies that search engines can crawl, render, index and understand your website. It covers server responses, robots.txt and noindex rules, XML sitemaps, canonical tags, redirects, internal linking, page speed, mobile usability, structured data and international settings. The output is a prioritised list of fixes, not a score.

This checklist is the one I use on client sites before any content or link work. It supports my entity SEO pillar.

What does a technical SEO audit include?

It includes four layers: access (can crawlers reach pages?), indexing (are the right pages indexed, and only those?), understanding (structure, canonicals, structured data, language) and experience (speed, mobile, security). Each layer depends on the one before, so audit in that order.

Tools to prepare

  • Google Search Console (verified for the domain property).
  • A crawler: Screaming Frog, Sitebulb or similar.
  • PageSpeed Insights and Chrome DevTools.
  • Rich Results Test and Schema Markup Validator.
  • Bing Webmaster Tools, which also offers useful diagnostics.
  • Optional: server access logs.

1. Crawlability

  • robots.txt exists, returns 200, and does not block important sections or CSS/JS files.
  • No accidental Disallow: / left from staging.
  • Server returns correct status codes: 200 for pages, 301 for moved, 404/410 for removed.
  • No 5xx errors under normal load (check Search Console crawl stats).
  • Important pages reachable within a few clicks from the home page.
  • No infinite URL spaces from filters, calendars or search parameters.

2. Indexing

  • Search Console Pages report reviewed: why are pages not indexed?
  • No noindex on pages that should rank; check templates and SEO plugin settings.
  • Thin or utility pages (tags with one post, internal search, cart, account) noindexed or excluded where appropriate.
  • XML sitemap lists only canonical, indexable 200 URLs, and is submitted.
  • Duplicate content handled: HTTP vs HTTPS, www vs non-www, trailing slash variants all resolve to one version.

Quick checks with curl:

curl -sI http://example.com/ | head -3
curl -sI https://www.example.com/ | head -3
curl -s https://example.com/robots.txt

3. Canonicals and redirects

  • Each indexable page has a self-referencing canonical.
  • Canonicals point to 200 pages, not redirects or 404s.
  • No redirect chains longer than one hop where avoidable; no loops.
  • Old URLs from past migrations still redirect correctly, see store migration.
  • Paginated archives are crawlable and not all canonicalised to page one.
  • Clear hierarchy: home → categories/services → detail pages.
  • Descriptive internal anchor text.
  • No orphan pages (indexable pages with no internal links).
  • Broken internal links fixed.
  • Breadcrumbs on deeper pages.
  • Topic clusters: pillar pages linking to supporting pages and back.

5. On-page technical elements

  • Unique title tags and meta descriptions on important pages.
  • One clear H1 per page; logical heading order.
  • Images have alt text and dimensions.
  • Clean URL slugs.
  • Content visible in the rendered HTML; important text not hidden behind interactions only.

6. Rendering

Modern search engines render JavaScript, but rendering can be delayed and errors can hide content.

  • Use Search Console’s URL Inspection “View crawled page” to check rendered HTML.
  • Main content and links present without user interaction.
  • No critical resources blocked by robots.txt.

7. Speed and Core Web Vitals

  • Search Console Core Web Vitals report reviewed for mobile and desktop.
  • Key templates tested in PageSpeed Insights.
  • Main issues traced to LCP, TBT/INP or CLS causes.

Details in the Core Web Vitals guide.

8. Mobile

Google uses mobile-first indexing, so the mobile version is the one that counts.

  • Same content and structured data on mobile as on desktop.
  • Readable text, tap targets large enough, no horizontal scroll.
  • No intrusive interstitials blocking content.

See the mobile-first design checklist.

9. Structured data

  • Organization/Person, WebSite and BreadcrumbList present and valid.
  • Article, Product, Service, FAQPage where relevant.
  • No duplicates from multiple plugins.
  • Rich Results Test passes on sample pages.

Guide: schema markup.

10. International and multilingual

  • Each language on its own URL.
  • Hreflang present and reciprocal.
  • lang and dir attributes correct (important for Arabic).

Guide: WordPress multilingual site.

11. Security and trust

  • HTTPS everywhere, valid certificate, no mixed content.
  • No security issues or manual actions in Search Console.
  • No spam pages injected (search site:yourdomain.com and look for content you did not publish).

12. AI search readiness

  • Key facts stated in plain text on crawlable pages.
  • robots.txt decisions about AI crawlers made deliberately, not by accident.
  • Optional llms.txt in place.

Prioritising findings

Score each issue on impact and effort:

  1. Blockers: noindex on key pages, robots blocks, 5xx errors, broken canonicals.
  2. High impact: duplicate versions, redirect chains on important URLs, missing internal links to money pages.
  3. Improvements: speed, structured data, titles.
  4. Hygiene: minor broken links, alt text gaps.

Each item gets an action, owner and deadline.

Common mistakes

  • Reporting hundreds of crawler warnings without prioritising.
  • Fixing only what tools flag, ignoring business-critical pages.
  • Not re-crawling after fixes to confirm.
  • Auditing desktop only.

Audit worksheet: how to record findings

An audit is only useful if someone can act on it. Record each issue in one row so developers, content writers and the business owner can read the same document.

Field Example
Issue Arabic blog posts canonicalised to English versions
Evidence URL Inspection shows Google-selected canonical differs; 3 example URLs
Impact Arabic pages unlikely to appear for Arabic queries
Fix Self-referencing canonicals plus correct hreflang pairs
Owner and effort Developer, about 2 hours
Verify by Re-inspect URLs after recrawl; check Pages report

The example row is illustrative, but this particular issue is common on bilingual sites in Egypt and the Gulf.

Issues that show up often on regional business sites

  • Staging sites left indexable: a staging. or dev. subdomain copied from production and visible in search.
  • Language switcher problems: Arabic pages missing hreflang, or the switcher linking to the Arabic homepage instead of the matching page.
  • Heavy page builders and sliders: large hero images and many scripts that hurt mobile performance on slower connections.
  • WhatsApp and chat widgets: third-party scripts loading on every page and delaying interaction.
  • Plugin overlap: two SEO or caching plugins producing duplicate meta tags or conflicting cache rules.
  • Thin location or service pages: dozens of near-identical pages for each city with only the name changed.

Core Web Vitals: what to check in 2026

Google’s Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP, which replaced First Input Delay in March 2024) and Cumulative Layout Shift (CLS). In an audit:

  • Use field data from Search Console’s Core Web Vitals report or PageSpeed Insights first; lab scores alone can mislead.
  • Group failing URLs by template. Fixing one template often fixes hundreds of pages.
  • For INP, look at long JavaScript tasks from chat widgets, analytics tags and sliders.
  • For CLS, check fonts, cookie banners and images without dimensions, including Arabic web fonts that load late.

How often to audit

  • Full audit: once or twice a year, and before and after any redesign, migration or domain change.
  • Monthly light check: Search Console Pages report, Core Web Vitals, manual actions and security issues.
  • After every major plugin or theme update: spot-check robots, canonicals, schema and page speed on key templates.

Agency and freelancer tip: scope the audit

If you audit sites for clients, agree on scope before starting: number of templates, languages, whether you include fixes or only recommendations, and what access you need (Search Console, hosting, analytics). A prioritised list of fifteen issues the client will actually fix is worth more than a two-hundred-row export from a crawler.

FAQ

How long does a technical SEO audit take?

For a small business site with a few templates, a careful audit usually takes one to three working days. Large e-commerce or multilingual sites take longer because each template and language needs checking.

Can I rely on an automated audit tool?

Tools find symptoms quickly, but they cannot judge business priority or confirm what Google actually indexes. Combine a crawler with Search Console data and manual checks.

What should I fix first?

Anything that blocks crawling or indexing of important pages, then canonical and hreflang errors, then performance on high-traffic templates.

Want an audit of your site with a clear action list? Contact me.

Frequently asked questions

What is a technical SEO audit?

It is a review of the technical factors that affect how search engines crawl, render, index and understand a website: server responses, robots rules, sitemaps, canonicals, redirects, internal linking, speed, mobile usability and structured data.

How often should I do a technical SEO audit?

A full audit once or twice a year and after major changes such as a redesign or migration, with monthly checks of Search Console for new issues.

Which tools do I need?

Google Search Console, a crawler such as Screaming Frog or Sitebulb, PageSpeed Insights, and the Rich Results Test cover most needs. Server logs add insight on larger sites.

Is a technical audit enough to rank?

No. It removes obstacles. Rankings also depend on relevance, content quality and links. Technical SEO makes sure good content can be found.

Muhamed Ahmed

Ecommerce & Web Solutions Developer

I'm Muhamed Ahmed, an ecommerce and web solutions developer with 15 years of experience building fast, secure online stores and websites on WooCommerce, WordPress and custom Laravel platforms. I write about website speed, SEO, automation and conversion.

All articles Hire me

Related articles