Original framework
The ICE-D prioritization framework
Use a short written rationale for each factor. A numeric score is optional and should never hide uncertainty.
Verify before prioritizing
A warning should enter the implementation backlog only after its behavior, scope and likely consequence are understood. Group repeated URLs by root cause so a template problem is not presented as hundreds of independent tasks.
Impact: connect the issue to a useful outcome
Estimate which indexable pages, customer journeys or measurement decisions could change. An issue affecting a high-value service template may matter more than a larger count of low-purpose URLs. State uncertainty rather than inventing revenue impact.
Confidence: grade the evidence
Confidence rises when the behavior is reproducible, the affected pattern is sampled properly and first-party evidence supports the diagnosis. It falls when a tool infers a problem without access to intent, production constraints or search-engine processing.
Effort: include the complete delivery cost
Consider investigation, design, engineering, content, stakeholder approval, regression testing and deployment—not only the code change. A technically simple fix can still be expensive when it affects regulated content or many teams.
Dependency: make sequence visible
Identify work that blocks or changes another recommendation. A URL design decision should usually precede redirect mapping; a stable form-success event should precede campaign reporting; a template fix may precede page-by-page cleanup.
Turn priority into an executable roadmap
For each approved item, record an owner, due window, dependencies, acceptance criteria and QA method. Keep low-confidence hypotheses in an investigation queue rather than presenting them as committed fixes.
Why a single score can mislead
Multiplying four estimates can create false precision. Use ranges or simple labels when appropriate, retain the written rationale and revisit priority when evidence, platform constraints or commercial goals change.