How to do a technical SEO audit: An engineering field guide

A technical SEO audit should end with a developer knowing what to change, a business owner understanding why it matters, and a repeatable test showing whether the change worked. A spreadsheet containing hundreds of warnings does not meet that standard.

The useful unit of work is a verified defect: an important page cannot be discovered, its content is not visible to Google, or multiple URLs represent the same content without a clear preferred version. Each defect needs evidence, scope, an owner and an acceptance test.

This field guide explains How to do a technical SEO audit as an investigation rather than a tool export. The objective is to remove technical obstacles to discovery and understanding-not to promise indexing, rankings or enquiries.

Establish the system boundary before collecting warnings

Start with a short audit brief. Identify the production domain, relevant subdomains, CMS, rendering framework, hosting arrangement and person responsible for deployments. Record recent migrations, template changes and experiments. These details help you distinguish an isolated page mistake from a shared application defect.

Define which pages the business actually wants people to discover through search. Product listings, service pages and documentation may deserve attention; account screens and temporary campaign variants may have different requirements. Do not assume every URL should appear in search.

Create a page-family register with four fields:

• Family: service detail, product detail, category, article or documentation.
• Business purpose: explain an offering, support product evaluation or answer a customer question.
• Expected search treatment: intended for search, intentionally excluded or requiring a decision.
• Technical owner: the team controlling its template and publishing rules.

This is not an acquisition strategy exercise. Choosing which audiences and offers should generate leads belongs in an SEO strategy for lead generation. Nor is it an editorial brief or topic-architecture project. Here, the question is whether the chosen pages function as intended for users and search engines.

Set exclusions explicitly. Checkout usability, relationship workflows and email recovery need their own investigations. They may share infrastructure with SEO pages, but a technical audit should not quietly expand into every marketing problem.

Build an evidence kit you can reproduce

Request read-only access wherever practical. Useful inputs include Search Console, a CMS URL export, existing sitemaps, a site crawler and browser developer tools. Hosting or CDN logs can help when access failures are suspected, but they are not mandatory for every small-site audit.

Use analytics only when it answers a prioritisation or measurement question. Follow applicable consent requirements and avoid copying personal data into audit documents. Do not send names, email addresses, phone numbers or sensitive form contents in analytics events. If logs contain identifying data, request a minimised extract rather than unrestricted access.

Record the collection date and crawler configuration. Keep the start URLs, crawl limits, rendering mode and exclusions alongside each export. Otherwise, differences between two crawls may reflect different settings rather than an improved website.

Use several URL inventories

Collect URLs from the CMS, sitemap, internal crawl and Search Console. Compare the lists instead of choosing one as the complete truth.

A crawler follows the paths available to it. If a page has no discoverable route from the crawl's starting points, that page may not appear in the export. Conversely, a CMS can retain URLs that no longer represent useful public pages.

Label each URL by source and page family. Preserve the original address even if you create a normalised comparison field. Automatically removing query strings or changing letter case before investigation can hide the very variations you need to inspect.

Hypothetical example: an education website lists 120 course pages in its CMS, but an internal crawl finds 90. The 30-page difference is an investigation queue, not proof of 30 orphan pages. Some may be unpublished, intentionally excluded or outside the crawler's configured scope.

Sample by template, then expand by failure pattern

For a large site, begin with representative pages from each family: an established page, a recently published page, a business-critical page and a known exception. Include relevant locale and device presentations.

Sampling helps locate shared defects, but it does not establish that every unsampled page is healthy. When a sample exposes a template problem, expand the test across that family. Report both the confirmed affected count and the portion not yet tested.

Trace discovery before investigating rankings

Google's SEO Starter Guide explains that Google primarily discovers pages through links from pages it already knows. That makes internal navigation a practical starting point.

Choose an important destination and follow the route from a relevant entry page. Can a visitor find it through navigation, category pages or contextual links? Does the route reach the correct destination? Is the link text descriptive enough to explain what comes next?

