How to manage content during a government website consolidation
When the NSW OneCX Program moves an agency to nsw.gov.au, the technical work is visible: URLs redirected, CMS configured, pages moved. What's less visible is the content design work that determines whether those pages are actually useful when they land.
Most government consolidation projects treat content as a migration task. It is a design problem.
In the ACT Government consolidations I led, we often reduced content by 90% before consolidating into act.gov.au. That wasn't a technical outcome. It was the result of thousands of deliberate content decisions: what to keep, what to merge, what to retire, and what to rewrite.
This guide is for content practitioners and digital leads managing a consolidation project. It covers the content design decisions that determine whether the consolidated site is genuinely better than what it replaced.
What you will need before you start
A full list of current URLs (from a site crawl or CMS export)
Analytics data: at minimum, page view figures for the last 12 months
A content decision framework your stakeholders have agreed to
At least one person with clear authority to retire content
Without that last one, the process will stall. Consolidation projects fail when everyone can approve migration but nobody can approve retirement.
Step 1: Audit before you move anything
A content audit is not a content inventory. An inventory lists what exists. An audit assesses what is worth keeping.
Run the audit before migration planning begins. For each piece of content, assess:
Task relevance: Is this supporting a real user task that still exists?
Accuracy: Is it current, correct, and not contradicted by other content?
Duplication: Does the same information exist elsewhere? Which version is better?
Ownership: Is there an accountable owner who will maintain this post-migration?
A page with fewer than 100 views in 12 months and no legal requirement is a candidate for retirement, not migration.
Agencies will consistently argue for migrating everything because the minister might need it. Migrate-everything is a risk avoidance strategy that transfers cluttered, outdated content from an old site to a new one and adds to the cost of maintaining it.
Step 2: Establish content tiers
Not all content needs the same level of attention. Establish a tiering framework before migration begins so decisions are predictable and stakeholders know what to expect.
Tier 1: Migrate and uplift. High-traffic, task-critical pages. These must move and must be better on arrival. Prioritise these for content design work: plain language review, structure, heading hierarchy, calls to action.
Tier 2: Migrate as-is. Moderate-traffic pages that are accurate and functional but not a priority for immediate redesign. Move them and schedule a review within 12 months.
Tier 3: Retire. Low-traffic, duplicate, outdated, or no longer relevant to user needs. These should not migrate. Get stakeholder sign-off on retirements before migration planning, not during: it is far harder to get agreement under go-live pressure.
Step 3: Write content decisions into the migration plan
Most migration plans are technology documents. They list pages, URLs, redirects, and go-live dates. They don't record the content decisions.
Document every significant content decision: what was retired and why, what was merged and how, what was rewritten and to what standard. This matters for audit trails when a minister's office asks why a page is gone. It also protects the next content practitioner who inherits the site.
A simple decision record works: Page title / URL / Decision (migrate, retire, merge, rewrite) / Reason / Owner.
Keep this in a shared, accessible format, not a spreadsheet on someone's desktop.
Step 4: Apply plain language and accessibility standards before go-live
The point of consolidation is not just fewer URLs. It is content that works better for users.
Don't migrate content that fails WCAG 2.2 Level AA or the Australian Government Style Manual's plain language requirements. Fix it before it moves, or schedule the fix within 30 days of migration.
The Digital Inclusion Standard requires WCAG 2.2 Level AA, and the expectation is that the new site is more accessible than what it replaced, not simply equivalent. Consolidation itself is backed by policy: the Digital Access Standard, which applies to public-facing services from 1 January 2026, requires agencies to reduce duplication and minimise the number of access points.
For Tier 1 content, build plain language review into the migration workflow as a sign-off condition.
Step 5: Set up governance before go-live
Consolidation creates a window of high accountability. Use it.
Before the new site goes live, put in place:
A content owner register: who is accountable for each section of the site
A review schedule: when content will be reviewed next (12 months maximum for Tier 1)
A publication workflow: how new content gets reviewed before it goes live on the consolidated platform
Without a governance framework in place at launch, consolidated sites tend to regrow. The new site starts clean and within 18 months is accumulating content at the same rate as the old one.
What good looks like at 12 months
A well-managed consolidation results in a site where:
Every page has an owner and a next review date
Content has been audited, not just moved
Tier 1 content has been uplifted to plain language and accessibility standards
A decision record exists for what was retired
The governance framework was in place at launch
The measure of success is not how many pages moved. It is how many pages are still being maintained, correctly, 12 months after go-live. That is the question worth asking before the project starts.
The website consolidation content workbook
Everything in this guide as a workbook you can keep and reuse: the audit tests, the tiering framework, the decision record, and the launch governance checklist.
Download the workbook
Download it as a PDF.
The workbook on this page
Prefer to read it here? The full workbook is below, with each part in an expandable section.
1. Before you start
You need three things before you begin: a full list of current URLs (from a site crawl or CMS export), page view figures for at least the last 12 months, and one person with clear authority to retire content. Without that last one, the process stalls.
2. Audit before you move anything
An audit assesses what is worth keeping, not just what exists. Assess every page against four tests before it goes near a migration plan.
- Task relevance: is this supporting a real user task that still exists?
- Accuracy: is it current, correct, and not contradicted by other content?
- Duplication: does the same information exist elsewhere, and which version is better?
- Ownership: is there an accountable owner who will maintain it after migration?
Retirement test: a page with fewer than 100 views in 12 months and no legal requirement to exist is a candidate for retirement, not migration.
3. Sort every page into a tier
| Tier | What it is | What happens |
|---|---|---|
| Tier 1: Migrate and uplift | High-traffic, task-critical pages | Must move and must be better on arrival. Prioritise for plain language review, structure, heading hierarchy, and clear calls to action. |
| Tier 2: Migrate as-is | Moderate-traffic pages that are accurate and functional | Move them, and schedule a review within 12 months. |
| Tier 3: Retire | Low-traffic, duplicate, outdated, or no longer relevant | Do not migrate. Get stakeholder sign-off on retirements before migration planning, not under go-live pressure. |
4. Record every decision
Keep a decision record in a shared, accessible location. It is your audit trail when a minister's office asks why a page is gone, and it protects whoever inherits the site.
| Page title | URL | Decision | Reason | Owner |
|---|---|---|---|---|
| Apply for a permit | /permits/apply | Rewrite | Tier 1, fails plain language review | J. Smith, Services branch |
Decision options: migrate, retire, merge, or rewrite. The full workbook has blank rows to copy.
5. Set up governance before go-live
Consolidation creates a window of high accountability. Put these in place before launch, or the new site refills at the same rate as the old one.
- Content owner register: who is accountable for each section of the site.
- Review schedule: when each section is reviewed next (12 months maximum for Tier 1).
- Publication workflow: how new content is reviewed before it goes live.
- Standards gate: Tier 1 content passes a plain language and accessibility (WCAG 2.2 Level AA) review as a sign-off condition before migration.
6. The 12-month success check
Success is not how many pages moved. It is how many are still being maintained, correctly, 12 months after go-live. Check that:
- every page has an owner and a next review date;
- content was audited, not just moved;
- Tier 1 content was uplifted to plain language and accessibility standards;
- a decision record exists for what was retired;
- the governance framework was in place at launch.
Photo by UX Indonesia on Unsplash.
Did this land?
I write these to be used, not just read. Tell me if this wouldn't work in your organisation, and why.