How to Run a Technical SEO Audit That Produces Fixable Priorities

Before crawling, establish exactly which production site, hostnames, protocols, subdomains, and rendering conditions belong in scope. A technical audit can be invalidated by something as simple as crawling a staging host, bypassing a CDN, using the wrong canonical hostname, or comparing data from properties that do not represent the same site.

Begin in Google Search Console. Confirm the property or properties that cover the live URLs you intend to audit. Review the submitted sitemaps and note whether the site uses a sitemap index, separate content-type sitemaps, or multiple hostnames. Record any obvious differences between the URLs the site submits and the URLs you expect to be canonical.

Next, document crawl settings. State the starting URL, user agent, JavaScript rendering mode, robots handling, canonical handling, crawl limits, include and exclude rules, and authentication or cookie requirements.

Do not assume that imitating a search crawler automatically reproduces Google behavior; use the setting to test how the site responds under a known condition, then verify important differences through Search Console, rendering tests, or server evidence.

Request server or CDN logs early if they are available and relevant. Access can require coordination with hosting, security, infrastructure, or development teams, so waiting until the end of the audit can stall the diagnostic work. When logs are used, plan to verify crawler identities rather than trusting a user-agent string alone.

Capture a baseline before changes begin. Export crawl data, Search Console indexation information, relevant performance reports, sitemap inventories, and any release notes that explain recent platform changes. Keep the raw data separate from your working notes so another analyst can reproduce the audit later.

Finally, define what the audit is not covering. If content quality, backlinks, international strategy, analytics implementation, or conversion issues are out of scope, say so. Clear boundaries prevent technical findings from being used to explain problems the audit was never designed to diagnose.

A useful audit separates failure modes before it assigns urgency. Start with access and rendering: can search crawlers request the important URLs and receive the content needed to understand them? Then check indexation intent: are canonical, robots, noindex, redirects, and sitemap signals consistent with what the site wants indexed? After that, review architecture and internal linking, structured data, and performance.

Keep the categories plain and diagnostic. Access failures include blocking rules, widespread server errors, redirect loops, or rendering conditions that prevent important content from being available.

Indexation conflicts include unintended noindex directives, canonical inconsistencies, duplicate URL sets, or sitemap submissions that contradict page-level directives. Architecture findings include excessive depth, orphaned URLs, weak internal paths, and navigation patterns that create unnecessary URL variants.

Performance should be evaluated after you know which templates and pages matter. A slow template can deserve urgent attention, but it should not displace a blocking issue simply because its metric is easier to display.

Structured data also belongs after basic eligibility and page truth are understood; markup should describe visible content rather than be used to compensate for missing or inaccessible content.

Use a consistent finding record for every issue: evidence, affected URLs or templates, expected behavior, observed behavior, business relevance, dependency, proposed action, owner, validation method, and confidence.

A simple confidence scale can use 5 as the highest internal rating, provided the team understands that it is a workflow aid rather than a search engine score.

This classification step makes the rest of the audit faster because each later section feeds a known decision bucket. It also prevents the common mistake of allowing a crawler's built-in severity label to become the implementation priority without human review.

Crawlability and indexation should be audited as separate questions. A URL can be crawlable but intentionally excluded from indexing, indexable but poorly discovered, or discoverable through sources that your site crawler never reaches. The audit should identify which condition applies instead of treating every non-indexed URL as the same problem.

Start with robots.txt and page-level directives. Review blocking rules for patterns that affect important sections, then inspect representative pages to confirm robots meta tags and relevant response headers.

Review canonical declarations and redirects for consistency. A sitemap URL that returns a non-200 response deserves review because submitted inventories are most useful when they represent current canonical destinations.

Next, reconcile URL inventories. Use a repeatable sequence: 1) export URLs discovered by the internal crawl, 2) export submitted sitemap URLs, 3) export relevant Search Console URL evidence, and 4) add any trusted inventory from the CMS, analytics, feeds, or migration files when it helps explain discrepancies. Compare the sets instead of assuming one is authoritative for every question.

For orphan analysis, focus on URLs that appear in an authoritative inventory or receive search evidence but have no discoverable internal path in the current crawl. When a URL appears in source 2 or source 3 but not source 1, investigate why.