Do not impose a universal click-depth limit. A buried service page deserves investigation because its route may be unclear, not because every website must satisfy an arbitrary number.

For each priority page, record:

1. The pages linking to it.
2. Whether those links appear in the rendered page.
3. The destination reached after any redirects.
4. Whether the surrounding context makes the link useful.

If an important page appears only in the CMS export, confirm that it is published and intended for search. Then propose a link from the most relevant parent or supporting page. Avoid solving discoverability by adding every URL to a bloated footer.

Review the sitemap as another discovery input. Compare it with the intended public inventory, then investigate omissions and obsolete entries. Google describes sitemap submission as optional; it is not an indexing guarantee or a substitute for useful navigation.

Keep the remedy proportional. A missing course link may need one template adjustment. It does not automatically justify rebuilding the entire site hierarchy or rewriting its editorial architecture.

Separate access, rendering and search appearance

A URL loading in your browser does not establish that Google receives equivalent content. Your browser may have cookies, an authenticated session or a location-specific configuration. Google also needs access to resources such as CSS and JavaScript to understand a page properly.

Treat the investigation as three separate questions:

• Access: can the relevant crawler retrieve the page and required resources?
• Rendering: does the retrieved page produce the important content and links?
• Search appearance: is there evidence that Google has indexed the intended page?

One answer does not settle the others.

Inspect crawl controls and delivery failures

Review production robots.txt rules against the intended page-family register. Google's crawler overview states that common crawlers, including Googlebot, respect robots.txt rules for automatic crawling. An accidental restriction on a public section therefore deserves prompt investigation.

Do not treat all Google clients as interchangeable. The same documentation distinguishes common crawlers, special-case crawlers and user-triggered fetchers. A successful request from one tool is not proof that every automatic crawler has equivalent access.

Ask the infrastructure owner to investigate access-denied responses, recurring server failures and location-based restrictions affecting public pages. Capture the requested URL, time, response and conditions. One failed request is evidence of that request failing-not yet proof of a persistent sitewide outage.

Where logs are used, a Google-looking user-agent string alone is insufficient for confident attribution. Google’s crawler-verification documentation explains how to check source IP ranges or use reverse and forward DNS lookups. Have the infrastructure team verify traffic before making claims about Googlebot behaviour.

Never remove security controls wholesale to resolve a suspected SEO issue. Narrow the rule causing the problem and test the proposed exception with the security owner.

Compare what users and Google can see

Use Search Console's URL Inspection tool for representative priority pages, as recommended in Google's Starter Guide. Compare the available inspection evidence with a fresh, logged-out browser visit.

Look for the page's defining information: the service description, product details, course information, main heading and links to related destinations. Investigate a page that shows a complete offering to you but only a shell, loading state or consent overlay under another relevant condition.

Record missing elements precisely. “JavaScript SEO problem” is not a useful ticket. “Course modules are absent from the inspected output on the course-detail template” gives an engineer a reproducible symptom.

Hypothetical example: a SaaS feature page displays its explanation only after a visitor selects a region. The audit should test the default experience and what Google's inspection shows. The proposed fix is to make the intended public explanation reliably accessible-not to show a special keyword-filled version only to crawlers.

Google notes that location can affect what its crawler sees and that crawling generally originates in the United States. For a location-sensitive website, record the default content and verify that it is an acceptable representation of the page.

Resolve URL identity before multiplying pages

A website can expose the same material through campaign parameters, alternative paths and old URLs. Google's Starter Guide explains that duplicate content is not itself a spam-policy violation, but it can confuse users and consume crawling resources on unimportant variations.

Build a duplicate investigation around content and intent, not just matching titles. Two pages with the same template are not necessarily duplicates. Two differently styled pages may still represent the same offering.

For each suspected group, record the preferred URL, alternative URLs, content differences, existing redirects and declared canonical information. Where Search Console provides relevant canonical evidence, compare it with your intended version rather than assuming your declaration settled the matter.

