A technical SEO audit should turn website behavior into a prioritized set of decisions. It is not simply a crawl export or a score from a performance tool. A business owner needs to know what is affected, why it matters, who can fix it and how the change will be verified without putting useful pages or customer data at risk.
The checks below cover discovery, indexing, experience and measurement. They are starting points, not proof that every warning applies to every site. Use a staging environment where appropriate, keep backups and review changes that affect URLs or search access. Search engines retain control of indexing and ranking, even when a technical implementation is correct.
Begin with scope and a safe baseline
Choose representative pages before running tools: the homepage, an important service or category, a detail page, an article and a form. Add any template with unusual behavior. Record the environment, date and known limitations so a later comparison is meaningful. Testing a private preview should not accidentally enable public indexing.
Ask who can change the CMS, templates, hosting and redirects. A useful audit separates recommendations from work the team is authorized and able to implement. Google’s SEO fundamentals provide context, while your actual URL and template behavior determine the fix list.
Discovery and response checks
- Important URLs return the intended status. Check real responses rather than assuming a page is valid because it looks normal. A missing page should not quietly return a success response.
- Primary navigation reaches useful content. Important pages should not depend only on a search box, hidden interaction or unrelated external link for discovery.
- Internal links use current destinations. Replace unnecessary redirecting or broken links where the final intended page is known. Keep descriptive link text.
- Robots rules match the environment. Production and staging need different access decisions. Review the actual served file, including any static file that bypasses the application route.
- XML sitemaps contain eligible URLs. Include published, intended, canonical pages rather than private drafts, removed services or every URL a CMS can generate.
These checks establish whether a useful page can be reached and whether the surrounding signals are coherent. A sitemap does not force indexing. A robots rule also has a specific role; do not assume that blocking a crawl is the same as requesting removal from an index. Review the intended outcome before editing.
Indexing and URL consistency checks
- Page-level indexing directives are intentional. Inspect meta tags and response headers. A copied noindex header can affect a live page even when the template’s visible content looks correct.
- Canonical URLs describe the preferred page. Check whether a canonical points to the intended equivalent URL, not a homepage or unrelated page chosen as a shortcut.
- Redirects have a clear purpose. Use relevant destinations, avoid loops and review long chains. A deleted article does not automatically belong on the homepage.
- URL variants are handled consistently. Review protocol, host and trailing-slash behavior, and ensure internal links use the chosen form.
- Parameters and filters have an indexing strategy. Decide which combinations provide useful search destinations and which mainly reproduce existing content.
A hypothetical store might generate sorting and filter URLs that all display closely related products. The right decision depends on user value and platform behavior, not a blanket rule to index or block everything. Document the pattern, test representative cases and preserve a rollback path for changes affecting many URLs.
Content and rendering checks
- Main information is available reliably. Compare the delivered page and the normal rendered experience. Essential explanations should not vanish when an optional script fails.
- Titles and headings describe the page. Check for missing, duplicated or misleading labels, and avoid multiple competing H1s introduced by templates and editors.
- Page templates provide distinct useful content. Thin service-and-city duplicates need an editorial decision, not just a technical canonical added to hide the problem.
- Structured data matches visible facts. Validate the JSON and the meaning. Do not publish ratings, offices or individual credentials that have not been supplied and verified.
- Pagination and archives remain usable. Confirm that later pages can be reached, links work and drafts do not leak into public search or feeds.
Technical and editorial work overlap here. A valid response does not make an article useful, and a well-written article cannot repair an inaccessible template. Coordinate page-level content improvements with the implementation so each team knows which part of the problem it owns.
Mobile and performance checks
- Layouts fit small screens. Read real headings and long labels at narrow widths. Check menus, tables, dialogs and forms for page-level horizontal overflow.
- Images have sensible dimensions. Reserve space with width and height, provide suitable sizes and avoid loading a huge desktop image for a small card.
- The main visual loads with appropriate priority. Do not lazy-load the key above-the-fold image merely because a global plugin enables it for every image.
- Scripts have an actual purpose. Review duplicate analytics, unnecessary libraries and code that blocks content or interactions. Test with reduced motion and JavaScript disabled.
- Layout and interaction remain stable. Inspect font loading, banners, delayed widgets and controls that move while someone tries to use them.
Use lab tools as diagnostic evidence, not as a marketing certificate. Record the device profile, throttling, page and date. A local test or a single Lighthouse run is not the same as production field performance. A website implementation review should distinguish measured results from targets still needing live verification.
Forms, privacy and maintenance checks
- Forms store successful enquiries. Test validation, server errors and the no-JavaScript path. A success animation is not evidence that the business received a lead.
- Repeated submissions are controlled. Verify spam protection and idempotency so retries do not create duplicate records or misleading conversion events.
- Optional tracking respects consent. Inspect actual network requests before acceptance, after rejection and after acceptance. Keep admin and private previews excluded.
- Protected files and administration stay private. Check the public document root, secret files, authentication, headers and access permissions without exposing credentials in reports.
- Publishing and scheduled work are monitored. Confirm the scheduler, queues, failed jobs and real delivery paths. A configured command is not proof that shared hosting is running it.
A measurement review should then confirm that a successful stored outcome, rather than a button click, is the event being reported. Keep private form fields out of analytics payloads and URLs.
Read a finding as a decision, not a score
Consider a hypothetical service page with an accidental noindex header. The evidence is the actual response, the affected URL pattern and a confirmation that the page is intended for public discovery. The proposed fix is to remove the unintended directive in the relevant environment. Verification means requesting the page again, checking related templates and ensuring private previews still remain excluded. A report should show that chain clearly.
Now consider a page that loads slowly because a large image is downloaded on mobile. The issue is not resolved by changing a score label or adding a loading animation. The team needs to inspect the image source, displayed dimensions, responsive choices and any effects on visual quality. It should verify the result under a documented test profile and check that reserved image space prevents a new layout shift.
Both examples require judgement about scope. A shared template fix may affect many pages and deserve broader regression checks. A single editorial image replacement may need only focused checks. The audit should help the team choose the smallest reliable implementation rather than insist that every task trigger a complete rebuild or redesign.
Keep unknowns explicit. If production access is unavailable, say that the issue was observed locally and live verification remains outstanding. If a third-party widget cannot be changed directly, identify the owner and the available alternatives. Unknown information should become a clear follow-up item, not a fabricated completion claim.
The same discipline applies to severity. A broken enquiry path can deserve attention before an obscure metadata warning, while an indexing error on an important template may justify an urgent release. Priorities should follow the affected business and search journeys. Tool labels can assist triage, but they cannot replace an explanation of impact, risk and ownership.
Use a release record to connect implementation and review. Record which files or settings changed, what was tested and what remains outside the scope. That makes it possible to revisit an observation without reconstructing the entire project from memory.
Turn findings into work the team can finish
Give each finding an affected pattern, example URL, evidence, proposed change, responsible person and acceptance check. Prioritize issues that block important pages or real customer actions. A small set of well-explained fixes can be more useful than a large backlog nobody can confidently assign.
Separate pre-existing issues from changes introduced during implementation. Test the smallest relevant case first, then broaden checks when shared templates or URL rules are affected. Keep records and secrets safe, and do not run destructive database commands to make a development test pass.
After a release, verify the actual served responses and key journeys again. Hosting caches, static files and production settings can differ from local assumptions. Request a technical SEO audit if you need a prioritized review, and agree explicitly which implementation and production checks are included.