
Technical SEO Audit: Process, Checklist, and Costs 2026
A technical SEO audit clarifies whether Google can reliably crawl, correctly render, and fully index your website. It also shows where server configuration, redirects, canonicals, internal linking, or load times cost visibility. Below you will learn which areas a reliable technical SEO audit has to cover, in which order we proceed, which findings typically appear after ranking losses, penalties, or a relaunch, and when an external analysis is worthwhile compared with checking it yourself.
Identifying technical SEO problems with purpose
SEYBOLD ONE analyzes technical causes of visibility losses and develops data-driven strategies to improve your search engine and AI visibility.
Get a free consultationWhat a technical SEO audit does and does not do
Technical SEO forms the foundation on which content and brand signals can work at all. A technical analysis therefore does not answer questions about keyword strategy or text quality but checks the prerequisites: does Googlebot reach the relevant URLs, does the server deliver stable status codes, does the search engine understand which version of a page is authoritative, and do real users experience the page as fast and stable? You will find a detailed explanation of the terms in our article Technical SEO explained simply.
What matters for expectations is what such an audit is not. Google points out that search finds the vast majority of pages automatically without pages having to be submitted manually. A good audit therefore doesn't focus on submitting URLs but on the obstacles that slow down the automated process or direct crawling resources to worthless pages. The same applies: perfect measurements alone guarantee no top rankings. Google makes clear that there is no single page experience signal; the core ranking systems reward a good user experience but presuppose relevant content. Technical optimization is thus a necessary but not a sufficient condition for visibility.
The audit areas at a glance
A complete technical SEO audit covers eight areas. The following overview doubles as a compact checklist that you can use for a first self-assessment.
| Audit area | Key questions | Typical data sources |
|---|---|---|
| Crawling | Does robots.txt block important resources? Do filter and parameter URLs waste crawl capacity? | robots.txt, crawler, “Crawl stats” report, log files |
| Indexing | Which URLs are indexed, which are excluded, and why? Do noindex instructions match the intention? | Page indexing report, URL Inspection |
| Status codes and redirects | Are there 404 errors on linked pages, redirect chains, soft 404s, or 5xx errors? | Crawler, server logs |
| Canonicalization and duplicates | Do canonicals point to indexable target pages? Do HTTP/HTTPS, www, or parameter variants compete? | Crawler, URL Inspection (Google-selected canonical URL) |
| Information architecture | Can important pages be reached in a few clicks? Are there orphaned pages without internal links? | Crawler, XML sitemap comparison |
| Performance | Do real users meet the thresholds for LCP, INP, and CLS, separately for mobile and desktop? | Core Web Vitals report, CrUX, PageSpeed Insights |
| Rendering and mobile | Does Googlebot see the same content as users after JavaScript rendering? Is the mobile version complete? | URL Inspection (rendered HTML), crawler with rendering |
| Security and special reports | Are there security issues or manual actions? Is HTTPS implemented consistently? | Search Console: “Security issues”, “Manual actions” |
Depending on the website, structured data, hreflang markup for international sites, and the question of how AI crawlers and answer systems handle the content are added. For the core of the audit, however, the eight areas remain the reliable framework.
The process of a technical SEO analysis in seven steps
The order is not an end in itself: anyone who starts with load times although half of the product pages aren't indexed optimizes past the actual problem. We therefore go from the fundamental to the detail.
- Clarify starting point and goals. Before the first crawl comes the question of which page types are business-critical, such as category and product pages in a shop or service pages for service providers, and whether there is a specific occasion, such as a ranking drop or a planned relaunch.
- Evaluate Search Console. The Page indexing report shows which URLs Google has indexed and for which reasons others remain excluded. The status “Crawled – currently not indexed” is particularly revealing: Google fetched the page but did not include it, which often points to thin, duplicate, or weakly linked content.
- Run a full crawl. A desktop crawler maps the website the way a search engine bot reaches it via internal links. This yields status codes, click depth, canonical conflicts, missing or duplicate titles, and orphaned pages.
- Compare crawl, sitemap, and index. The real insights arise in the difference: URLs in the sitemap that are not linked internally; internally linked URLs that are not indexed; indexed URLs that shouldn't exist anymore.
- Evaluate log files. For larger websites, server logs show where Googlebot actually directs its requests. That makes visible whether crawl capacity trickles away into filter combinations, session parameters, or redirect chains.
- Assess performance with field data. Lab values from a single test run are a hint, not a diagnosis. What counts is the data of real users that Google summarizes in the Core Web Vitals report of Search Console.
- Prioritize measures. At the end there is no error catalog with 400 entries but a list weighted by impact and effort that development, editorial, and marketing can implement concretely.
Crawling and indexing: where most losses arise
In practice, the biggest lever almost always lies in crawling and indexing, because errors here affect entire page types and not just individual URLs. An accidental noindex in the template of a category level, a canonical that points to the homepage after an update, or a robots.txt that still contains the state of the staging environment after go-live can push hundreds of pages out of the index at the same time.
For shops and large portals, control of crawling capacity is added. In its documentation on crawl budget, Google describes that this topic is relevant above all for very large or fast-changing websites; for most smaller sites, a clean basic structure is enough. In the overview of crawling and indexing, Google shows how website owners control which content gets crawled: important pages belong in the XML sitemap, while shopping cart, filter, and other dynamic URLs without search value can be excluded from crawling via robots.txt. A frequently overlooked distinction applies here: robots.txt prevents crawling, not necessarily indexing. Anyone who wants to remove a page from the index reliably uses noindex and keeps the page crawlable for that.
A second classic is redirect chains. Every additional stop lengthens the path for bot and user, and chains with three or four hops grown over several relaunches are not rare. The audit should therefore not only capture individual 301 redirects but the complete chain up to the final target and its status code.

