# Technical SEO Audit Checklist for Business Websites > A technical SEO audit checklist for business websites: crawlability, indexing, status codes, canonicals, speed, mobile, structured data and how to score fixes. URL: https://seoconsultantlondon.online/guides/technical-seo-audit-checklist/ Updated: 2026-10-26 ## Quick answer A technical SEO audit checks that Google can crawl, render and index your pages. Start with Google's three technical requirements: Googlebot isn't blocked, the page returns a 200 status and it has indexable content. Then review robots.txt, sitemaps, canonicals, redirects, internal links, speed, mobile usability and structured data, and score each fix. ## Key takeaways - Google lists three minimum technical requirements for indexing: Googlebot isn't blocked, the page returns an HTTP 200 status and the page has indexable content. - Meeting those requirements doesn't guarantee indexing, so a good audit also checks duplication, canonicals, quality signals and internal links. - Work in layers: access and crawling first, then indexing signals, then site structure, then speed and rendering, then enhancements such as structured data. - Score every finding for impact, effort and risk, so the list becomes a roadmap, not a pile of warnings. - Most small-business audits turn up a handful of serious issues and many trivial ones, and the skill lies in telling them apart. ## What does a technical SEO audit cover? Ask ten SEOs what goes into a technical audit and you'll get eleven answers, which is exactly why checklists are useful. A technical audit looks at whether search engines can reach your pages, understand them and store them, and whether the way the site is built helps or hinders that. It doesn't judge your copy or your backlinks, though what it finds often explains why those efforts aren't paying off. Think of it as an MOT for the site. You're not redesigning anything. You're lifting the bonnet, checking what's working, noting what's worn and deciding what to fix before it fails. > Why it matters: technical faults are the cheapest SEO problems to fix and the most expensive to ignore, because they can silently block every page you publish. ### What do Google's technical requirements say? Google's page on [Search technical requirements](https://developers.google.com/search/docs/essentials/technical), last updated on 18 December 2025, sets out three minimum requirements for a page to be eligible for indexing. First, Googlebot isn't blocked: the page must be publicly accessible, and pages behind a login or blocked by robots.txt are unlikely to appear in results. Second, the page works, meaning Google receives an HTTP 200 success status code. Third, the page has indexable content, in a file type Google supports and without violating its spam policies. The page adds an important caveat: meeting these requirements doesn't guarantee indexing. That's why a proper audit goes beyond them, but they're an excellent spine for the checklist. #### The audit in one sentence Check that Googlebot can reach it, that it returns 200, that the content can be indexed and that nothing contradicts those signals. ### How should you organise the work? In layers, from the bottom up. First, access and crawling: can Google get in at all? Second, indexing signals: are the right pages allowed and encouraged to be indexed? Third, structure: are pages linked sensibly, with clean URLs? Fourth, performance and rendering: do pages load fast and display properly on mobile? Fifth, enhancements: structured data, hreflang and other extras. Working in that order means you never polish the top floor of a building with no foundations. A fault in an early layer, such as a blocked directory, can make everything above it irrelevant. #### Keep a single findings sheet One row per finding, with columns for the check, the evidence, the impact, the effort, the risk, the owner and the status. It becomes your roadmap. ## Layer one: can Google access your site? Everything starts with access. If Googlebot can't reach the page, nothing else matters, and the checks here take minutes. Do them first, and do them carefully. ### Is robots.txt behaving? Open yourdomain.co.uk/robots.txt and read every line. Look for a stray "Disallow: /" that blocks the entire site, broad folder rules that catch real content and blocks on CSS or JavaScript that pages need to render. Confirm the file lives at the root, returns a 200 status, is plain UTF-8 text and references your sitemap. Check the robots.txt report in Search Console for fetch errors. The details of what the file can and can't do are in the guide to [pages blocked by robots.txt](/guides/blocked-by-robots-txt-search-console/). A single bad line here is one of the most damaging faults in SEO, and one of the quickest to fix. #### What to test Take five important URLs, one from each major section, and test them against the rules. Include a stylesheet and a script file. ### Are key pages publicly accessible? Pages behind logins, paywalls or IP restrictions can't be crawled. Check that staging sites are protected properly, and that production pages aren't accidentally gated. Test as a logged-out visitor in a private browser window. Use the URL Inspection tool's live test on key pages to confirm that Googlebot can fetch them. Also check for security tools, firewalls or bot protections that challenge or throttle Googlebot. A legitimate crawler blocked by a security rule is a surprisingly common cause of crawl problems. #### Don't forget HTTPS Confirm the site loads over HTTPS with a valid certificate, that HTTP redirects to HTTPS and that no mixed content warnings appear on key pages. ## Layer two: do pages return the right status codes? Google's second requirement is a 200 status. The audit needs to confirm that important pages return it, and that everything else returns the right alternative. Status codes are the site's way of telling Google what's going on. ### Do important pages return 200? Crawl the site and filter by status code. Your homepage, service pages, product and category pages, articles and contact page should all return 200 directly, without redirecting. Anything important returning a 3xx, 4xx or 5xx needs attention. A redirecting page isn't necessarily wrong, but a key page that only works after a redirect chain is a candidate for cleanup. Check the response for server errors under load. Search Console's crawl stats report shows patterns in server responses, as covered in the guide to the [Search Console Crawl Stats report](/guides/google-search-console-crawl-stats-report/). #### Check the homepage variants Test http and https, www and non-www, with and without a trailing slash. All should end at one preferred address. ### Are errors and redirects handled properly? Missing pages should return a true 404 or 410, not a 200 with an error message, which is a soft 404. The difference is explained in the guide to [soft 404 errors](/guides/soft-404-errors-seo/). Redirects should be permanent 301s where content has moved, pointing straight to the final destination without chains or loops. Google follows a limited number of hops, so long chains risk being abandoned. Look for broken internal links, redirected internal links and links to 404 pages. Each wastes crawl effort and frustrates visitors. The mechanics of clean redirect mapping are in the guide to [301 redirects and redirect mapping](/guides/301-redirects/). #### Test a nonsense URL Request a random address on your domain. It should return a 404 status. If it returns 200, your 404 handling is broken. ## Layer three: can the right pages be indexed? Access and status are necessary, but not sufficient. The third layer checks that your signals about indexing all agree. Contradictions are where most mysterious problems live. ### Are directives and canonicals consistent? Crawl for noindex directives in meta tags and X-Robots-Tag headers, and compare the list with your intentions. Service pages, products and key articles shouldn't carry noindex. Check that every indexable page has a self-referencing canonical, that canonicals point to live 200 pages and that no page canonicalises to a redirect, a 404 or a noindexed URL. The tag's role is covered in the guide to the [noindex tag](/guides/noindex-tag-when-to-use-it/). Look for pages that canonicalise to a different URL in error, a common template bug. The way Google resolves duplicates is explained in [duplicate pages without a user-selected canonical](/guides/duplicate-without-user-selected-canonical/). #### Make signals agree A page in the sitemap, linked internally, canonical to itself, returning 200 and allowed by robots.txt is a clear "index me" message. Any contradiction muddies it. ### Is the sitemap clean and submitted? Check that an XML sitemap exists, is referenced in robots.txt and submitted in Search Console, and that it lists only canonical, indexable, 200-status URLs. Look for redirected, noindexed, 404 and parameter URLs in the file. Compare submitted with indexed counts in the page indexing report. If the Sitemaps report shows errors, resolve them first. The causes and fixes are in the guide to [sitemap errors in Search Console](/guides/sitemap-errors-search-console/), and general principles are in [XML sitemap best practices](/guides/xml-sitemap-best-practices/). #### Check the lastmod values Dates should change only when content changes. A sitemap that claims everything updated today every day loses credibility. ### What does the page indexing report say? Open Indexing, then Pages. Review the reasons pages aren't indexed and look for surprises: noindex exclusions on important pages, soft 404s, duplicates, crawled or discovered but not indexed. Group the URLs by pattern and decide which matter. Patterns tell you more than counts. A thousand excluded parameter URLs are a tidy-up. Ten excluded service pages are a priority. The statuses are explained in the guides to [crawled, currently not indexed](/guides/crawled-currently-not-indexed/) and [discovered, currently not indexed](/guides/discovered-currently-not-indexed/). ## Layer four: is the site structure sound? Once pages can be indexed, the next question is whether the site helps Google and visitors find and understand them. Structure is the quiet multiplier of everything else. It's also where small sites often have easy wins. ### Are internal links working? Every page you care about should be linked from at least one other relevant page, in context. Look for orphan pages with no internal links, important pages buried many clicks from the homepage and navigation labels that don't describe their destinations. Check that links use real anchor elements with descriptive text. A full review has its own method, described in the guide to the [internal link audit](/guides/internal-link-audit/). For the audit checklist, flag the pages that need attention and the patterns behind them. #### Check click depth Key pages should usually be reachable in three clicks or fewer from the homepage. Deeper isn't automatically bad, but it's worth a second look. ### Are URLs and architecture sensible? URLs should be readable, lowercase, consistent in format and free of unnecessary parameters. Folder structures should reflect the hierarchy of the site. Breadcrumbs should help users and, where marked up, search engines. Watch for duplicate paths to the same content, session identifiers and endlessly combining filters. The principles for grouping pages into clear hubs are in the guide to [website architecture and internal links](/guides/website-architecture-internal-links/). On a small site, a tidy hierarchy and clear navigation do most of the work. #### Spot duplicate patterns early Crawl for repeating title tags and near-identical content. Duplicate patterns are rarely accidental. They point to a template or setting. ## Layer five: speed, rendering and mobile Pages can be crawlable and indexable and still frustrate users and crawlers. This layer checks how the site performs and how it renders. Treat it as a quality check, not a perfection contest. ### How do you check speed and Core Web Vitals? Use the Core Web Vitals report in Search Console for field data on your real visitors, and PageSpeed Insights or Lighthouse for lab diagnostics on specific pages. Look at loading, interactivity and visual stability. Focus on the templates that matter: homepage, key service pages, product pages. Identify the biggest causes, such as oversized images, render-blocking scripts, slow server response and third-party scripts. You don't need a perfect score. You need pages that load promptly and behave predictably. The thresholds and priorities are in the guide to [Core Web Vitals for business websites](/guides/core-web-vitals/). #### Prioritise by template Fixing one template that powers a hundred pages beats tweaking a hundred pages individually. ### Does Google see the page the way users do? For sites that use JavaScript to build content, check the rendered HTML in the URL Inspection tool and confirm that headings, body text, links and structured data appear. Make sure important content isn't hidden behind interactions that Googlebot doesn't perform. Check that CSS and JavaScript files aren't blocked. The guide to [JavaScript SEO and rendering checks](/guides/javascript-seo/) explains how to test and what to do if content goes missing. #### Mobile matters Google uses the mobile version of a page for indexing, so check that content, links and structured data match between mobile and desktop, and that tap targets and fonts are usable. ## Layer six: enhancements and extras With the foundations solid, the final layer covers extras that help pages appear well in results and connect to the right audiences. These rarely fix a broken site, but they polish a healthy one. ### Is structured data valid and honest? Check that structured data, such as organisation, local business, article, product and FAQ markup where appropriate, is present on the right templates, validates without errors and matches visible content. Don't mark up content that users can't see. Make sure business details match your profile and website. The right types and common pitfalls are in the guide to [structured data for service business websites](/guides/structured-data-service-businesses/). Remember that markup helps search engines understand a page. It doesn't force a rich result. #### Test on templates, not pages Validate one example per template, then spot-check the rest. Template-level fixes spread across the site. ### Are international and local signals correct? If you serve several languages or countries, check hreflang annotations for return links, correct codes and consistency with canonicals. If you serve a local market, check that the business name, address and phone number are consistent on the site and with your profile, as in the guide to a [NAP consistency audit](/guides/nap-consistency-audit/), and that location pages offer real content. For multi-country sites, the details are in the guide to [hreflang and international URL structure](/guides/hreflang-international-url-structure/). #### Keep it relevant Skip checks that don't apply. A single-country brochure site doesn't need an hreflang audit. ## How do you record and score findings? An audit is only useful if it leads to action. Recording and scoring turn a long list into a plan people can follow. The method is simple and it works. ### What does the findings sheet look like? One row per issue. Columns: the check, the URLs or pattern affected, the evidence (a screenshot or crawl export), the likely impact, the effort to fix, the risk of the change, a priority score, the owner, the target date and the status. Group findings by layer so the logic is clear. | Finding | Layer | Impact | Effort | Risk | Priority | |---|---|---|---|---|---| | Service pages canonical to wrong URL | Indexing | High | Low | Low | 1 | | Redirect chains on top 20 URLs | Status codes | Medium | Low | Low | 2 | | Orphan blog posts | Structure | Medium | Medium | Low | 3 | | Oversized hero images | Speed | Medium | Low | Low | 2 | | Missing alt text on decorative images | Enhancements | Low | Medium | Low | 5 | #### Keep evidence attached A screenshot or export next to each finding saves arguments and speeds up developer work. ### How do you set priorities? Score impact, effort and risk on a simple scale, such as high, medium and low. Do high-impact, low-effort, low-risk fixes first. Schedule high-impact, high-effort items as projects. Park low-impact, high-effort items. Never ignore high-risk changes: plan them with testing and rollback. Then turn the top items into tickets with clear descriptions, acceptance criteria and owners. A ranked list of ten well-written tickets does more good than a hundred-line report nobody reads. #### Share the top five first Start with a short summary of the five most important findings. People engage with a clear message much more than with a spreadsheet. ## How do you brief developers on the fixes? Technical SEO lives or dies on the handoff. A well-written ticket gets fixed. A vague one stalls. Write briefs that make the right action obvious. ### What does a good ticket include? The problem in one sentence. The affected URLs or patterns, with examples. The current behaviour and the desired behaviour. Why it matters, briefly. Steps to reproduce or check. Acceptance criteria, such as "service pages return a self-referencing canonical." And any dependencies or risks, including a rollback plan. Attach screenshots or crawl exports. Be specific about the template or component, not just the URL. Developers appreciate clarity and respond poorly to alarm. #### A sample ticket in plain English "Service pages currently output a canonical tag pointing to the category page. Change the template so each service page's canonical points to its own URL. Test with /services/example/. Acceptance: view source shows a self-referencing canonical on all 14 service pages." ### How do you check the fix? Test on staging first where possible, then on production after release. Re-crawl the affected area, inspect a sample with the URL Inspection tool and compare the evidence with the original finding. Update the findings sheet with the date and result. Monitor Search Console over the following weeks for changes in indexing and performance. If a fix doesn't hold, record it and investigate. Plugins, caching and deployment processes can undo changes, and noticing early saves weeks. ## What mistakes spoil technical audits? Technical audits fail in predictable ways. Most come from trusting tools too much or looking at too little. Avoid these. ### Which mistakes cause the most harm? Treating tool scores as verdicts. Reporting hundreds of low-value warnings without ranking them. Ignoring Search Console's own data in favour of a crawler's guess. Changing many things at once, so nothing can be attributed. Fixing symptoms, such as individual URLs, instead of the template that creates them. And auditing a staging site without checking production. Another is auditing in isolation. A technical fix that conflicts with the content plan or the business goal can create new problems. Keep the audit connected to what the business wants from search. #### A healthy habit For every finding, ask: would fixing this change what Google can crawl, index or understand, or what a visitor experiences? If not, it can wait. ### What about false positives? Crawlers flag things that aren't problems: missing meta keywords, slightly long descriptions, harmless duplicate titles on utility pages. Learn which warnings your tools over-report on your platform, and skip them. Document the decision so the next person doesn't redo the analysis. Equally, tools miss things. They can't judge intent, can't see Google's decisions and may not render your JavaScript the way Google does. Always cross-check important findings in Search Console and with URL Inspection. ## When should you bring in a specialist? Plenty of small business sites can be audited in-house with patience and the free tools. Some situations call for expertise. Knowing which saves time and money. ### Which situations justify help? A migration or redesign. A large site with thousands of URLs and complex filters. A JavaScript-heavy build. A sudden traffic drop with no obvious cause. Persistent indexing problems that survive basic fixes. Several languages or countries. Or a platform that limits what you can change and needs creative solutions. A specialist brings pattern recognition, tooling and the ability to write precise briefs. An independent [SEO audit](/seo-audit/) is a sensible first step, and ongoing work with a [technical SEO consultant](/technical-seo-consultant/) can handle implementation support, monitoring and releases. #### What to expect from the work A prioritised findings list with evidence, clear developer-ready tickets, a verification plan and a short summary a non-technical colleague can follow. ### How do you keep the site healthy afterwards? Build checks into routine work. A monthly review of Search Console reports. A pre-launch and post-launch checklist for releases. Alerts for sudden changes in indexing, errors or crawl stats. A written policy for page types, redirects and canonicals. A quarterly crawl compared against the last one. Technical health isn't a project with an end date. It's maintenance, and the cheapest maintenance is the kind that catches problems in days instead of months. ## What does a worked example look like? A story helps the checklist stick. This one is hypothetical, built from typical patterns, with illustrative details. It shows how a layered audit finds a cluster of related problems. ### What did the audit find? A small professional services firm saw enquiries from search flatten after a redesign. The audit started at the bottom. Layer one found nothing: robots.txt was clean and pages were accessible. Layer two found that old URLs from the previous site returned 404 and a handful of internal links pointed to redirecting URLs. Layer three found the real problem: the new template output a canonical tag on every service page pointing to the services overview page, so Google treated all service pages as duplicates of one. Layer four found that the sitemap listed the old URL structure, and layer five found oversized images on the homepage and service templates. #### The key discovery One template line, a wrong canonical, explained most of the lost visibility. Without the layered approach, it could have taken weeks to find. ### What was the fix and result? The developer corrected the canonical template, the team regenerated the sitemap with the new URLs, redirects were added for the old addresses and images were compressed. They verified with URL Inspection, requested indexing for the main service pages and monitored the page indexing report. Over several weeks, the service pages returned to the index and impressions recovered. The checklist didn't do anything clever. It forced a methodical look at each layer, in order, and recorded the evidence. That's all a technical audit is, and it's a habit any business can adopt. Keep the findings sheet, rerun the checks after every major change and the site will stay in good order. #### The summary Check access, check status codes, check indexing signals, check structure, check speed and rendering, then add the extras. Score everything and fix the high-impact items first. ## How do you run a quick audit with free tools in an afternoon? You don't need a budget to find the big problems. A focused afternoon with Search Console, a free crawler and your browser will surface most of what matters on a small site. The sequence below is deliberately short. ### What's the two-hour version? Spend twenty minutes in Search Console: the page indexing report, the Sitemaps report, the robots.txt report and the Core Web Vitals report. Spend thirty minutes crawling the site with a free-tier crawler, exporting status codes, canonicals, titles and directives. Spend twenty minutes testing five key URLs in the URL Inspection tool, comparing the indexed and live views. Spend twenty minutes on speed with PageSpeed Insights for the homepage and one service page. Spend the final half hour writing the findings sheet and ranking the top five. You won't catch everything, but you'll catch the faults that cost the most. For small sites with few templates, that's usually enough to make a meaningful difference. #### Skip what doesn't matter yet Ignore minor warnings until the serious ones are fixed. A short, honest list beats a long, ignored one. ### What should the quick audit always include? A check that the site loads over HTTPS and that variants redirect to one address. A read of robots.txt. A look at the sitemap. A scan for noindex on key pages. A test of a nonsense URL for correct 404 handling. A check of the homepage and a service page in the live test. And a look at whether the Business Profile, website and directories agree on name, address and phone number. Those seven checks take an hour and catch the most damaging accidents. Add the rest of the checklist as time allows. ## What does a monthly technical health routine look like? An annual audit finds what's already wrong. A monthly routine catches what's going wrong. The second saves far more trouble. It takes about thirty minutes once it's habitual. ### What goes into the monthly check? Open Search Console and compare the indexed and not-indexed counts with last month. Scan for new reasons in the page indexing report. Check the Sitemaps report for errors. Review the Core Web Vitals report for newly failing groups. Look at the crawl stats if you have access, for spikes in errors or response times. Click through your top ten pages to confirm they load and render correctly. Check for any messages from Google. Record the numbers in a simple log, with notes on releases, plugin updates and content changes. Patterns become obvious after a few months. | Check | Where | Looking for | |---|---|---| | Indexed vs not indexed | Page indexing report | Sudden changes, new reasons | | Sitemap health | Sitemaps report | Errors, count mismatches | | Core Web Vitals | Core Web Vitals report | New failing URL groups | | Crawl health | Crawl Stats report | Error spikes, slow responses | | Key pages | Manual visit | Broken layout, missing content | | Messages | Search Console | Manual actions, security issues | #### Pair it with a release checklist Before and after every deployment, check robots.txt, a few templates for canonicals and directives and a nonsense URL for status. A small habit prevents a large mistake. ### Who should own it? One named person, with a backup. They don't need to be technical, but they do need to know what normal looks like and who to call when something isn't. Give them a one-page runbook with the checks, the thresholds that trigger an escalation and the contacts for developers and hosting. If there's no one in-house, an ongoing arrangement with a specialist can cover the routine and flag problems early. Either way, someone must own it, because unowned checks are the ones that don't happen. ## Frequently asked questions ### What is a technical SEO audit? It's a structured review of whether search engines can crawl, render and index your site, and whether the technical set-up supports good performance. It covers robots.txt, sitemaps, status codes, canonicals, redirects, internal links, speed, mobile usability and structured data, and ends with a prioritised list of fixes. ### How long does a technical SEO audit take? For a small business site of a few dozen to a few hundred pages, expect a few hours to a couple of days, including analysis and writing up. Larger sites with thousands of URLs, complex platforms or JavaScript rendering take longer. Time depends more on complexity and reporting detail than on page count. ### Which tools do I need for a technical SEO audit? Google Search Console is essential, along with a site crawler such as Screaming Frog or Sitebulb, PageSpeed Insights or Lighthouse and your browser's developer tools. A spreadsheet to record and score findings is just as important. Tools find candidates, and judgement decides which findings matter. ### How often should I run a technical audit? A full audit once a year suits most business sites, with lighter checks after releases, redesigns, migrations or traffic changes. Review Search Console monthly for new errors. Large or fast-changing sites may need quarterly reviews, and any major site change deserves a focused pre-launch and post-launch check. ### Should I fix everything an audit tool reports? No. Many warnings are minor or irrelevant. Prioritise issues that stop pages being crawled or indexed, create duplicates, break user journeys or slow important pages. Fix those first, and treat cosmetic findings as backlog items. A scored, ranked list prevents wasted effort and developer frustration.