Editor Content Health Dashboard : A personalized, self-service governance view for every content editor in the CMS
As a content editor, I want to see a personalized dashboard when I log in to the CMS that shows me only the content I own that needs attention, so that I can find and fix issues myself, without waiting for someone else to tell me about them.
This dashboard replaces the generic default view in the CMS for all content editors. It does not replace any existing admin tools or reports. The intent is to move content governance from a reactive, admin-led activity into a proactive, editor-led habit. The dashboard is the trigger for that behavioural shift. This is a single story that covers the concept and requirements. If the team needs to break it into smaller stories per dashboard section for sprint planning, that is a valid approach, but the sections should be built as one coherent interface, not as separate standalone tools.
The problem we are solving
Today, the CMS shows every editor the same generic dashboard. It is not personalized, it does not show issues specific to that editor's content, and it gives no signal about whether the content they own is healthy or broken. The result is that content problems, broken links, outdated pages, unused media, unpublished drafts, go unnoticed for months or even years, until an admin, a customer complaint, or a site audit surfaces them. By that point the damage is already done.
With over 100 editors across our sites, we cannot rely on a central team or a CMS administrator to track and chase every editor about their content. That model does not scale. Governance needs to become a personal responsibility and for that to happen, editors need to be able to see their own issues at a glance the moment they log in.
Who this is for
This dashboard is for every person who creates, edits, or publishes content in the CMS. That includes marketing editors, regional content managers, product page owners, and campaign managers. It is not a tool for administrators - it is a tool that makes every individual editor their own first line of quality control.
What the editor needs to see
When an editor logs in, their dashboard should surface the content they personally created or own. (as per editor access rights applicable)
Broken and 404 pages
1. Pages I created that are currently returning a 404 error or are broken
2. Pages that have an incorrect redirect set up
3. Any pages I own that have no live URL and no redirect in place
4. Direct links to each page so I can go in and fix it immediately
Outdated content
1. Pages I own that have not been reviewed or updated in a defined period of time
2. A clear signal of how long it has been since the last update
3. The ability to mark a page as reviewed without making edits, if the content is still current
Unused images and media
1. Images and files I uploaded that are not currently used on any page
2. The file name, upload date, and file size so I can make an informed decision
3. A way to archive or delete unused files directly from the dashboard
Unpublished drafts
1. Pages I have started but never published
2. The last date I saved the draft, so I can identify ones that have been forgotten
3. A direct link to open the draft and either publish it or discard it
Expiring and review-due content
1. Pages where a review date or expiry date is approaching in the next 30 days
2. Pages where no review date has been set at all, flagged as a governance gap
3. The ability to extend a review date or set one if it is missing
Rule-Based Automation Layer (if possible)
Defined rules such as:
1. Draft older than 90 days → archive or notify owner
2. Redirect chains > 2 hops → auto-flag for cleanup
3. 404 URLs with traffic → auto-suggest redirect
4. Orphan pages (no inbound links) → flag or archive
What the editor does not need to see
The dashboard should not show content owned by other editors (exception for admins, site managers & super users). It should not show global site statistics. It should not require the editor to filter, search, or configure anything to get to their personal view. When they log in, their issues are the first thing they see.
Why this is a single solution, not multiple tools
We considered building separate reports for each of these issues. We decided against it. Separate reports mean editors have to remember to check multiple places. Most will not. A single dashboard that loads at login means the information finds the editor, the editor does not have to go looking for it. This also means one build, one place to maintain, and one consistent experience for all 100+ editors regardless of which site or market they work in.
Attached are vizualisation ideas- not anything we have as of today.