A technical audit should produce decisions, not a spreadsheet of unexplained warnings. Its purpose is to find obstacles that prevent useful pages from being accessed, understood, or used, then identify a safe way to remove those obstacles. The most valuable finding is often a small configuration error affecting an entire template.
Start with a defined scope. Record the domain, important subdomains, main page types, recent releases, and business-critical journeys. Obtain permission before crawling heavily or changing production settings. For a small publication, a careful sample and a modest crawl can be more useful than an elaborate tool stack.
On this page
- Build an inventory before changing anything
- Check access and response codes
- Review crawling and indexing controls
- Compare canonical signals
- Inspect site architecture and internal links
- Test rendering and mobile usability
- Evaluate performance in context
- Check structured data and sitemaps
- Prioritize by impact, reach, and confidence
- Write a repair ticket someone can verify
- Close the loop after deployment
Build an inventory before changing anything
Collect URLs from the site’s navigation, XML sitemap, content system, and Search Console where access is available. These sources answer different questions. A crawl shows what a crawler can discover through links; the content system may reveal pages that have no links at all.
Group the inventory by template: articles, categories, products, locations, search results, and utility pages. Record which groups should be indexed. Internal search pages and private account pages do not need the same treatment as public guides.
Save the current configuration and a few representative responses. This makes rollback and comparison possible. Avoid deleting or redirecting pages simply because they have little traffic; first establish their purpose and whether anyone depends on the URL.
Check access and response codes
Open representative URLs and inspect the actual HTTP response. Important live pages should normally return 200. Moved pages need appropriate redirects. Missing resources should communicate that they are missing, rather than returning a successful response with a vague error message.
- Check HTTP-to-HTTPS and preferred-host behavior.
- Look for redirect loops and unnecessary chains.
- Investigate recurring server failures by time and template.
- Test a deliberately nonexistent URL.
- Check whether the CDN or security layer treats crawlers differently.
Do not redirect every missing URL to the homepage. A replacement should serve a comparable need. Where no equivalent exists, a clear not-found response can be the honest and useful outcome.
Review crawling and indexing controls
Read robots.txt and inspect robots meta tags and HTTP headers on actual pages. These controls operate differently. A crawl restriction can prevent a search engine from seeing an indexing directive on the blocked page, so combining controls without understanding them can produce surprises.
Check the production site’s visibility settings after migrations or staging launches. Then sample public pages for accidental noindex directives. Also confirm that deliberately excluded pages remain excluded.
Document the intended state before editing. “Remove all noindex tags” is not an audit recommendation; “remove the unintended noindex directive from the published article template” is.
Compare canonical signals
Inspect canonical tags, redirects, internal links, and sitemap URLs together. They should tell a consistent story about the preferred version of a page. Conflicting signals make the site harder to interpret and the audit harder to validate.
For parameter variants, determine whether the content is truly equivalent. A sorting parameter may duplicate a collection, while a meaningful filter can create a distinct browsing experience. The correct approach depends on usefulness, scale, and whether the filtered page is intended for discovery.
Test the canonical destination directly. A tag pointing to a redirect, missing page, or unrelated resource is a concrete issue to investigate. Read our canonical implementation guide before applying sitewide rules.
Inspect site architecture and internal links
Can a visitor find the most important pages from the main navigation and relevant topic hubs? Are related articles connected naturally? Does pagination expose older content? A sitemap is helpful, but it cannot make an incoherent navigation system useful.
Look for orphan pages, broken links, and links that unnecessarily pass through redirects. Review anchor text in context. A link should explain the destination sufficiently for a reader to choose it.
For a publication, a category page can be a useful hub if it has a clear topic, description, and relevant articles. Do not exclude all archives merely because they are generated by the content system.
Test rendering and mobile usability
Inspect the main content, menus, and forms on small screens. Check whether text is readable without zooming, controls are reachable, tables remain usable, and overlays can be dismissed. Compare the rendered page with the content you expect to be present.
JavaScript-dependent content deserves targeted checks. A crawler warning about scripts is not enough to diagnose failure. Look for missing text, inaccessible links, or actual errors in the rendered experience.
Include keyboard navigation. Visible focus, descriptive labels, and a logical heading structure improve usability and make manual verification easier.
Evaluate performance in context
Use field data where available to understand real visitor experience, and lab tests to diagnose reproducible problems. A single laboratory score is not a complete description of site performance. Test representative templates and realistic mobile conditions.
Common practical improvements include correctly sized images, explicit image dimensions, fewer unnecessary scripts, and avoiding large layout shifts. Preserve functionality while optimizing. A faster page with a broken menu is not an improvement.
Record the tested URL, date, device conditions, and tool. This lets another person reproduce the finding and separates a temporary network issue from a persistent template problem.
Check structured data and sitemaps
Structured data should accurately describe visible content. Validate relevant markup and fix substantive mismatches rather than adding every available schema type. Passing validation does not guarantee a special search appearance.
Review the sitemap for intended canonical URLs. Exclude missing, redirected, private, and deliberately non-indexable pages where appropriate. Confirm that the sitemap itself is accessible and that the content system updates it after publication.
Prioritize by impact, reach, and confidence
| Finding | Suggested priority | Acceptance check |
|---|---|---|
| Public article template accidentally noindexed | Urgent | Directive corrected on representative articles |
| Important navigation link is broken | High | Link reaches the intended live page |
| Several images are oversized | Scheduled improvement | Smaller payload without visible quality loss |
| One harmless title-length warning | Review in context | Title remains clear and accurate |
Assign an owner and explain why the issue matters. Include evidence, the proposed correction, dependencies, rollback notes, and the validation method. Avoid scoring every finding with a precise financial estimate unless you have a defensible basis.
Write a repair ticket someone can verify
Consider a category template that links to an obsolete article path. A useful ticket names the affected template, shows an example source page, identifies the old destination, and provides the intended replacement. It also explains whether the same pattern appears elsewhere and how that conclusion was reached.
The acceptance criteria might require that the link point directly to the live article, preserve a descriptive label, and remain usable on mobile. The developer can then implement a bounded change, and the reviewer can verify the result without repeating the entire audit.
Keep unrelated findings in separate tickets when they have different owners or rollback requirements. Grouping everything into “fix SEO” makes both prioritization and completion ambiguous. A compact, reproducible ticket is often the most valuable deliverable an audit produces.
Close the loop after deployment
Recheck the changed URLs and neighboring examples. A template fix can introduce a new problem elsewhere. Update the issue log with the deployment date and confirmed outcome, then monitor search reports over an appropriate period.
A completed technical audit leaves the team with fewer unresolved questions and a manageable repair queue. It should also make the next audit easier by preserving decisions and evidence.
Reference: Google’s developer guide to Search. For moved URLs, continue with 301 and 302 redirect decisions.