Technical SEO audit checklist: 27 checks, step by step

What a technical SEO audit is

A technical SEO audit is a systematic check of everything that determines whether search engines can reach, read, understand and trust your website. It does not judge whether your writing is persuasive or whether your offer is competitive. It asks a more basic set of questions. Can crawlers get to your pages? Are the right pages being indexed and the wrong ones left out? Is the site fast and stable for real visitors? Are there errors, duplicates or conflicting signals that confuse search engines? Is the structure clear?

These questions matter because technical problems are often invisible to the people who run a site. A page can look perfect in a browser and still carry an instruction that keeps it out of search results. A redesign can quietly break hundreds of links. A well-meaning plugin can create thousands of duplicate URLs. Content, links and reputation can only pay off if the technical foundation lets them, which is why a technical audit is usually the first step in a serious SEO program, as we explain in how long SEO takes.

This checklist walks through the audit in a logical order, from access to indexing to structure to performance, explaining what to check, why it matters, what the common failures are and how to fix them. You can use it to audit your own site, to brief a developer, or to judge the quality of an audit that someone else delivers. If you would rather have specialists do it, our technical SEO service and SEO audit cover the same ground.

Before you start: tools and access

You do not need expensive software to carry out a useful audit, but you do need the right access and a few reliable tools.

• Google Search Console. The single most important source of truth about how Google sees your site: indexing status, errors, performance, Core Web Vitals and security issues. Verify the site, ideally as a domain property so that all versions are included.
• Analytics. To understand which pages earn traffic and conversions, so that you can prioritize fixes by business value.
• A site crawler. Desktop crawlers such as Screaming Frog or Sitebulb, or cloud-based equivalents, crawl your site the way a search engine does and report status codes, titles, canonicals, links and more.
• PageSpeed Insights and Lighthouse. For performance, with both lab data and real-user field data where available.
• Bing Webmaster Tools. A second perspective, and useful for other search products that rely on Bing.
• Browser developer tools. For inspecting headers, rendering and network requests.
• Server access or logs. Where possible, since logs show what crawlers actually request.
• Structured data testing tools. Google's Rich Results Test and the Schema Markup Validator.

Before changing anything, record a baseline: organic traffic, indexed pages, the number of pages crawled, current Core Web Vitals and key rankings. You cannot show improvement without knowing where you started.

Step 1: can search engines access the site?

If crawlers cannot reach a page, nothing else about it matters. Start with the simplest barriers.

Robots.txt

Open yoursite.com/robots.txt and read it. This file tells crawlers which areas of the site they may not visit. Check that it does not block important sections, CSS or JavaScript files that pages need to render, or the whole site. A common and costly error is a leftover "Disallow: /" from a staging environment that was carried into the live site during a launch. Remember what the file does and does not do: it controls crawling, not indexing. A URL blocked in robots.txt can still appear in results if other pages link to it, and a crawler cannot read an instruction on a page that it is not allowed to fetch. Also confirm that the sitemap location is declared in the file.

Meta robots and X-Robots-Tag

Pages can carry a noindex instruction in the HTML or in the HTTP header. Crawl the site and list every URL that has noindex, nofollow or similar directives, then ask whether each is intentional. Accidentally noindexed pages are among the most common reasons good content fails to rank.

Status codes and server health

Each URL should return a sensible status code: 200 for live pages, 301 for permanent moves, 404 or 410 for pages that are gone. Look for server errors in the 500 range, timeouts and intermittent failures, which can cause search engines to reduce how often they crawl your site. Check the crawl stats in Search Console for patterns in errors and response times.

Other barriers

Some sites block crawlers unintentionally through security software, a content delivery network or a web application firewall that mistakes legitimate bots for attackers. Others sit behind logins, IP restrictions or cookie walls that prevent access. Use the URL Inspection tool in Search Console to fetch key pages as Google does and confirm that it can load them.

Step 2: indexation

Access is necessary but not sufficient. The next question is whether the pages you want are in the index and the pages you do not want are not.

Read the Pages report

