You have a website, but important pages are hard to find, inquiries have slowed or a recent change has left you unsure what still works. Then an automated report arrives with hundreds of warnings. Which ones matter—and what should you buy next?
A useful technical SEO audit answers that question. It connects observations to the pages and customer journeys your business depends on, explains the likely consequences and gives you a practical order for repairs.
The result should help you commission the right work: a focused fix, better content, a performance improvement or, when justified, a rebuild.
Start with the business decision
Describe the concern before choosing the tools. “Our main service page disappeared after a migration” calls for a different investigation from “People find us, but few contact us.”
Technical findings may explain some visibility or inquiry problems, while demand, offer quality and competition may need separate investigation.
Agree the important pages, recent changes, available history and questions the audit will answer. Include a representative sample of service pages, articles and inquiry routes, then identify which shared templates need wider inspection. Record the coverage so you know how far each conclusion reaches.
Our websites and search service can start with diagnosis or an already understood repair. An audit earns its place when evidence is needed to choose the work.
Ask for evidence in five areas
1. What the website actually serves
Check response statuses, redirects, headers and the HTML returned by the server. Compare that with the content and links available after the page renders. A page that looks complete in one browser may depend on scripts or resources that need investigation.
Google describes crawling, rendering and indexing as separate stages. The audit should identify which stage an observation concerns, rather than labeling every missing page a “JavaScript problem.” See Google’s JavaScript SEO guidance.
2. Whether the right pages can be discovered and indexed
Review internal links, sitemap entries, crawl rules and indexing instructions against each page’s purpose. Private, duplicate and retired pages need different treatment from a main public service page.
For example, robots.txt controls crawling, while noindex instructs supported search engines to exclude a page from indexing. Google must be able to access a page to see its noindex instruction. These controls need checking together, as explained in Google’s indexing-control documentation.
Where authorized Search Console access is available, label stored indexing information and live test results separately. The stored report concerns Google’s indexed version; a live test checks current accessibility and possible indexability. Google’s URL Inspection documentation explains that distinction. An indexing request is a request to crawl, not a completed indexing result.
3. Which version of a page represents the business
Compare redirects, canonical annotations, sitemap URLs and internal links. They should tell a consistent story about the preferred address, especially after a domain or platform change.
A declared canonical is a signal to Google, not proof that Google selected it. The finding should show any conflicting signals and explain the correction. Google’s canonical guidance describes the relative roles of redirects, canonical annotations and sitemaps.
4. How the experience performs
Review important mobile journeys alongside performance measurements. Identify the tested URL, device profile, conditions and individual metrics, then connect any recommendation to an observed loading, responsiveness or layout problem.
Keep lab diagnostics and real-user measurements labeled. Lighthouse simulates a page load; field data reflects recorded user experiences and may be unavailable for a lightly visited page. Use lab results to investigate a specific issue and compare a repair under consistent conditions. Field data answers a different question. Google’s PageSpeed Insights explanation covers both.
5. Whether interested visitors can take the next step
Follow the route from a service page to contact or booking. Inspect navigation, mobile readability, form instructions, errors and available fallbacks. Agree any submission test before sending it, and record what was actually confirmed: reaching a form, application acceptance, inbox receipt or a completed booking.
Expect findings you can commission
Planning example: A fictional public service page returns successfully but contains noindex, conflicting with the owner’s intention to make it discoverable.
A useful finding would record:
- Evidence: The exact URL, inspection date, response status and relevant header or HTML excerpt.
- Scope: The affected page and any other routes confirmed to share the same setting.
- Potential business impact: Google may exclude a core service page when it processes the directive, affecting one route by which prospective buyers discover the offer. Review page and inquiry history to investigate the business effect.
- Priority and confidence: Investigate early if this is an important service page with a confirmed public purpose. Confidence is high in the observed directive conflict; its effect on visibility or inquiries needs the relevant search and business records.
- Proposed repair: Locate the responsible template or configuration and correct the instruction for the intended public pages.
- Dependencies and effort: Confirm the owner's intended indexing setting, identify the responsible template and check other routes using it. Estimate the repair after that investigation; a page setting and a shared configuration issue can require different work.
- Validation: Recheck the released response, related crawl controls and preferred URL; record subsequent indexing observations separately.
That gives a developer a specific change to investigate and your team a clear way to review it. “Fix indexing” does neither.
Set a repair order around impact and confidence
Prioritize confirmed problems affecting important pages and visitor tasks. Separate those from hypotheses that need another observation. Group repeated warnings when one shared template causes them, and record dependencies before work starts.
Ask three questions of each recommendation: What is affected? What evidence supports it? What will we check after the change? This makes the priority list useful when budgets or development capacity require phased work.
Leave with a decision and a usable handover
The handover should include reviewed scope, evidence references, prioritized findings, open questions and a recommended next phase. Proposed repairs need responsible roles, dependencies and completion checks.
A specific defect may need a focused repair. Weak buyer information may need content work. A rebuild should have requirements the current platform cannot reasonably meet; our redesign and migration guide covers that decision.
Agree investigation, implementation and continuing search work as clear purchases. Engagement options explain how a defined project can lead into optional ongoing work.
Discuss your website concern. Tell us the URL, what has changed and what you want the site to do better. We can help define the investigation that moves that decision forward; leave credentials and confidential customer records out of the inquiry.