Gwenllian.PEditor
SEO projects involve many small decisions about content, URLs, technical changes and priorities. Months later, teams may remember the outcome but not the reason. A lightweight decision log preserves that context without requiring a full project-management record of every conversation. For a small UK agency, such a log can protect continuity when an account manager leaves, a website changes platforms or a client asks why a particular page was consolidated. The useful record is not a transcript of meetings. It shows the choice made, the evidence and constraints behind it, who had authority to approve it, and what would justify revisiting it.
Record decisions that affect future work
Focus on choices likely to matter later: retaining a URL, delaying a migration, changing a service-page structure or accepting a known limitation. Routine approvals that have no lasting consequence do not need to fill the log.
A decision has a consequence beyond the moment in which it was made. A client might choose to preserve a long-standing service URL rather than rename it for a new keyword. A content owner may authorise combining two overlapping guides, which means the team must preserve useful information and test an approved redirect. A technical owner may decide that a canonical rule belongs in a shared template rather than individual records. Each choice will shape future work and could be misunderstood after staff changes. Those are reasonable candidates for documentation.
Distinguish these choices from ordinary operational updates. A draft entering review, an article's spelling correction or a meeting being rescheduled generally belongs in the relevant workflow system, not necessarily in a permanent decision log. Record a decision when understanding the reason will help a future person maintain, reverse or assess the result. This simple filter prevents the log from becoming an exhaustive timeline that nobody reads.
Capture the reason as well as the outcome
A note that says 'client chose option B' is less useful than a concise explanation of the constraint or trade-off behind the choice. Future teams can then understand whether the original reasoning still applies when circumstances change.
Use a compact entry: decision identifier, date, affected URL or project, issue, options considered, evidence available, selected approach, deciding owner, dependencies and review trigger. The rationale should explain the meaningful compromise. Perhaps the team retained an existing page because it already answered the reader's question and a new article would duplicate it. Perhaps an old page was retired because its service ended and no relevant successor existed. A short reason allows another editor to evaluate the choice without guessing from the outcome alone.
Do not inflate the record with invented precision. If the team expected a potential usability benefit but had no measurement, say it was a reasoned expectation, not a verified improvement. If a decision was driven by client preference, record that honestly. The purpose is a faithful account, not a persuasive document retroactively proving the chosen option was inevitable.
Distinguish evidence from preference
Where a decision reflects available data, technical constraints or brand preference, label that context clearly. This prevents later readers from treating a stakeholder preference as though it were a proven SEO requirement.
A client's preference for a shorter menu may be sensible but is not evidence that Google rewards that exact number of navigation links. A decision to use a permanent redirect can be supported by the real relationship between old and new resources and by Google's site-move documentation, but that guidance does not guarantee all historic rankings transfer. A verified broken form is direct evidence of a customer-journey problem; a proposed keyword opportunity may remain speculative. Keep these categories distinct.
When Search Console figures influence a decision, record the property, date range and relevant filters. Clicks, impressions and average positions have product-specific meanings; they are not automatically qualified leads or sales. If a chart is sparse or affected by a site release, say so. Avoid treating a third-party audit's risk label as an objective requirement without checking the underlying public behaviour. Evidence quality belongs in the log because a decision made under uncertainty may deserve reassessment when better information becomes available.
Link to supporting material where needed
Complex decisions may rely on an audit, redirect map or design specification. Reference the relevant project material instead of copying large amounts into the log. The decision record should remain concise enough to scan.
A content consolidation may need a link to the approved old-to-new URL map and a list of valuable material retained. A migration decision could reference the site's inventory and the deployment plan. A technical ticket should contain detailed reproduction steps and acceptance tests; the decision log needs only the choice and its rationale, with a pointer to that ticket. This separation avoids two parallel documents that drift into contradictory instructions.
Protect private information in linked records. A decision log may be shared with business owners and incoming contractors, while incident records could contain sensitive technical observations or personal customer information. Use permission-controlled references and avoid pasting passwords, raw logs or identifiable enquiries into a broadly accessible document. The UK's ICO data-minimisation guidance explains relevant principles for proportional processing of personal information, subject to the organisation's obligations.
Use the log during handovers and reviews
When staff change or a client moves provider, the log can explain why the site looks the way it does. It also helps recurring reviews identify decisions that should be reconsidered because the original constraint has disappeared.
Imagine a new account manager asks why no separate page exists for one local town. The log might show that the business had no distinct conditions for that area and chose a regional coverage page rather than near-duplicate local content. If operations later introduces genuine service differences, the decision can be reconsidered with new evidence. Without the record, another team may rebuild the same redundant pages and incur repeated writing and maintenance costs.
Review open decisions before a major redesign or content clean-up. A deferred technical repair might have depended on an unavailable developer who is now available. A migration choice might need revision after the site changed hosting provider. A retained article might have become obsolete because its product disappeared. The log should make it easy to recognise these triggers. It should not preserve a past decision as permanent law when the facts have changed.
Keep ownership simple
Choose one shared location and make the project lead responsible for capturing material decisions. A lightweight habit is more sustainable than a complicated approval system. The log succeeds when people can trust it to explain important choices later.
Define who can propose a decision, who can approve its effects and who maintains the entry. An agency strategist may recommend content consolidation, but an authorised client subject owner should verify factual service implications. A developer may advise on redirect implementation but not unilaterally choose a commercially misleading successor. A publishing owner can confirm an approved article was saved, while public QA must still establish that the frontend displays it as intended. One person may fill several roles in a small team; the approvals should remain understandable.
Make entries easy to find using a stable identifier and exact affected URLs where relevant. Avoid unnecessary elaborate taxonomy. A few dependable fields are better than dozens that are often left blank. When the project lead changes, include the log in the handover and verify that the new owner has legitimate access. This keeps organisational memory available without depending on a former employee's private inbox.
Record alternatives without turning the log into an argument
A useful decision shows meaningful alternatives and why the selected one was appropriate at the time. The entry does not need to prove the rejected choice was foolish. Several options can be legitimate under different conditions. A business might retain a URL because no change in content identity warranted migration, while another business might move the resource to a necessary new structure and implement relevant redirects. Explain the context rather than declaring one practice universally superior.
For content, alternatives might include refreshing a guide, consolidating overlap or commissioning a new specialist page. Record the distinct reader questions and source evidence behind the choice. For access management, alternatives might involve restricted delegated permissions versus broad administrator rights; note the actual task and owner approval. Never invent a guarantee of ranking or commercial return to rationalise one option. The decision log should support future judgement rather than become a collection of post-hoc sales pitches.
Make status and acceptance independent
A critical difference is between a decision being approved and its intended action being implemented. A client might approve a redirect map, but the deployment could remain pending. A technical correction might be committed to the repository yet fail on the public site. A CMS update may persist in the database while the frontend cache serves the previous version. The decision log should not collapse those into one word such as 'completed'.
Reference the implementation ticket and its acceptance evidence where the decision results in a website change. For a redirected article, the reviewer should test the old public URL and its relevant final page. For a content update, the live title, H1, source links, image, comparison and FAQ should render correctly. For a contact form, an authorised test submission should reach the intended system. Keep blocked public checks open instead of claiming a full pass based solely on a native database READ-BACK. This distinction lets clients understand what was agreed versus what was proven to work.
Review unresolved decisions proportionately
A decision log should not replace the work backlog. The backlog describes tasks, evidence and current action; the log describes consequential choices and rationales. Connect the two only where necessary. An item awaiting factual approval belongs in the work queue; once the responsible client makes a consequential choice, a short log entry preserves the reason.
At a monthly review, inspect decisions with approaching deadlines or changed dependencies. Avoid rereading every historic entry. If an earlier decision is overturned, create a dated revision or superseding entry that preserves the old rationale. Do not silently overwrite the past, because a future reviewer may need to understand why an old URL or process existed for a period. Clearly identify the current decision without leaving conflicting active instructions.
Use the log to improve client communication
When clients disagree with an agency recommendation, a clear account of evidence, trade-offs and authority can reduce confusion. It makes it possible to say, 'We reviewed a separate local page, but the company had not confirmed a distinct service offer,' rather than presenting the refusal as an arbitrary SEO rule. It also allows a client to request a different option with explicit understanding of its implications.
Keep language neutral and suitable for handover. Avoid characterising people as unreasonable or using private comments to record blame. A decision log should not publish internal deliberation as a customer-facing article. Protect restricted review notes and separate any approved public editor information from confidential workflow records. The best entry can be understood by somebody who did not attend the meeting.
Measure the log by clarity, not its size
Review whether a new colleague can understand an important page or technical choice using the entry and its supporting links. If the answer is no, the rationale may need a clearer explanation. If the document contains hundreds of trivial comments and duplicate statuses, reduce scope so it remains useful. An effective log prevents repeated investigations, lost approvals and contradictory decisions; it need not accumulate a large number of entries to achieve that.
Good documentation respects uncertainty. It shows which facts were available, what the team preferred and why, and what future changes could warrant a new choice. That allows an SEO programme to adapt as content, business offerings and technical systems evolve without rewriting its history. A concise, accurate client decision log is therefore a practical maintenance tool: it preserves the reasons behind consequential choices while leaving implementation and public acceptance to the systems that can actually verify them.