Reading Core Web Vitals correctly
The Core Web Vitals measure loading behavior, responsiveness, and visual stability. According to web.dev, the following thresholds apply for a good user experience, each measured at the 75th percentile of page views:
- Largest Contentful Paint (LCP): at most 2.5 seconds until the largest visible element is displayed
- Interaction to Next Paint (INP): at most 200 milliseconds response time to interactions
- Cumulative Layout Shift (CLS): a value of at most 0.1 for unexpected layout shifts
INP has replaced the earlier First Input Delay; Google had announced the switch for March 2024. Older checklists that still list FID as a metric are accordingly outdated.
The 75th percentile is decisive: not the average is assessed but whether three quarters of all page views meet the limit, separately for mobile and desktop. A lab test on a fast office computer can therefore show green values while users with mid-range smartphones on mobile networks experience an entirely different reality. In the audit, we therefore always compare lab data with field data from the Chrome User Experience Report. How LCP, INP, and CLS can be improved in a targeted way is described on our page on optimizing the Core Web Vitals.
Special cases: ranking drop, penalty, and relaunch
Not every audit begins in normal operation. Three occasions call for a different, more forensic approach.
Sudden ranking loss
If visibility collapses within a few days, the first thing to clarify is whether the cause is algorithmic, technical, or manual. The first port of call is the “Manual actions” report in Search Console. Google explains that most of the problems listed there lead to pages ranking lower or disappearing from search results entirely, without a visible notice for users. It is different with security issues such as malware or phishing: here browsers can display warning pages before visitors reach the website. A reliable diagnosis checks both reports and then compares the time of the drop with deployments, server changes, and known Google updates.
Google penalty
If a manual action is present, a technical audit alone is not enough. Unnatural links, spam content, or hacked areas often play a role, which call for link forensics and clean documentation for the reconsideration request. The technical analysis provides proof here that the affected areas have been cleaned up and that no further compromised URLs are reachable.
Website relaunch
In a relaunch, the technical audit is split in two: before go-live as acceptance of the staging environment and immediately afterwards as monitoring. The center is the complete redirect matrix from old to new URLs so that link signals are preserved and Google captures the new content efficiently. In addition comes the check of robots.txt, noindex instructions, canonicals, and sitemaps in the live system. Background is covered in the article Website relaunch without ranking loss.
Check it yourself or have it checked?
You can do a first technical inventory yourself with freely available tools. Three tool types cover the basics:
- Google Search Console: free and indispensable for indexing status, crawl stats, Core Web Vitals from field data, and security and spam notices.
- PageSpeed Insights: free, combines lab measurements with field data from the Chrome User Experience Report, provided enough data is available for the URL.
- Desktop crawlers and SEO suites: map structure, status codes, and metadata; many are free to use for small websites, while paid licenses are common for large shops.
The limit of self-checking rarely lies with the tools but with the interpretation. A crawler quickly reports thousands of hints for a mid-sized shop; what matters is which of them actually cost visibility and which remain without consequence. External support is worthwhile above all when a ranking loss cannot be clearly explained, when a penalty is present, when a relaunch is coming up, or when the website is so large that log file analyses and crawl control become necessary. What a comprehensive SEO audit includes beyond the technology is explained in our glossary article on the SEO audit.
Technical audit at SEYBOLD
We offer the technical SEO audit at several depths, matched to the respective occasion. The technical audit costs €1,500 to €3,500 one-time, depending on the size of the website. For ranking drops and penalties there is the forensic audit for €1,500 to €5,500 one-time, and for relaunch projects the relaunch safeguarding from €1,500. Anyone who wants to combine the technical analysis with content, brand, and AI visibility chooses the complete visibility audit from €3,000. You will find all services and terms on our page How much does SEO cost? For teams that want to carry out audits themselves in the future, we also offer a Technical SEO workshop from €500.
Our perspective: auditing is risk management, not a mandatory appointment
For over 25 years we have been dealing with the question of why websites lose visibility. In many of the cases that come to us, the cause does not lie in a single Google update but in technical decisions that nobody checked with search engines in mind: a template update, a new filter system in the shop, a hosting change, or a redirect logic that nobody controlled anymore after the relaunch.

