Imagine opening your WordPress dashboard two years from now.
You notice two old articles were merged.
Why?
You remember doing it.
But you don't remember whether the reason was:
content cannibalization,
outdated information,
low traffic,
duplicate search intent,
or:
a better reader experience.
Then you find an affiliate product you stopped recommending.
Why?
Was the product discontinued?
Did its pricing change?
Did you find a better alternative?
Did the affiliate program close?
Was the recommendation no longer right for your audience?
Next, you notice your Blueprint categories were reorganized.
Again:
Why?
This is a different problem from version control.
Version control tells you:
What changed?
A decision log tells you:
Why did we choose to change it?
That distinction becomes increasingly important as a blog grows.
If you're new to the Blogging Success Blueprint, start here:
👉 Blogging Success Blueprint Part 1
And for the traffic foundation:
👉 Blogging Success Blueprint Part 2: Get Blog Traffic
Step 1: Understand What a Content Decision Log Is
A content decision log is a simple record of important editorial or business decisions affecting your content.
It captures:
the decision
the problem
the evidence available
the alternatives considered
the reasoning
the expected result
the date
and, where useful:
when to review the decision again.
Think:
Problem
⬇️
Evidence
⬇️
Options
⬇️
Decision
⬇️
Reason
⬇️
Outcome
That's the basic system.
Step 2: Don't Record Every Tiny Choice
You don't need an entry saying:
“Changed heading from H3 to H2.”
Nor:
“Moved paragraph three above paragraph four.”
A decision log isn't supposed to become an administrative burden.
Record decisions that future you might reasonably ask:
“Why did I do that?”
That's the threshold.
The Future-You Test
Before creating a decision record, ask:
Will this affect multiple articles?
Could it affect traffic or revenue?
Is it difficult to reverse?
Does it change an established strategy?
Could I forget why I made this choice?
Might I need to evaluate the outcome later?
If several answers are yes, log it.
Step 3: Give Every Important Decision an ID
You can keep this simple.
For example:
DEC-001
DEC-002
DEC-003
Now you can reference decisions elsewhere.
For example:
Version 2.0 created because of DEC-014.
Or:
Articles merged under DEC-027.
This begins connecting the systems we've built recently.
Step 4: Record the Decision Date
Context matters.
A perfectly reasonable decision in 2026 may no longer be appropriate in 2028.
Record:
Decision Date: October 2026
Now future you understands when the reasoning applied.
Step 5: Describe the Problem Before the Solution
Don't begin with:
“We're merging these articles.”
Start with:
“These two articles appear to address substantially the same reader intent and cover overlapping material.”
That's the problem.
Then investigate.
Separating:
Problem
from:
Solution
reduces the risk of deciding what you want to do before understanding why.
Step 6: Record the Evidence
Suppose you're considering merging two posts.
Evidence might include:
search-query overlap
similar article purpose
similar ranking terms
reader confusion
internal-link ambiguity
duplicate sections
and:
performance history.
Record the evidence that mattered.
Then future you can see whether the decision was grounded in actual signals or merely intuition.
Step 7: Separate Evidence From Assumptions
Suppose:
Evidence: Both pages receive impressions for many of the same queries.
That's observable.
But:
Assumption: Combining the pages may produce a clearer resource.
That's a prediction.
Keep those separate.
A useful decision record distinguishes:
What we know
from:
What we expect.
Step 8: Record Alternatives
This is one of the most useful parts of a decision log.
Instead of recording only:
“Merge Article A and Article B.”
record the alternatives:
Option A — Keep both unchanged
Option B — Differentiate their intent
Option C — Merge them
Option D — Redirect one
Then record why you chose one.
This prevents the final decision from looking inevitable when it wasn't.
Step 9: Record Why You Rejected Alternatives
Suppose you reject differentiation.
Why?
Maybe:
“The two pages don't have sufficiently distinct reader purposes to justify maintaining both.”
That reasoning matters.
Otherwise, someone—including future you—may later propose the exact same rejected idea.
The decision log saves that history.
The Decision Record
A simple entry might look like:
Decision ID: DEC-021
Date: October 2026
Problem: Two articles substantially overlap.
Evidence: Similar search intent, repeated sections, reader navigation ambiguity.
Options: Keep / Differentiate / Merge.
Decision: Merge.
Reason: One comprehensive resource appears more useful than maintaining two overlapping pages.
Expected Result: Clearer reader journey and simpler maintenance.
Review Date: January 2027.
That's enough.
Step 10: Record Expected Outcomes
Every strategic decision contains an expectation.
Write it down.
For example:
“We expect the new Blueprint Hub structure to make it easier for readers to locate resources by stage.”
Later, you can ask:
Did it?
Without an expected outcome, evaluation becomes vague.
Step 11: Don't Rewrite Your Expectations After the Result
This is subtle but important.
Suppose you predict:
“This new CTA may increase relevant email signups.”
Three months later, signups don't change.
Don't rewrite the original decision log to say:
“The purpose was never to improve signups.”
Keep the original expectation.
Then document what actually happened.
That's how a decision log becomes a learning tool.
Step 12: Add an Outcome Field
After enough time passes, record:
Worked as expected
Partially worked
No meaningful change
Unexpected result
Decision reversed
or:
Insufficient evidence
Don't force every decision into success or failure.
Sometimes the evidence simply isn't strong enough.
Step 13: Record Reversals
Changing your mind isn't a failure.
Suppose you create a new content category.
Six months later, you discover it:
confuses readers
duplicates another category
and:
contains only four articles.
You remove it.
Record:
DEC-042 supersedes DEC-019.
Now the history makes sense.
Decision Evolution
Think:
Decision 1
⬇️
Observed Outcome
⬇️
New Evidence
⬇️
Decision 2
⬇️
Improved Strategy
Good strategy evolves.
The decision log shows how.
Step 14: Connect Decisions to Content Experiments
Some decisions should become experiments.
Suppose feedback suggests:
Readers don't understand which Blueprint to read next.
Potential decision:
Test a goal-based “Read Next” block.
Record:
problem
hypothesis
change
primary metric
timeframe
result
and:
decision afterward.
Now experimentation becomes part of editorial reasoning.
Step 15: Don't Pretend Every Decision Is an Experiment
Some changes shouldn't wait for testing.
If a reader identifies:
a materially incorrect factual statement,
the appropriate action is to investigate and correct it if confirmed.
Accuracy isn't something you A/B test against misinformation.
Similarly, accessibility barriers and broken functionality may require direct fixes.
Use experiments where genuine uncertainty exists—not where basic correctness is the issue.
Step 16: Log Major SEO Decisions
SEO decisions can be surprisingly difficult to reconstruct later.
Record important choices such as:
merging pages
changing search intent
changing URL structure
redirecting important pages
rebuilding pillar pages
changing internal-link architecture
and:
reorganizing taxonomy.
Then if performance changes later, you have context.
Step 17: Avoid Post-Hoc SEO Stories
Suppose traffic rises after a decision.
Don't automatically record:
“Decision caused traffic increase.”
Record:
“Traffic increased after the change.”
Then evaluate other possible factors.
Search visibility changes for many reasons.
The decision log should preserve evidence—not manufacture certainty.
Step 18: Log Affiliate Decisions
Suppose you stop recommending Product A.
Record why.
Possible reasons:
product changed
better alternative became available
pricing became less competitive
reader needs changed
important feature disappeared
affiliate relationship ended
or:
your evaluation changed.
That's useful editorial history.
Step 19: Keep Affiliate Compensation Separate From Recommendation Quality
Your log might record:
Affiliate Program: Active
but:
Editorial Decision: No longer recommended for this use case.
That's okay.
A product shouldn't remain recommended merely because it pays commission.
Similarly, a product shouldn't automatically be rejected simply because it has no affiliate program.
The recommendation should serve the reader.
Step 20: Log Tool-Building Decisions
Remember our Interactive Blog Tools Blueprint?
Suppose you consider building:
SEO Difficulty Calculator.
After investigation, you decide:
Don't build it.
Why?
Maybe you conclude the output would create:
false precision
unsupported scoring
or:
more complexity than reader value.
Record that.
A decision not to build something can be just as valuable as a decision to build it.
The “We Decided Not To” Library
Over time, maintain records of ideas you deliberately rejected.
Examples:
Didn't build tool because methodology wasn't defensible.
Didn't create category because taxonomy would become too fragmented.
Didn't publish survey because sample was too weak for intended claims.
Didn't recommend product because it wasn't relevant enough.
This prevents bad ideas from repeatedly returning as “new” ideas.
Step 21: Log Taxonomy Decisions
Our Blog Taxonomy Blueprint is perfect for this.
Suppose we eventually organize the Blueprint into:
Foundation
Content
SEO & Discovery
Traffic & Distribution
Audience
Monetization
Authority
Scale
Record why.
Then if we later consider:
Should Traffic and SEO become one category?
we can review the original reasoning before changing anything.
Step 22: Log Knowledge-Graph Decisions
Our knowledge graph requires controlled relationships.
Suppose we decide:
Use “supports”
but not:
helps
strengthens
enhances
and:
assists
as separate relationship types.
Record why:
“Reducing synonymous relationship labels makes the graph easier to maintain.”
Now future expansion remains consistent.
Step 23: Log Content-Provenance Decisions
Suppose we decide:
Statistics require source tracking, but ordinary editorial advice generally doesn't.
Record that standard.
Then future Blueprint articles can apply it consistently.
This is how editorial policies emerge from decisions.
Step 24: Log Version-Control Decisions
Suppose we decide:
Major methodology changes trigger a new major version.
Record the rule.
Then:
Tool A
Framework B
and:
Research Report C
can follow the same principle.
Consistency becomes easier.
Step 25: Log Portability Decisions
Suppose you decide:
Every original research dataset should have a separate protected copy outside the publishing system.
Record:
why
where
format
and:
review schedule.
Now portability becomes policy rather than a vague intention.
Step 26: Turn Reader Feedback Into Decisions
Yesterday we created:
Reader Feedback
⬇️
Classification
⬇️
Pattern
Now add:
Pattern
⬇️
Decision
For example:
Feedback: Readers repeatedly ask where to begin.
Evidence: 37 similar questions across email and comments.
Decision: Build a Start Here section in the Blueprint Hub.
Now reader feedback has a documented outcome.
Step 27: Tell Readers When Feedback Produces a Change
This can be powerful.
Suppose multiple readers report:
“The calculator explanation is confusing.”
You improve it.
You might say:
“We've clarified this section based on reader feedback.”
That shows readers their feedback matters.
Don't identify people without permission.
But acknowledging collective feedback can strengthen the relationship.
Step 28: Connect Decisions to Sources
Our provenance system tracks evidence.
Now:
Source
→ supports →
Claim
→ influences →
Decision
For example:
Reader Survey
→ reveals →
Navigation Confusion
→ influences →
Blueprint Hub Redesign
That's a traceable reasoning chain.
Step 29: Connect Decisions to Versions
Our Version Control Blueprint tracks changes.
Now:
Decision DEC-027
→ creates →
Article Version 2.0
If you later ask:
“Why was Version 2.0 created?”
you can trace it directly to the decision.
Step 30: Connect Decisions to Outcomes
Complete the chain:
Evidence
⬇️
Decision
⬇️
Change
⬇️
Version
⬇️
Outcome
⬇️
Learning
⬇️
Future Decision
Now your blog learns from itself.
The Blueprint Decision Ledger
A simple spreadsheet could contain:
Decision ID
Date
Area
Problem
Evidence
Options
Decision
Reason
Expected Outcome
Related Content
Review Date
Actual Outcome
Status
Superseded By
That's enough to build an institutional memory.
Decision Categories
Use categories such as:
CONTENT
SEO
AUDIENCE
MONETIZATION
AFFILIATE
RESEARCH
TOOL
UX
ACCESSIBILITY
TAXONOMY
TECHNICAL
BRAND
MAINTENANCE
Then you can filter the history.
Decision Status
Use:
ACTIVE
Still the current decision.
REVIEW
Needs reevaluation.
SUPERSEDED
Replaced by a newer decision.
REVERSED
Deliberately undone.
EXPERIMENTAL
Being tested.
COMPLETED
One-time decision implemented.
Simple status labels keep the log manageable.
The Decision Confidence Label
For selected decisions, you might also record:
HIGH CONFIDENCE
Strong evidence.
MODERATE CONFIDENCE
Reasonable evidence but uncertainty remains.
LOW CONFIDENCE
Best available judgment with limited evidence.
This isn't a scientific score.
It's an internal reminder of uncertainty.
A low-confidence decision may deserve earlier review.
The Reversible Decision Principle
Some decisions are easy to reverse.
Others aren't.
Changing:
a CTA label
is relatively easy to undo.
Changing:
hundreds of URLs
can be much more disruptive.
The harder a decision is to reverse, the more careful the documentation should generally become.
The Decision Cost Matrix
Think about two dimensions:
IMPACT
How much could this affect?
REVERSIBILITY
How difficult is it to undo?
Then:
HIGH IMPACT + HARD TO REVERSE
Document carefully.
HIGH IMPACT + EASY TO REVERSE
Consider testing where appropriate.
LOW IMPACT + HARD TO REVERSE
Question whether the change is worth it.
LOW IMPACT + EASY TO REVERSE
Keep the process lightweight.
This helps prevent bureaucracy.
The Decision Review System
Not every decision needs permanent review.
But some do.
For example:
30 DAYS
Short experiment.
90 DAYS
Editorial or conversion change.
6 MONTHS
Taxonomy or navigation decision.
ANNUALLY
Portability, major platform, and structural decisions.
These are examples—not universal rules.
Set review timing based on the decision.
The Decision Review Question
When the review date arrives, ask:
Did the expected outcome occur?
What changed?
What did we learn?
Did any assumptions prove wrong?
Has new evidence appeared?
Is the decision still appropriate?
Then choose:
KEEP
MODIFY
REVERSE
REPLACE
or:
CONTINUE OBSERVING.
Decision Logs and Email Strategy
Suppose reader feedback suggests subscribers want more beginner material.
You decide to create a beginner-focused email sequence.
Record:
feedback evidence
reason
sequence objective
and:
expected outcome.
Then build the relationship through your email platform.
Later, evaluate the decision using appropriate engagement and conversion signals rather than assuming the sequence worked merely because it was created.
Decision Logs and AI
AI can help summarize:
evidence
alternatives
previous decisions
and:
possible consequences.
But don't let AI quietly make important editorial decisions without recording the human reasoning.
For example:
AI might suggest:
“Delete 100 low-traffic articles.”
That's not enough.
You still need to consider:
accuracy
reader usefulness
backlinks
conversions
strategic role
historical value
internal links
and:
search intent.
AI can assist analysis.
The decision remains yours.
Avoid Decision Theater
A decision log can become useless if every entry says:
“We chose this because it seemed best.”
That's not documentation.
Record enough reasoning to make the decision understandable.
But don't write an essay for every choice.
The objective is:
Useful memory.
Not paperwork.
The Five-Minute Decision Record
For most decisions, five minutes should be enough.
Record:
What are we deciding?
Why now?
What evidence matters?
What alternatives exist?
What did we choose?
Why?
What do we expect?
When will we review it?
Done.
The Content Decision Scorecard
Periodically ask:
Are major editorial choices documented?
Can we distinguish evidence from assumptions?
Do we record alternatives?
Do we explain why alternatives were rejected?
Do important decisions have expected outcomes?
Are review dates used where appropriate?
Can decisions connect to content versions?
Can decisions connect to reader feedback?
Can we see which decisions were reversed?
Can we identify superseded decisions?
Are affiliate decisions editorially independent?
Are AI suggestions being reviewed rather than automatically accepted?
If yes, you're building real editorial memory.
The Content Decision Flywheel
Here's the complete system:
Observe
⬇️
Identify Problem
⬇️
Gather Evidence
⬇️
Consider Alternatives
⬇️
Decide
⬇️
Document Reason
⬇️
Implement
⬇️
Measure
⬇️
Review Outcome
⬇️
Capture Learning
⬇️
Improve Future Decisions
⬇️
Repeat
The value compounds because future decisions begin with the lessons from previous ones.
The Blueprint Editorial Memory Stack
Look at what we've built recently:
READER FEEDBACK
What are readers telling us?
⬇️
CONTENT PROVENANCE
Where did our evidence come from?
⬇️
DECISION LOG
Why did we choose this action?
⬇️
VERSION CONTROL
What did we change?
⬇️
CONTENT DECAY DETECTION
When should we investigate again?
⬇️
KNOWLEDGE GRAPH
What else is affected?
⬇️
CONTENT PORTABILITY
Can we preserve the system?
This is becoming much bigger than a posting schedule.
It's an editorial intelligence system.
The Rule to Remember
Our most recent Blueprint progression becomes:
Reader Feedback System
Don't only measure what readers do—create ways to hear what they still need.
Content Decision Log
Don't only remember what you changed—preserve why you decided to change it.
That's today's shift.
Final Thoughts
Blogging produces hundreds of decisions.
Most disappear.
You remember the result but forget the reasoning.
Then months later you revisit the same problem and start from zero.
A decision log changes that.
You can remember:
what problem you were solving
what evidence you had
what alternatives you considered
what you chose
why you chose it
what you expected
and:
what actually happened.
That creates something most blogs don't intentionally preserve:
Editorial memory.
And editorial memory can improve future judgment.
Not because every previous decision was correct.
But because every documented decision can teach you something.
Don't just preserve your content.
Preserve the reasoning that shaped it.
Discover more from The Blogger's Guide to Marketing
Subscribe to get the latest posts sent to your email.