How to verify an SEO fix worked

A verification plan starts with a precise statement of the problem and intended change. “Improve SEO” is too broad to test. “The canonical on these product pages should point to the preferred indexable URL” is specific enough to inspect. Write the affected URLs, the current condition, the intended condition, the owner, the release dependency and the reason for the change. Record the before state before editing anything. Depending on the fix, that may include source HTML, rendered output, HTTP headers, crawl observations, indexation status, page content, internal links, Search Console rows or an analytics baseline. Keep the capture dated and reproducible. This is not bureaucracy. Without a baseline, a later state has no comparison. Without a precise intended state, a team can declare a ticket complete while the underlying issue remains. The initial brief should also state what the fix is not expected to change. That boundary helps avoid treating unrelated ranking movement as proof.

The comparison should use the same definition, scope and source wherever possible. If the issue was a missing title, compare the prior and current title on the affected pages. If it was indexation, inspect the relevant coverage or inspection state after allowing for processing time. If it was internal linking, compare the link relationship and crawl access rather than only page views. Preserve the original baseline; do not replace it with a new export. Where a direct comparison is impossible, explain the difference. Search data often has latency and noise. Use a realistic observation window and avoid selecting only a favourable day. For a content change, compare the target query and page signals with an appropriate pre-period, while noting other changes that occurred. For a technical change, the first proof may be a correct live response and later crawl observation, not an immediate ranking increase. “Before and after” describes a method of comparison, not a promise that every metric moves upward. It is valid to conclude that implementation is correct, outcome evidence is not yet available, or the hypothesis needs revision.

Keep the record short enough that it will be maintained. Include the issue, affected URLs, baseline source and date, intended change, release date, implementation result, observation window, outcome evidence, limitations and next action. Link to the relevant ticket or deployment where available. Name the person who performed the check and the source they used. If several changes landed together, state that attribution is limited. If the fix was rolled back, record the rollback state rather than leaving the task marked complete. The record should serve the next reviewer, not only the person who did the work. This is particularly important for agencies, distributed teams and migrations where context can be lost between recommendation and release. A consistent record also improves future prioritisation: repeated failures may reveal a template or process problem rather than isolated page issues. The point of verifying an SEO fix is not to produce another report. It is to make the next decision safer and more informed.

Do not use a single rank check to prove a broad change, because location, device, personalisation and normal result movement can alter the observation. Do not compare different page groups or date definitions without stating the difference. Do not treat an automated audit score as proof that the intended production state exists. Do not wait for traffic when the fix can already be checked directly in HTML or headers. Avoid changing the baseline after seeing the outcome, and avoid selecting only the queries or days that support the preferred story. These errors are usually process problems rather than bad intent. A written check established before release makes them less likely. When the available source is imperfect, label the limitation and narrow the claim. Useful proof is proportionate to the decision. A low-risk metadata correction needs a lighter record than a migration, but both need a clear before state, intended state and reviewer.