The page indexing report in Search Console lists indexed pages and gives reasons for those that are not. Study the reasons. Some are healthy, such as pages deliberately excluded by noindex or duplicates whose canonical points elsewhere. Others signal problems: pages blocked by robots.txt that should be indexed, soft 404s, server errors, redirect issues, and pages that Google discovered or crawled but chose not to index.

Two statuses deserve special attention. "Discovered, currently not indexed" means Google knows the URL but has not crawled it yet, which can signal that the site is large relative to its perceived importance or that the page is poorly linked. "Crawled, currently not indexed" means Google fetched the page and decided not to include it, which often points to thin, duplicate or low-value content. Neither is fixed by resubmitting. They are fixed by improving the page and its internal links.

Compare three lists

Create three sets of URLs: those your crawler finds, those in your sitemap, and those that are indexed. Differences tell stories. Pages that are crawlable but not in the sitemap may be unimportant or forgotten. Pages in the sitemap but not indexed deserve investigation. Indexed pages that are in neither the crawl nor the sitemap may be orphaned or the result of parameter and duplicate problems.

Spot index bloat

Index bloat means having far more indexed pages than useful ones, typically because of faceted filters, internal search results, tag archives, session parameters or auto-generated pages. Bloat wastes crawling and dilutes the site. Identify the sources and decide whether to remove, consolidate, canonicalize or block them.

Step 3: XML sitemaps

A sitemap is a file that lists the URLs you want search engines to know about. It helps discovery, particularly on large or poorly linked sites, but it is a suggestion, not an instruction.

• Include only canonical, indexable URLs that return a 200 status. Redirected, noindexed, blocked and error URLs do not belong.
• Keep each file within the limits: 50,000 URLs or 50 MB uncompressed. Use a sitemap index for larger sites.
• Keep lastmod dates accurate. Dates that change on every build, with no real change in content, teach crawlers to ignore them.
• Submit the sitemap in Search Console and check for errors and the difference between submitted and indexed counts.
• Reference the sitemap in robots.txt.
• On large sites, split sitemaps by type, such as products, categories and articles, so that indexing by section can be monitored.

Step 4: site architecture and internal linking

How pages connect determines which ones are found and which are treated as important. A technical audit should map the structure and look for weaknesses.

• Click depth. Important pages should be reachable within a few clicks from the homepage. Pages buried many levels deep are crawled less often and tend to be treated as less important.
• Orphan pages. Pages that no other page links to may never be found and receive no internal strength. Compare crawl results with sitemaps and analytics to find them.
• Link equity distribution. The pages that earn revenue should receive the most internal links, with descriptive anchor text, from relevant pages.
• Navigation. Menus and footers should use real links that crawlers can follow, and should surface the pages that matter most, without being bloated with hundreds of links.
• Breadcrumbs. They clarify hierarchy for users and search engines and can be marked up with structured data.
• Pagination. Paginated series should be crawlable through normal links, and each page should be able to stand on its own.
• Broken links. Internal links pointing to 404s or through redirect chains waste crawl effort and frustrate users.

The structure should mirror how your business and your customers think, which is also the logic behind a topical map, as described in our content strategy work.

Step 5: URLs and canonical tags

The same content should be reachable at one preferred address. When it is reachable at several, search engines have to guess which to rank, and signals are split.

Check the URL versions

Test the four common variations of your homepage: http and https, with and without www. All but one should redirect permanently to the preferred version. Also check trailing slashes, uppercase and lowercase variants and index file names such as /index.html, and make sure they resolve consistently.

Keep URLs clean

URLs should be short, readable and stable, with words separated by hyphens. Avoid session identifiers and needless parameters. If parameters are required for filtering or tracking, decide how they should be handled.

Audit canonical tags

The canonical tag tells search engines which URL is the preferred version of a page. It is a hint, not a command, and search engines may choose differently if signals conflict. Check that key pages carry self-referencing canonicals, that canonicals point to indexable 200 pages, that they are not conflicting with redirects, noindex or sitemap entries, and that they appear once and in the head of the document. Compare the canonical you declare with the one Google selected, which is shown in the URL Inspection tool, and investigate pages where they differ.