Choose a remedy according to purpose:

• If an alternative address no longer needs to remain independently available, consider a redirect to the equivalent preferred page.
• If an equivalent variation must remain accessible, consider the rel="canonical" link element to indicate the preferred version.
• If pages serve meaningfully different needs, do not consolidate them merely because a crawler labels their titles as duplicates.

These options follow Google's guidance on reducing duplicate URLs. They do not guarantee that Google will select the version you prefer.

Hypothetical example: /courses/analytics/ and /courses/analytics/?campaign=summer show the same course information. The team may decide the parameter version must remain usable for campaign handling while the clean URL is preferred for search. Compare their canonical declarations, sitemap inclusion and internal links for consistency with that decision.

Now consider /courses/analytics/online/ and /courses/analytics/classroom/. If they describe genuinely different delivery formats, mechanically consolidating them could remove useful distinctions. The technical decision needs product context.

Before changing a URL pattern, list dependencies such as navigation, campaign destinations and application routing. Test a limited representative set first. A cleaner-looking URL is not sufficient justification for a risky migration; Google explicitly cautions against dropping everything to reorganise an existing site.

Investigate search exclusions without chasing an index count

Use Search Console to investigate priority URLs and groups of similar outcomes. Keep a distinction between pages you intend to be searchable and pages the business has deliberately excluded.

For an important missing page, work backwards through the evidence: is it published, linked, accessible and visibly complete? Does it represent distinct information, or is it another address for content already available elsewhere? Are its technical settings consistent with the intended search treatment?

If an exclusion appears intentional, identify the decision owner before changing it. An SEO audit must not expose private, unfinished or account-specific material simply to increase the number of searchable URLs.

Equally, avoid treating every “not indexed” outcome as a technical defect. Google's Starter Guide makes clear that inclusion is not guaranteed. When access and rendering checks pass, the remaining investigation may involve content usefulness or duplication rather than infrastructure.

Mark unresolved cases honestly: “No technical blocker confirmed in the tested conditions” is more accurate than “Google must index this page.” Specify what was checked and what remains uncertain.

Audit templates and loading behaviour without inventing ranking formulas

Template-level checks are valuable because a single implementation error can affect many pages. Inspect whether titles describe the current page, headings identify its subject and image descriptions fit their context.

The purpose here is to detect broken generation rules, not to rewrite every page. A service template that gives every offering the homepage title is a technical publishing defect. Choosing persuasive wording for each offering belongs in an on-page SEO checklist.

Google's Starter Guide supports clear, distinct titles and descriptive image alt text. It also explains that search snippets may come from page content rather than the meta description. Do not promise that correcting a field will force a particular search-result presentation.

For loading behaviour, collect repeatable browser observations under documented conditions. Record viewport, connection setting, cache state and whether the visitor is logged in. Investigate visible failures such as delayed primary content, broken resources or an overlay preventing access to the explanation.

A performance-tool score is an investigation aid, not a revenue forecast. Tie each proposed change to an observed problem: a large decorative asset delays the useful content, or a third-party script interrupts page interaction. Have an engineer isolate the cause before removing dependencies.

Tradeoffs matter. Reducing image weight must preserve necessary detail; delaying scripts must not break required consent controls. Google also states that HTTP/2 crawling provides no Google-specific ranking boost. Infrastructure improvements should be justified by their actual operational value, not invented ranking bonuses.

Check experiments that alter public pages

Active website experiments can complicate URL and rendering evidence. Ask who owns each test, which pages it affects and when it will be reviewed. Capture the configuration when collecting audit evidence.

Google's website-testing guidance recommends several specific safeguards:

• Do not show one set of pages to Googlebot and another to humans as an SEO tactic.
• For experiments using alternative URLs, use canonical links to indicate the original preferred URL.
• Use a temporary 302 rather than a permanent 301 when redirecting users into a temporary variation.
• Remove experiment elements when the test is finished.

