SEO Audit Checklist: What a Useful Website Review Covers

An audit can investigate missing pages, a traffic decline, weak service content or risks before a redesign. Those questions overlap, but they are not the same assignment. Decide whether you need a broad baseline or a focused investigation, and describe the decision you want the report to support.

Record the website, language versions, important services and known change dates. If a decline is the trigger, distinguish impressions, visits, inquiries and sales. Each measures something different. A provider cannot establish the cause of fewer sales by examining page titles alone. The SEO audit service should be scoped around the evidence needed for your question.

Identify the pages that sell your services, the navigation that reaches them and any language counterparts. Note old domains, redesigned sections or previous URL changes. A focused inventory is more useful than assuming every discovered URL deserves indexing.

Agree access before the review begins. Search Console can help examine search visibility and indexing; analytics can describe recorded visits and actions; the publishing system can reveal settings behind a problem. Public-only reviews have limits. Ask the reviewer to state which sources were available and which conclusions remain uncertain. Give appropriate permissions through the relevant account controls rather than emailing passwords.

A page can exist without Google knowing about it. A discovered URL can be inaccessible to the crawler. A fetched page can remain unindexed, or another version may be selected. Each state points toward a different investigation.

The report should identify the affected URL, observed status and relevant evidence. A sitemap entry alone is not proof of indexing. A robots.txt restriction also differs from an indexing directive. Google Search Console's URL Inspection tool helps investigate individual URLs, including Google's selected canonical where available. When interpreting its output, keep indexed information apart from the live test. See the missing-page diagnostic guide for the next decisions.

Review the published page, not just its text draft. Does it identify the service, explain requirements, distinguish inclusions and offer a usable next step? Check whether essential information is visible on mobile and whether a visitor must operate a complex interaction to reach it.

Look for inaccurate claims, outdated prices, repeated service descriptions and questions answered only in markup. Titles and headings should describe the individual page. A technical tool may identify duplicate titles, but the reviewer still needs to decide whether the underlying pages should differ, merge or remain as intentional alternatives. The recommendation should explain that decision.

Important services need reachable links from relevant pages. An audit should check the destination and purpose of those links, not merely count them. A guide can explain a decision and link to the related service; the service can link back where the explanation helps a buyer.

Competing URL versions need special care. Parameters, old slugs, protocol variants and language routes may behave differently. Record redirects, canonical signals and internal references before proposing consolidation. Do not recommend removing a page simply because its wording overlaps another. Establish whether it serves a distinct audience or decision and review any available search and conversion history.

An SEO review can identify a reporting problem when measured inquiries fall, but tracking implementation must be expressly included if it will be changed. Test the form journey from submission through the confirmed receipt state. Distinguish a button click from a stored inquiry and a telephone-link click from a completed call.

Ask which events are recorded and what each proves. If confirmation-page visits can occur without a valid submission, they should not be treated automatically as new leads. A technically successful page visit does not establish that the sales team received the inquiry. Where delivery or attribution cannot be verified, the report should preserve that uncertainty.

A usable finding has a location, an observation, an interpretation, a recommended action and a way to check completion. For example, “service page cannot be reached from the services hub” is more actionable when it names both pages and shows the missing path. The proposed correction should fit the observed problem.

Prioritize by customer impact, affected scope, confidence and dependencies. A shared-template problem may need attention before individual content edits. Treat automatic severity labels as inputs rather than business priorities. A low score without the supporting findings does not tell your developer what to change or tell you whether the work has been completed.

The following is an illustrative finding, not a result observed on a customer website. It shows the difference between reporting a warning and defining a correction.

Finding: an old service link reaches the wrong destination

The observation should name the page containing the link, the linked URL and the destination reached during the test. “Broken internal linking” leaves too much for the person approving the work to infer.

Next comes the interpretation: does the old address lead to an unrelated page, an error or another version of the intended service? That distinction matters. The appropriate correction depends on the page's purpose and the destination that should remain.

Recommendation: agree the destination and update the path

A recommendation might propose updating the source link and reviewing what happens to visitors who still use the old URL. If a redirect is appropriate, its destination needs approval. A blanket instruction to send everything to the homepage would not resolve the visitor's original question.

Validation: test the customer path after publication

The completion check should confirm that the source page links to the approved destination and that any agreed redirect behaves as intended. Record the test date and remaining exceptions. This establishes what was corrected; it does not prove a later ranking improvement.

Use the same test when reading the rest of an audit: can you locate the issue, understand the recommendation and tell when it is complete? If not, request clarification before authorizing changes. You can inspect the sample audit or discuss a review through SEO audit services. A technical correction can then be quoted separately when implementation is needed.

Separate confirmed corrections from experiments and unresolved questions. Assign an owner to each approved task, agree the release process and define what must be retested. If implementation is outside the audit, request a separate estimate rather than assuming it is included.

To commission a review, send the website and the question you need answered. Include affected URLs and relevant change dates. An initial scope can then specify sources, deliverables and exclusions. Keep the original findings and the implementation record together so later reviews can distinguish an old recommendation from a completed, validated change.