Step 6: redirects and error pages

Redirects preserve ranking signals when URLs change. Done badly, they leak them.

• Use 301 for permanent moves. A 302 signals a temporary change, which is correct only for genuinely temporary situations.
• Remove chains and loops. A redirect that passes through several hops slows users and crawlers and may lose signals. Point old URLs directly to their final destination.
• Redirect to relevant pages. Sending every old URL to the homepage is treated as a soft 404 in many cases and gives users nothing useful.
• Handle deleted pages properly. A 404 or 410 is fine for pages that are truly gone, and redirects are better where a close replacement exists.
• Check for soft 404s. Pages that return a 200 status but display an error or empty message confuse search engines. Search Console reports many of them.
• Customize the 404 page. It should return a real 404 status and help the user find their way.

After any migration, redirects are the first thing to verify. We cover that process in our SEO migration service.

Step 7: on-page elements at scale

A crawler can check on-page elements across thousands of pages in minutes, which is something a human cannot do.

• Titles. Missing, duplicate, too long or too short titles. Each page should have a unique, descriptive title.
• Meta descriptions. Missing or duplicated ones. They do not directly affect ranking, but they affect clicks.
• Headings. Missing H1s, multiple H1s used carelessly, and headings that do not reflect the page's content.
• Images. Missing alt text, oversized files and broken image links.
• Thin pages. Pages with very little unique content, which may be candidates for expansion or consolidation.
• Word-for-word duplicates. Pages with identical titles or body copy, which often indicate template or parameter problems.

Treat the output as a starting point for judgment, not a to-do list to be cleared mechanically. A missing meta description on an unimportant page matters less than a duplicate title across fifty product pages.

Step 8: mobile and rendering

Google predominantly uses the mobile version of a page for indexing, so the mobile experience is the one that counts.

• Content parity. The mobile page should contain the same primary content, links and structured data as the desktop version. Content hidden or removed on mobile may be treated as absent.
• Viewport and layout. The page should declare a viewport and adapt without horizontal scrolling or tiny tap targets.
• Intrusive elements. Large pop-ups that cover content on mobile harm both users and performance.
• Blocked resources. Make sure CSS, JavaScript and images are not blocked, since search engines need them to render the page.
• Rendered content. Use the URL Inspection tool to view the rendered HTML and a screenshot, and confirm that important text, links and images appear.

Step 9: JavaScript and rendering

Search engines can process JavaScript, but it adds a step, and mistakes are common on sites that rely heavily on client-side rendering.

• Is the main content in the initial HTML or added later? Content that appears only after scripts run may be indexed more slowly or incompletely.
• Do links use real anchor tags with href attributes? Links built only with click handlers cannot be followed by crawlers.
• Do URLs change properly? Single-page applications should update the URL and use the history interface so that each view has its own address.
• Is metadata set correctly? Titles, descriptions and canonicals should be present in the rendered output, and ideally in the initial response.
• Is lazy loading safe? Content loaded on scroll should be reachable by crawlers, and the images that are most important to the page should not be hidden behind slow loading.

Server-side rendering or static generation is generally the most reliable approach for content that needs to rank. Dynamic rendering, serving a different version to bots, is now regarded as a workaround, not a recommended long-term solution.

Step 10: page experience and Core Web Vitals

Core Web Vitals measure real-user experience in three areas, with published thresholds for a good rating, assessed at the 75th percentile of visits.

Use field data from Search Console's Core Web Vitals report and PageSpeed Insights to see what real visitors experience, and lab tools such as Lighthouse to diagnose causes. The most common fixes are:

• For LCP: optimize and properly size the main image, serve modern formats, avoid lazy-loading the main above-the-fold image, reduce server response time, use caching and a content delivery network, and remove render-blocking resources.
• For INP: reduce and defer JavaScript, break up long tasks, minimize third-party scripts and avoid heavy work on interaction.
• For CLS: set dimensions on images, videos and embeds, reserve space for ads and dynamic content, and avoid inserting content above existing content.