Google also notes that Googlebot generally does not support cookies. Check the experience available without them rather than assuming your own assigned variant is universal.

The audit should verify search-safe implementation, not declare an experiment statistically conclusive. Test duration depends on the design and available evidence; an arbitrary visitor count cannot guarantee certainty.

Convert findings into a repair queue

Prioritise by business relevance, confirmed scope, strength of evidence and implementation risk. Avoid multiplying speculative traffic gains into an impressive-looking financial estimate.

A sensible first group contains verified access or content-visibility failures on important public pages. Next come repeatable discovery and URL-identity problems. Cosmetic consistency issues usually follow, unless investigation reveals a broader defect.

An engineering-ready ticket should contain:

1. Observed behaviour: what happened, where and when.
2. Expected behaviour: what the page-family requirements say should happen.
3. Evidence: representative URLs, captured output and reproduction steps.
4. Scope: confirmed affected pages and untested areas.
5. Proposed change: the smallest plausible intervention.
6. Acceptance and rollback: how to verify the fix and reverse it safely.

Hypothetical ticket: course-detail pages are absent from relevant category navigation after a template release. The CMS export confirms they are public. The proposed change restores course links within the category template. Acceptance requires the links to appear for logged-out visitors, lead to the intended destinations and be discoverable in a repeat crawl using the original settings.

That ticket does not promise more enquiries. Its business value is a restored route to commercially relevant information. Search and commercial outcomes require separate observation.

How Anurag would deliver the audit

For a technical SEO audit engagement, Anurag would begin with the page-family register, Search Console access, URL inventories and a short discussion with the development owner. Recent release history and business priorities would establish where investigation should start.

He would compare discovery paths, inspect representative rendering evidence, review URL duplication and reproduce suspected failures. Infrastructure specialists would be involved where the evidence points to delivery or security controls rather than CMS configuration.

The outputs would be a prioritised issue register, annotated examples, template-level recommendations and developer-ready acceptance tests. An executive summary would distinguish confirmed defects from hypotheses and explain which commercially important pages are affected. Findings requiring editorial judgement or acquisition planning would be separated from technical implementation work.

Measurement would follow three layers. First, repeat the original test to confirm the defect is resolved. Second, review subsequent Search Console evidence for the affected page family. Third, observe relevant organic landing-page and consented conversion reporting, noting concurrent campaign, content and product changes.

These layers prevent an important mistake: treating a successful deployment as proof of growth. A before-and-after increase alone does not establish causation. Google says changes can take hours to months to be reflected and may not produce a noticeable search improvement.

If your team needs a scoped investigation and an implementable repair queue, contact Anurag with your website, platform, affected page families and suspected symptoms. Share access securely after scope is agreed rather than sending credentials in an enquiry.

Close the repair loop

A finding is not closed when someone marks the code task complete. Retest production, compare it with the captured baseline and check neighbouring templates for regressions. Preserve the release date, evidence and remaining uncertainty.

Use different statuses for implementation and outcomes: deployed, technically verified, awaiting search observation and reopened. This keeps the team from confusing “the correct content now renders” with “Google has processed the change.”

The durable result of an audit is a small collection of reliable checks that can be repeated after releases: important pages remain linked, intended content remains visible, URL preferences remain coherent and public sections remain accessible. Start with the highest-value verified failure, fix it safely, and keep the test that would catch it next time.

Sources

• Google Search Central: SEO Starter Guide - discovery through links, resource access, URL Inspection, duplicate content, titles, images and limitations on search outcomes.
• Google: Overview of crawlers and fetchers - crawler categories, robots.txt behaviour, geographic access, identity verification and HTTP/2 limitations.
• Google Search Central: Minimise A/B testing impact in Search - experiment canonicals, temporary redirects, cookies, cloaking and removal of completed test elements.