The right action depends on intent: an important canonical page may need relevant internal links; an obsolete page may need consolidation or a redirect; a duplicate may need canonical cleanup; a page that should remain excluded may need to be removed from submitted inventories.

Do not assume that every URL absent from a crawl is an orphan. JavaScript navigation, crawl rules, pagination, forms, faceted navigation, authentication, and alternate discovery paths can all create differences. Reproduce the route and determine whether a user and a search crawler can reasonably reach the page.

Finish by checking intent conflicts: submitted but noindexed URLs, redirected sitemap entries, canonicals that point away unexpectedly, blocked resources needed for rendering, and important pages with no stable internal path. These conflicts are more decision-useful than a raw count of excluded URLs.

Site architecture determines how users and crawlers move through the site and how clearly the site communicates page relationships. The audit should map important page types, identify weak paths, and distinguish structural problems from isolated linking gaps.

Review crawl depth as a diagnostic, not a universal threshold. If an important commercial or informational page sits at depth 4 while equivalent pages are much easier to reach, investigate whether navigation, category structure, pagination, or internal links create the difference.

A page at depth 3 is not automatically healthy, and a deeper page is not automatically broken; the question is whether the path reflects its importance and user role.

Next, examine internal link distribution. Identify pages that receive many sitewide links, pages that receive few contextual links, and important pages that rely on a single navigation path. Compare those patterns with the site's intended hierarchy.

If a priority page is difficult to reach from related content, add contextually appropriate links where they help users understand the relationship.

Then review cluster coherence. For each major topic or category, identify the primary overview page and the supporting pages that should relate to it. Check whether links work in both directions where that relationship makes sense and whether users can move between supporting resources without returning to the homepage. Do not force every page into a rigid hub model; use the structure that best matches the information architecture.

Use high-performing content carefully as a linking source. Reviewing the top 50 traffic-driving pages can reveal places where a relevant internal link would improve discovery, but traffic alone is not a reason to add a link. The destination must be useful in context.

Finally, inspect anchor text. Descriptive anchors can clarify destination meaning, while repetitive exact-match anchors or generic labels can reduce usability. The goal is clear navigation and contextual relevance, not manufacturing a particular anchor profile.

Performance auditing is most efficient when it starts with templates and field evidence. Pages built from the same component system often share the same rendering costs, so representative testing can identify whether a problem is systemic before the team creates hundreds of individual tickets.

Map the main page templates and select representative URLs for each. Use laboratory tools to diagnose likely causes, then compare the results with field data where available. Laboratory tests are useful for debugging because they provide repeatable conditions.

Field data reflects real-user experiences across devices and networks and should inform whether the issue is widespread enough to prioritise.

For Largest Contentful Paint, inspect the element that becomes the largest visible content and trace whether server response, image delivery, CSS, fonts, or scripts delay it. The commonly cited good threshold is 2.5 seconds.

For Cumulative Layout Shift, identify elements that move after initial rendering and check images, embeds, dynamic banners, fonts, and reserved layout space. The commonly cited good threshold is 0.1.

For Interaction to Next Paint, inspect long main-thread tasks, event handlers, third-party scripts, and heavy JavaScript execution. Do not reduce the work to a score-chasing exercise. The useful question is which component or dependency creates the delay and how broadly that component is used.

Compare template findings with business importance. A problem on a low-use archive template may deserve less urgency than the same issue on core landing pages. Also separate controllable first-party code from third-party dependencies so owners are clear.

After implementation, validate the template again and monitor field data over time. A laboratory improvement can confirm that the code path changed, but it does not by itself prove ranking or conversion impact.

Server or CDN logs can show requests that reached the infrastructure, which makes them valuable for checking assumptions from the crawl. They are especially useful on larger, frequently changing, or technically complex sites where discovered URL sets and actual crawler requests may diverge.

Begin with data quality. Confirm the log source, retention window, timezone, request fields, caching layers, and whether CDN or edge behavior means some requests never reach the origin log. Verify search crawler identities where possible instead of filtering only by the user-agent label.

For pattern analysis, an observation window of 30-90 days can help reduce the risk of drawing conclusions from a short anomaly, but the right window depends on how often the site changes and how much traffic the logs contain.