Speed rarely overrides relevance in ranking, but poor experience loses visitors and conversions, and it can tip the balance between two equally relevant pages.

Step 11: security and HTTPS

• HTTPS everywhere. All pages should be served securely with a valid certificate that is not close to expiry.
• No mixed content. Secure pages should not load images, scripts or styles over insecure connections.
• Security headers. HSTS and other headers add protection and show care for users.
• Hacked content. Check Search Console's security issues report, and look for injected spam pages, hidden links or suspicious redirects, which are common on outdated content management systems.
• Software updates. Keep the platform, themes and plugins up to date. Neglected sites are a frequent source of compromise.

Step 12: structured data

Structured data labels what a page contains in a form machines can read. Google recommends JSON-LD in the schema.org vocabulary. It can make pages eligible for enhanced presentation in results, though it never guarantees it.

• Use the types that fit. Organization, LocalBusiness, Product, Article, FAQ, BreadcrumbList and others, according to the page.
• Match the visible content. Markup should describe what users can see, and not invent claims such as reviews that are not on the page.
• Validate. Run pages through the Rich Results Test and the Schema Markup Validator, and fix errors. Treat warnings with judgment.
• Avoid duplicates. Plugins and themes sometimes output conflicting or repeated markup, which should be consolidated.
• Monitor. Search Console's enhancement reports show markup errors found at scale.

Step 13: international and multilingual sites

If the site targets several languages or countries, check how versions are separated and connected.

• Each version should have its own URL, ideally in a consistent structure such as subfolders.
• Hreflang annotations should link each version to its alternatives, using correct language and region codes, and each page must link back to those that link to it. Missing return links invalidate the annotation.
• Include a self-referencing entry and, where appropriate, an x-default for unmatched users.
• Avoid automatic redirects based on a visitor's location that stop crawlers from seeing all versions.
• Make sure translations are genuine and localized, rather than a thin machine-translated copy.

Step 14: duplicate and thin content

Duplicate content is rarely a penalty, but it dilutes signals and wastes crawling, and it often reveals structural problems.

• Parameter duplicates. The same page reachable through tracking, sorting or session parameters.
• Printer, AMP-style or alternate versions. Make sure they canonicalize to the main version.
• Tag, category and archive pages. Auto-generated archives that mirror other content can often be noindexed or merged.
• Faceted navigation. Filter combinations that generate large numbers of near-identical pages, which need deliberate rules about which to index.
• Near-duplicate templates. Location or service pages that differ only by a place name, which should be enriched or consolidated.

The usual remedies are to consolidate pages and redirect, to canonicalize, to noindex low-value variants or to improve pages so that each earns its place. For online stores, filters deserve particular care, as we explain in our guide to faceted navigation SEO.

Step 15: crawl budget and log files

Crawl budget is the amount of attention a search engine gives your site. For most small sites it is not a concern, but for large sites with many thousands of URLs, wasted crawling can delay the discovery of important pages.

• Look for crawl traps. Infinite calendars, endless filter combinations, internal search result pages and session-based URLs can swallow crawling.
• Review the crawl stats report. Total requests, response times and the share of requests going to different file types show how crawlers spend time.
• Analyze server logs. Logs show which URLs crawlers actually request, how often, and with what status codes. Compare them with the pages that matter to find mismatches, such as heavy crawling of parameter URLs and little of the product pages.
• Improve efficiency. Fix errors and redirect chains, speed up the server, reduce duplicate URLs and strengthen internal links to priority pages.

Step 16: platform-specific checks

Every platform has its own habits. WordPress sites often suffer from plugin bloat, duplicate archives and heavy themes. Shopify has fixed URL structures, duplicate product paths and app-added scripts. WooCommerce combines WordPress issues with product attribute and tag archives. Headless and JavaScript-heavy builds raise rendering questions. Check the common problems for your platform specifically, because they are well known and often the quickest wins. For online stores, we examine one platform in depth in our guide to Shopify SEO problems and fixes.

Step 17: analytics and tracking sanity

An audit is only as useful as the data used to judge it, so confirm that measurement works.

