An SEO audit checklist for findings you can act on
Updated · By SEOAction
An SEO audit checklist should help you agree what you are examining, record what you found, and define work someone can check. Start with scope and evidence before assigning fixes. The checklist below is our suggested way to turn a review into useful tasks rather than an unexplained score.
It is a planning and handoff method, not an exhaustive technical audit or a claim that completing a list will improve rankings. Use current primary documentation and a suitable verified test for each technical question you actually investigate.
Agree the question and the boundaries
Write down why you are doing the audit. Include the website areas under review, the decision the work should support, who can authorize access, and who will receive the findings. Record a specific exclusion when you are not checking a system, page group or account.
Discuss the work the recipient can realistically do. Our suggestion is to separate an investigation that needs a developer from an editorial change the owner can review. Avoid producing a large implementation list without knowing who will assess it or whether the required evidence is available.
Keep a dated scope note with your report. If the scope expands, record the new question and any additional permission needed before proceeding. Do not imply that an examination of a few example pages represents a complete review of an entire site.
Decide what evidence a check needs
For each proposed check, identify the source you will inspect and what would count as a supported observation. A tool output, page inspection and an untested suspicion should have separate labels in your notes. Keep enough context for a reviewer to understand which page or configuration you examined.
Choose the official guidance relevant to the particular behavior. Our suggested checklist does not supply universal thresholds for every website, a preferred commercial tool, or a shortcut around checking what an output means. Mark a check incomplete if you cannot establish its method or scope.
Before describing a failure, compare the observation with the intended page behavior. Write the evidence first and the possible explanation second. If the explanation depends on information you have not obtained, turn it into a follow-up question rather than a confirmed defect.
Practice with a small findings register
Our audit example CSV contains two synthetic items with evidence, owner and acceptance fields. One concerns an example title; the other records a possible speed issue without a measurement. Neither item came from a real site audit.
Our local CSV check confirmed the fields were present and kept the unmeasured item as an investigation. It did not run a speed test, inspect a live website or establish a technical cause. Use the example to practice the distinction between evidence to review and a fix ready to assign.
Create your own working row for one actual question within your authorized scope. Record where the evidence is saved, what it shows and what is still unknown. Ask a reviewer to explain the row back to you before treating it as a useful handoff.
Give a supported task an owner and an acceptance check
Write the proposed change in plain language. Add the intended owner and the exact observation that should be checked after the work. Our suggestion is to keep the acceptance condition focused on the work itself, such as comparing a revised title with the page it describes.
Separate that acceptance check from a later performance review. A completed change and a favorable search outcome are different claims requiring their own evidence. The official starter guidance does not promise automatic first-place rankings or guaranteed inclusion in the index.
If a task cannot yet be described without guessing its cause, assign the investigation instead. Name the missing evidence and the person who can obtain it. Avoid instructing someone to implement a speculative repair merely to close a report item.
Prioritize within your actual constraints
Our suggested review order considers the evidence available, the importance of the affected reader task, and the practical work needed to investigate or change it. Discuss that reasoning with the site owner. Do not disguise this judgment as a universal severity formula.
Keep unsupported impact estimates out of the task title. If the consequence is uncertain, write that uncertainty in the row. Give related items a common question where that helps review, while preserving the separate evidence needed for each proposed change.
At the handoff, review what is accepted, what needs more investigation and what is outside scope. Use the task worksheet for a short record, and keep the underlying sources alongside it. Reopen an item when new evidence changes the question; do not treat the checklist as a permanent certificate of site health.