Group verified crawler requests by template, directory, status class, parameter pattern, and canonical intent. Then compare those groups with the site's important canonical URLs. Repeated requests to obsolete parameters, redirected paths, error URLs, or excluded duplicates may reveal cleanup opportunities, but do not describe every such request as wasted ranking potential.

Search crawlers allocate activity dynamically, and the correct action depends on whether the URLs are legitimately useful or accidental proliferation.

On sites where the URL inventory is large, review patterns rather than relying on size. A site can contain 4 major directories and 5 recurring parameter families without that alone proving a crawl constraint. use logs to investigate whether important sections are rarely requested relative to how often they change.

A site with many pages can still be easy to crawl, while a large URL inventory can create unnecessary discovery paths through parameters or duplication. Size alone does not establish a crawl-budget problem.

Compare log evidence with internal links and sitemaps. If an important page receives very few crawler requests, check whether it is linked, submitted, canonical, and stable before assuming Google has deprioritised it.

If a retired URL is repeatedly requested, look for internal links, external links, old sitemap references, redirects, or historical discovery paths that explain the behavior.

The value of logs is that they show request behavior. They should sharpen the diagnosis, not replace indexation evidence or become a claim about ranking on their own.

Structured data should describe visible page content in a machine-readable way. The audit should therefore begin with accuracy: does the markup represent the real organization, author, product, article, event, or other entity shown on the page, and does the schema type follow the documentation that applies to that feature?

Inventory markup by template. Identify which page types contain structured data, which types are declared, and whether required or recommended properties are complete where relevant. Validate representative pages and investigate recurring errors at the template level rather than opening separate tickets for every URL.

Separate general schema vocabulary from Google search feature eligibility. A markup type can be valid schema without creating a Google rich result, and a page can meet markup requirements without being guaranteed a search feature.

Do not describe structured data as a ranking factor unless you have authoritative documentation for that specific claim.

For organization and author information, keep names, URLs, visible credentials, and relationships consistent with the page. Do not add credentials or expertise claims only inside markup. Structured data is not a place to make hidden assertions that the visible content does not support.

For Google AI Overviews and other Google AI features, do not imply that special schema is required. Use structured data when it accurately describes content and can support understood search features, while keeping the underlying page crawlable, indexable where intended, and useful to readers.

Review stale markup as part of the audit. Events expire, products change, authors move roles, and templates evolve. A technically valid implementation can still become inaccurate if the visible page and markup drift apart.

The audit is complete only when findings can be implemented and validated. Turn the evidence into a sequence that respects technical dependencies and makes ownership explicit.

Step 1: put access and rendering blockers in Layer 1 because later work depends on pages being requestable and understandable. Then place canonical, noindex, redirect, sitemap, and duplicate-intent work in Layer 2; architecture, navigation, and internal-link work in Layer 3; and enhancement work such as structured data and template performance in Layer 4 once the foundation is stable.

Within the sequence, use an internal unblocking label where it helps project management. A label of 2 can identify a fix that enables several later tasks, a label of 3 can identify a broader dependency, and a label of 1 can identify mostly standalone cleanup. These labels are workflow aids, not search impact scores.

Rank work inside each dependency layer by affected scope, business importance, confidence, implementation risk, and effort. If the team uses an internal priority label of 3 for broad-scope work, a dependency label of 3 for work that enables many later tasks, and a cleanup label of 1 for isolated work, document those meanings so they are not mistaken for search engine metrics.

Package each task with reproduction steps, example URLs, affected template or rule, owner, acceptance criteria, rollback considerations where relevant, and the validation method. Group related fixes into sprint-sized work rather than sending a flat spreadsheet with no implementation context.

After deployment, validate the technical state first. Confirm response behavior, directives, rendering, internal links, structured data, or performance depending on the ticket. Then monitor search data after recrawling and reprocessing.

Do not promise an immediate ranking change because implementation, crawling, indexing, competition, and content quality all affect the outcome.

Treat Layer 4 enhancement work as complete only after its own acceptance criteria pass. Revisit the sequence as evidence changes: a new deployment can introduce a higher-priority issue, a supposed blocker may prove harmless after validation, or a broad template fix may remove many lower-level findings at once. A living implementation queue is more useful than a static final report.