Separate a review occurrence from an action
A recurring SEO review is an appointment to examine evidence, not an instruction to create another copy of every unresolved task. Keep a review log separate from the action register. A review occurrence records when someone checked a defined scope; an action records a specific change that someone must make.
Before starting, collect the existing open, blocked and recently completed actions for the same site. Give the review a period and an owner, then record which sources were available. An unavailable report should produce an evidence gap, not a confident conclusion that all problems disappeared. Preserve the previous observation until a new check can actually replace it.
Match the finding before creating a task
Define a practical matching key from the site identity, affected page or shared component, and observed problem. For example, a broken navigation destination affecting twenty pages may belong to one navigation repair task with twenty affected URLs. Twenty independent page defects may require separate actions. A similar title alone is not enough to decide.
Search the action register using that key and inspect the linked evidence. If an open task already addresses the same change, append the new observation and update its last-seen date. Keep its original creation date and owner. If the new finding requires a different fix or affects a different site, create a separate task and explain the relationship.
Give every comparison a clear outcome
Use four explicit outcomes: new action, existing action updated, completed action reopened, or no action with a reason. Reopen a completed action only when current evidence shows that its agreed condition has returned. A delayed report showing an older state should be attached as historical evidence, not treated automatically as a regression.
For blocked work, record the dependency and next review trigger rather than creating a second task with a new due date. If the evidence changes the severity, explain why and notify the responsible person through the team’s agreed process. A silent date reset makes an overdue issue look new and hides how long it has remained unresolved.
Worked example: a repeated broken link
Illustrative example: Monday’s review creates NAV-14 for a broken footer link. Friday’s review finds the same destination still broken across the same template. The reviewer adds Friday’s checked URLs to NAV-14, retains Monday’s creation date and notes that the implementation is awaiting approval. The queue still contains one repair task.
After a verified fix, a later deployment restores the incorrect destination. A fresh check confirms the failure and the reviewer reopens NAV-14 with the deployment reference. If the later error instead affects a separate campaign page with its own link, they create a distinct task. These are workflow examples, not measured customer outcomes.
Close the review without manufacturing progress
Finish each occurrence with counts of new, updated, reopened and unchanged actions, plus unresolved evidence gaps. A week with zero new tasks can still be a completed review. Verify that each new action has a unique reason to exist and that repeated evidence points to an existing record instead of a second owner doing the same work.
Choose review frequency according to site changes and operational needs. Google says Search Console does not require daily visits and suggests checks around monthly or after content changes; this is not a universal incident-response schedule. When reviewing SEO Growth Assistant recommendations, compare them with your action register before assigning work. This procedure does not assume automatic deduplication by the product.