That is why we don't understand the technical SEO audit as an annual mandatory appointment with a lengthy PDF as the result but as part of ongoing visibility risk management. A one-time audit describes a state; visibility is only protected by a process that evaluates changes to the website before and after go-live by the same criteria. Our approach is forensic and data-driven: we link crawl data, Search Console exports, and log files to separate causes from symptoms, and we prioritize consistently by business impact. The experience from co-developing standards such as DIN SPEC 33461 flows into traceable audit criteria that development teams without an SEO background can also implement.
In addition comes a shift that many checklists still ignore: visibility today no longer arises only in classic search but also in AI-powered answer systems. A website that is cleanly reachable for Googlebot but unintentionally locks out AI crawlers or loads content only via JavaScript gives away reach. A contemporary technical audit therefore includes this bot strategy from the start.
Frequently asked questions about the technical SEO audit
How long does a technical SEO audit take?
For smaller company websites, the result is usually available after a few working days; for large shops with log file analysis, the audit can take several weeks. What matters for the duration are the number of pages, access to Search Console and server logs, and whether an acute ranking loss has to be worked up forensically.
Is there a free tool for technical SEO analysis?
Google Search Console and PageSpeed Insights are free and deliver the most important data directly from Google. For a structural analysis you additionally need a crawler; many of them are available in a limited free version. No tool, however, replaces the assessment of which findings actually cost visibility.
How often should a website be checked technically?
As a guideline, a comprehensive audit once a year is recommended, plus before and after every relaunch, system change, or larger template update. Shops and portals with frequent changes benefit from ongoing monitoring that reports indexing and status code problems before they show up in the rankings.
Do good Core Web Vitals automatically improve rankings?
No. Google rewards a good user experience but names no single page experience signal and puts the relevance of content first. Poor values can cost users and be a disadvantage against equivalent content, but perfect values do not compensate for weak content.
Sources
- Google Search Central: SEO Starter Guide
- Google Search Central: Understanding page experience in Google Search results
- Search Console Help: Page indexing report
- Google Search Central: Understanding Core Web Vitals and Google search results
- Google Search Central: Crawl budget management for large sites
- Google Search Central: Crawling and indexing overview
- web.dev: Web Vitals
- Google Search Central Blog: Introducing INP to Core Web Vitals
- Search Console Help: Manual actions report
- Search Console Help: Security issues report