• Analytics is installed once on every page, not twice, which would inflate sessions and distort bounce measures.
• Conversions, such as form submissions, calls and purchases, are tracked.
• Internal and developer traffic is excluded where possible.
• Search Console and analytics are properly linked.
• Tracking parameters do not create duplicate indexable URLs.

Prioritizing what you find

A large crawl can produce hundreds of findings. The skill in an audit lies in deciding which ones matter. Score each issue on two dimensions: how much it affects search visibility or revenue, and how much effort it takes to fix.

Within each level, favor fixes that affect the pages with the most revenue and the largest numbers of URLs. A single template fix that corrects ten thousand pages beats a hundred individual edits.

Writing tickets developers can act on

Findings only create value when they are implemented, so write them in a form that a developer can pick up without a meeting. A good ticket includes:

1. What is wrong. A plain statement of the problem and the number of affected URLs.
2. Why it matters. The effect on crawling, indexing or users, so that the priority is understood.
3. Evidence. Example URLs, screenshots or crawl exports.
4. The recommended change. Specific enough to implement, such as the exact redirect rule or tag.
5. How to test. What a developer or tester should see when it is fixed.
6. Priority and dependencies. What should be done first, and what else is affected.

After release, re-crawl and check that the fix worked and caused no new problems. Verification is a part of the audit, not a courtesy.

How often to audit

A full audit is typically worth doing when you start working on a site, before and after a migration or redesign, after a significant drop in traffic, and then once or twice a year. In between, light monitoring catches problems early. Set up alerts in Search Console, run a scheduled crawl monthly or quarterly, and check key templates and redirects after every major release. Many serious problems, such as an accidental noindex or a broken robots.txt, are introduced during routine updates, and the faster they are noticed, the cheaper they are to fix.

The checklist in one place

• Search Console, analytics and a crawler are set up, and a baseline is recorded.
• Robots.txt does not block important pages or resources, and declares the sitemap.
• No important page carries an accidental noindex or blocking header.
• Status codes are correct, with no widespread server errors or timeouts.
• Search engines can fetch and render key pages without being blocked.
• The page indexing report has been reviewed and every unwanted exclusion explained.
• Crawled, sitemap and indexed URL sets have been compared.
• Index bloat sources have been identified and handled.
• XML sitemaps contain only canonical, indexable, 200-status URLs and are submitted.
• Important pages are within a few clicks of the homepage, and orphan pages are found.
• Internal links use descriptive anchors and favor revenue pages.
• All URL versions redirect to one preferred version.
• Canonical tags are present, consistent and not in conflict with other signals.
• Redirects use 301 where permanent, with no chains or loops.
• 404 and soft 404 pages are handled properly.
• Titles, descriptions, headings and image alt text have been reviewed at scale.
• Mobile pages have content parity with desktop and render correctly.
• JavaScript-rendered content and links are crawlable.
• Core Web Vitals meet the good thresholds on key pages, or fixes are planned.
• The site uses HTTPS everywhere without mixed content, and no security issues are reported.
• Structured data is valid and matches visible content.
• Hreflang, where used, is reciprocal and correct.
• Duplicate and thin pages have been consolidated, canonicalized or improved.
• Crawl traps and wasteful URL patterns have been dealt with.
• Analytics fires once per page and conversions are tracked.
• Findings are prioritized by impact and effort and written as developer tickets.
• Fixes are re-crawled and verified after release.

Summary

• A technical audit checks whether search engines can access, index, understand and trust your site.
• Work in order: access, indexation, sitemaps, architecture, canonicals and redirects, on-page elements, mobile and rendering, speed, security, structured data and duplicates.
• Use Search Console as your main source of truth and a crawler to check at scale.
• Prioritize by impact and effort, and favor template-level fixes that correct many pages at once.
• Write findings as clear developer tickets, and verify fixes after release.
• Audit at the start, before and after major changes and at least annually, with light monitoring in between.

If you would like specialists to run the audit for you, request our free SEO audit for an initial view, or read about the technical SEO service for the full program. For context on cost and timing, see how much SEO services cost.