Alistair.PEditor
Website projects often contain SEO risks that are known long before they become problems: missing redirect decisions, delayed content, uncertain access or untested templates. A simple risk register makes those uncertainties visible while there is still time to act. The register should tell a small UK agency and its client what might go wrong, which decision would reduce the exposure and who will check the result. It is not a prediction of lost rankings or a document designed to make routine work look more dangerous. The most valuable entry is specific enough to affect an actual project decision.
Record specific risks rather than general worries
Describe the event that could occur and the area it would affect. 'SEO may drop' is too vague; a missing redirect map for changing URLs is concrete enough to assign and manage. A useful entry states a condition, plausible consequence and point at which action is required. For instance: 'If the redesign removes established service URLs without approved successor mappings, visitors following saved links may reach missing or irrelevant pages.' That sentence exposes an action the team can actually take: compile the affected URLs and approve destinations before release.
Other risks are about factual integrity or coordination rather than technical routing. A writer might publish an unsupported service claim because the operational approver is unavailable. A developer might deploy a template containing a staging noindex rule. An analytics property could remain under a former supplier's control, preventing authorised checks after launch. Keep these distinct: one is a content-governance problem, another a configuration problem, and the third an account-control dependency. The register should not turn all of them into a generic 'SEO risk'. Record which exact resource or group might be affected, what is known and what is still only an assumption.
Separate likelihood from consequence
A problem can be unlikely but serious, or common but minor. Considering both helps the team focus attention without pretending to calculate precision it does not have. Plain categories can be sufficient for smaller projects. Assess likelihood using available evidence about the project, and consequence by the actual customer task threatened. A critical enquiry page becoming inaccessible may have more direct business consequence than an obsolete article losing a decorative image, even where neither has a defensible numeric probability.
Risk matrices should not automatically manufacture probability percentages or financial losses. If the team has no measured basis for '70% likely' or a precise revenue figure, say 'possible, pending test' and identify how confidence could be improved. Consider breadth: a single faulty link on a rarely used archive page differs from a shared template setting affecting all active services. Record why severity was selected, not merely a red symbol. Reassess after testing; a feared deployment defect may become unlikely once a comprehensive staging check and rollback procedure exist. Where a real privacy or security exposure is suspected, use the client's authorised incident process rather than burying it under an ordinary marketing score.
Assign an owner to each material risk
The owner is responsible for ensuring the risk is addressed or monitored, not necessarily for doing every task. Ownership prevents known issues from sitting between agency, developer and client responsibilities. For a migration, an editorial owner may decide whether a new page is a meaningful successor while an engineer owns implementation. For service claims, the client must verify actual eligibility; the writer cannot grant themselves that authority. For measurement access, an authorised property owner may have to add the appropriate user.
Record the decision owner, action owner and review date separately when they differ. Do not assume a project manager can change server configuration simply because the risk register lists their name. The register should show what escalation occurs if an approval is missing at the release gate. One person may fill several roles in a very small organisation, but evidence of factual approval and public technical acceptance should remain distinct. Avoid placing administrator credentials or customer records in the register. A named access requirement is sufficient for planning, with secrets managed through secure authorised systems.
Define a practical mitigation
Record what would reduce the likelihood or consequence, such as completing a URL inventory, securing access or scheduling a pre-launch review. Mitigation should be actionable rather than simply restating the risk. A weak entry says 'avoid redirect errors'; a stronger one requires an approved old-to-new URL map, a test of relevant server responses and a named owner to correct exceptions. Google's site-move guidance describes URL mapping, permanent redirects and migration monitoring. It does not certify the client's intended map or guarantee that rankings remain unchanged.
Separate preventive action from a contingency plan. Prevention might mean reviewing a staging site's robots directives before deployment. The contingency is what happens if the live site unexpectedly emits noindex or blocks access after release: who can verify the change, authorise a correction, deploy safely and communicate the incident? The same distinction helps with content risk. A subject reviewer can check a service description before publication, while a rollback process can remove a discovered misleading claim from the public template. Assign evidence for each action so the team can tell whether mitigation was performed rather than merely scheduled.
Update risks when the project changes
Close items that are resolved and add new ones when scope or implementation changes. A static risk register created at kickoff quickly becomes irrelevant and can give false confidence that current issues are covered. Review the current state at meaningful project checkpoints: completion of the URL map, approval of major content, staging sign-off, production launch and material releases afterwards. Do not demand a lengthy meeting for every small edit; update entries when a new fact changes the decision.
Keep observed problems separate from future risks. Once the launch has actually broken a contact route, the issue is no longer a hypothetical failure: it needs an incident or defect ticket with reproduction steps, owner and acceptance test. Retain the risk entry as context, but do not continue describing the active problem as merely something that might happen. Conversely, a risk can close when the relevant verification passes, without asserting that all site behaviour has been tested. An entry about a subset of URLs must not become an unsupported declaration that the entire migration is safe.
Use the register to support decisions
Bring material open risks into project reviews when they require a trade-off or escalation. The register should help people decide what to do, not become a document maintained solely because project governance says one should exist. A release may be postponed until an essential form is tested, whilst a minor image alignment issue can receive an agreed later owner. These are editorial and delivery judgements, not universal SEO rules. Record what was approved, the evidence available and who accepted any remaining limitation.
Keep a short decision-ready view: the risk, potential customer consequence, current evidence, mitigation, owner, next check and release implication. Where the options involve changing established URLs or removing content, involve the people who know the original reader purpose. A redirect that technically reaches the homepage may still fail to answer the old visitor's question. A new service claim may be persuasive but inaccurate. The purpose of the review is to resolve such uncertainties with appropriate facts before launch, not merely report a count of green rows.
Verify mitigation and maintain an honest close-out
A successful database update, completed ticket or staging screenshot is not proof of a public result. For high-consequence changes, check the real production response and customer journey when authorised browser and server tools are available. Verify old-to-new redirects, canonical signals, meaningful content, image loading, forms and representative narrow-screen layouts as appropriate to the risk. Distinguish a prepared mitigation, implemented configuration and independently checked result. If a public route is inaccessible from a testing environment, document that limitation without declaring the site failed or passed.
Close each entry with a factual outcome: the accepted mitigation, test date and remaining exception. A risk that was accepted rather than eliminated should remain understandable to the next account or development owner. The register then becomes a short record of responsible project choices, not evidence of guaranteed search growth. Its value lies in letting the team anticipate consequential failures, make timely approvals and demonstrate what was genuinely verified, while preserving uncertainty where evidence is incomplete.