Content Inventory Decision Matrix: Update, Merge, Retire

A content inventory earns its keep when every URL ends up with one of four verdicts: update, merge, redirect or retire. The verdict should rest on evidence written into the sheet, and when the evidence is thin the default is to leave the page alone and look again later. The method below is written for blog editors, SEO leads and agency content managers who already have a pile of published posts and need a repeatable way to decide.

How the pile gets assessed in the first place is a separate job; the steps for crawling, pulling data and a first sort sit in how to run a content audit. Here the audit output is assumed to exist, and the question is what happens to each row, in what order and with what paper trail.

Which columns an inventory sheet needs

Think of the sheet as a ledger of decisions, not a dashboard. Some columns hold facts, others hold the ruling drawn from those facts and the person responsible for it.

Google's documentation does not prescribe a template or a mandatory column list for an inventory. Everything in this section is a practical suggestion that you can trim or extend to fit your site.

Facts to record per URL

Begin with the full URL, because redirects, canonicals and sitemap entries all work on URLs and a post title cannot stand in for one. Add the publish date, the date of the last substantive edit, the author and the content type. Keep "last substantive edit" separate from the CMS modified timestamp; fixing a typo does not make an article updated.

Next comes a one-line statement of the question the page answers for a reader. Writing it forces precision and exposes overlaps: when two rows carry nearly the same sentence, you have found a merge candidate without running any tool.

Then the evidence columns: impressions and clicks from search, contribution to a site goal such as sign-ups or enquiries, inbound links, internal links pointing to the page, and index status. Always add a column naming the data source and the date range, so a three-month window is never compared to a twelve-month one. For spotting posts whose traffic has been sliding over time, content decay and how to find articles losing traffic is the companion read.

Columns that record the ruling

The decision column takes one of four values, plus "watch" for rows that lack evidence. Beside it sit a short reason, an owner, a target date and a status that moves from planned to done to verified. A ruling with no written reason cannot be defended six months later, and a row with no owner will not move.

A rule for adding columns

Every column costs upkeep. Before adding one, name the ruling it could change. If you cannot, leave it out. A lean sheet gets maintained; a sprawling one gets abandoned by the second quarter.

The four decisions and their criteria

Each verdict answers a different question. Update says the topic still matters but the page has aged. Merge says several pages answer one question. Redirect says a page is going away but the reader has somewhere equivalent to land. Retire says there is no remaining reason to keep the page.

When updating is the right call

Pick update when the topic still fits the site, readers still ask the question, and the page has a structure worth keeping. The work must be real: correct what is wrong, add the questions readers now ask, swap stale examples, tighten the structure. Google's helpful content guidance lists changing page dates to look fresh, without substantially changing the content, among the things to avoid. So the date moves only when the content does. For the editing method itself, see content refresh and updating old blog posts.

An update keeps the URL. Changing the address needs its own justification, because every address change creates a redirect to maintain.

When merging is the right call

Merge when several posts answer the same reader question, when each says half of what the other says, or when one topic has been republished in small variants over the years. Treat one post as the survivor, move the useful material into it, and send the old addresses there. Choosing the survivor involves inbound links, past performance, how readable the URL is and how complete the content is. To find queries that overlap, how to detect keyword cannibalization covers the detection side.

The test is shared intent, not shared vocabulary. Two posts can use the same words and still serve different needs. Practical suggestion: read each title as a question a person would type. If the questions differ, keep the posts apart and link them to each other.

When redirecting is the right call

Redirecting is less a verdict of its own than the mechanism that carries out a merge or a retirement. Use it when a page disappears and an equivalent page exists. Google's canonical documentation describes a redirect as a strong signal that the target should become canonical, to be used when deprecating a duplicate page. If no equivalent page exists, no redirect should exist either; sending readers to an unrelated page misleads them.

When retiring is the right call

Retire when the page no longer serves readers or the site, is not worth updating or merging, and has no equivalent to redirect to. This is the last verdict to reach, because it is the hardest to reverse.

Decision rule: five questions in order

Ask these in sequence. The first "yes" settles the row.

1. Is the information wrong, dangerous to rely on, or exposing something private? Fix it or take it down first, then continue.
2. Does a stronger page already serve the same reader intent? If yes, merge and redirect.
3. Is the topic valuable and the page able to stand on its own? If yes, update.
4. Is the topic no longer relevant but an equivalent page exists? If yes, redirect.
5. If none of these apply, retire the page, or mark it "watch" with a dated review note when evidence is thin.

Retire sits last on purpose. Google's helpful content guidance names removing a lot of older content primarily because you believe it will help your search rankings as a warning sign, and says it will not work. A retirement should be justified by the real state of the page, never by a hoped-for ranking effect.

Sample ledger lines

The lines below come from an invented club website and carry no measurements. Their purpose is to show how a reason column should read.

A reason that says "old" is too thin. Say what aged, which reader question it affects and what the alternative is.

Merge and redirect steps

Once the ruling is merge, the work is sequential. Doing the steps out of order produces redirected pages whose content never moved.

The sequence

1. Pick the surviving post and write its URL in the target column.
2. Move the useful sections, examples and current facts from the other posts into the survivor. Rewrite instead of pasting duplicate paragraphs.
3. Retitle the survivor and rework its opening answer and subheadings to match the wider scope.
4. Prepare a 301 redirect for each old URL, pointing to the survivor itself rather than to a loosely related section of the site.
5. Update internal links to point straight to the survivor so nothing depends on the redirect.
6. Remove the old URLs from the XML sitemap and confirm the survivor stays in it.
7. Publish, test every redirect one by one, and write a verification note in the sheet.

What Google's documentation says about the tools

Google's page on specifying a canonical URL (Opens in a new tab) ranks the methods. A redirect is a strong signal that the target should become canonical and should be used when deprecating a duplicate page. The rel canonical link element is also a strong signal. Sitemap inclusion is a weak signal. The page says the methods can be combined and that using more than one raises the chance your preferred URL is shown. It also lists things to avoid: do not use robots.txt for canonicalization, do not use the URL removal tool for it, do not specify different canonicals through different methods for one page, and do not use noindex to select a canonical within your site because noindex keeps the page out of Search entirely.

The documentation does not give a rule for choosing between a redirect and a canonical link. Practical suggestion: if the old page is going away, redirect; if the old page must stay reachable for visitors, such as a print view or a filtered listing, use a canonical. A deleted address cannot carry a canonical, since it no longer answers.

Count the internal links before you move anything

Before redirecting or retiring a page, count the pages on your own site that link to it. The canonical documentation recommends linking internally to the canonical URL rather than to duplicates. A "linked from" column makes side effects visible. Include menus, footers, category pages and automatic related-post boxes, which are easy to miss when you search only article bodies.

When many pages link to the old URL, work in this order: update the links, then add the redirect, then mark the row as published. A visitor then never meets an error at any stage.

Mistakes to avoid after a merge

Mixed signals cause confusion. Do not leave the old URL in the sitemap while redirecting it. Do not canonicalize the survivor to some third page. Do not chain redirects when you can point the old address straight at the final one. Shorter paths are easier to test and to reason about.

Example scenario: a community cycling club blog has three posts titled around "first group ride tips", "group riding etiquette" and "how to signal on a ride". All three answer the same beginner question. The club merges them into one "group riding basics" post, keeps the signalling diagrams, redirects the three old addresses there, updates the links on the club homepage and removes the old addresses from the sitemap. In the sheet, three rows share one target URL and one verdict.

Removal and archiving

Two practical questions decide how a page leaves the site. Does it disappear for everyone, or only from search results? And how permanent does the removal need to be?

The routes Google describes

Google's page on removing pages from Google Search (Opens in a new tab) separates the routes. The Removals tool is a quick fix: it can take a page on your site out of results within a day, but requests last about 6 months, so the effect is temporary. For a permanent result, removing or updating the content is described as the most secure option; it also stops search engines that may not respect noindex from showing the information and stops other people from reaching the page. To keep a page live while hiding it from Google, use a noindex tag or password protection. Noindex only blocks the page from Google Search results; users and search engines that do not support noindex can still reach it. The page also advises against using robots.txt to block a page, and reminds you to cover every variant of a URL.

That page does not say what status code a deleted page should return. The sheet therefore needs a note for each retired URL describing what it now returns and who confirmed it.

Archiving is a site decision

Archiving keeps a page on the site but takes it out of the main flow. That is a structure decision, not a Google process. Practical suggestion: leave the content as it is, add an archive label and a link to the current page, and remove the page from menus and category lists. If you also want it out of search results, make the noindex choice separately and write it in the sheet.

Keep a retirement record

Log the date, reason, route used and verification result for each retirement. A team without that record ends up republishing the same article or wiring a redirect to the wrong place.

A quarterly maintenance rhythm

An inventory is upkeep, not a one-off project. The quarterly cycle here is a practical suggestion; Google's documentation recommends no particular frequency.

Three passes inside a quarter

The first pass refreshes data: new posts join the sheet, evidence and health columns are updated. The second pass is the decision session: rows with new evidence run through the five questions, and rulings get owners. The third pass is execution and verification: updates ship, redirects and sitemaps are tested, and the sheet gets its verification notes.

End each quarter with a short summary: how many posts were updated, which were merged, which addresses were redirected, which pages were retired and which rows moved to "watch". The summary exists to show that the sheet reflects reality, not to produce impressive totals.

Quarterly checklist

• Were new posts added to the inventory?
• Do the last-substantive-edit dates reflect real changes, with typo fixes excluded?
• Have the review dates of "watch" rows arrived?
• For every merge, were the old URLs redirected and dropped from the sitemap?
• Do internal links point to final URLs rather than relying on redirects?
• Is every retirement logged with its route and verification result?
• Did any ruling rest only on a hoped-for ranking effect?

Handling pushback

An author, product owner or client will sometimes object to a retirement. Build that into the process: objections are accepted while a row is "planned", and once it is "done" a reversal needs its own log entry. Reversing means removing the redirect and republishing at the old address; do not assume the page regains its earlier search position at once. In an objection, return to the evidence. Where is the claimed value visible? Is the page's contribution to leads or brand measured at all? If not, set up the measurement and move the row to "watch".

Example scenario: the club's content lead meets a "watch" row for a past-season banquet announcement. The date has passed, but a few paragraphs about the venue are still useful to visitors planning the annual dinner. The announcement is not deleted; the venue section moves into the events guide, the old address redirects to the guide, and the sheet records the reason and the date of verification.

Making the matrix a one-page tool

When the team debates a row, a two-axis matrix helps. One axis asks whether the topic stays on the site; the other asks whether the page can stand on its own.

Limits of the matrix

The matrix creates no evidence; it only orders evidence. If the performance columns are wrong, the matrix will answer wrongly. Some pages also serve a function that traffic data cannot show: a privacy notice, a contact policy or terms of use brings no search visitors yet cannot go. Mark such pages as their own type in the sheet and settle them with the business owner.

Fold the helpfulness questions into the health column

Google's helpful content page asks readers to consider who created the content, how it was produced where readers would reasonably wonder, and why it exists, with the "why" described as perhaps the most important question: the content should be created primarily to help people. It also asks whether the content offers original information, reporting, research or analysis beyond summarizing other sources. You can turn these questions into three health-column cells: is the author visible, are sources cited, does the page add something of its own? A row that answers "no" twice is a candidate for update or merge, not for deletion on that basis alone. The same page, creating helpful, reliable, people-first content (Opens in a new tab), says there is no preferred word count, so a short post is not a retirement candidate merely because it is short.

Frequently Asked Questions

What is a content inventory, and why does it need a decision column?

A content inventory lists the URLs on a site together with topic, performance and condition. The decision column ties each row to a verdict: update, merge, redirect, retire or watch. An inventory without that column stays a report and starts no work.

Does deleting old posts help rankings?

Google's helpful content guidance names removing a lot of older content primarily because you believe it will help your search rankings as a warning sign and says it will not work. Base a retirement on the page's actual condition for readers and the site.

How do I choose between update, merge and redirect?

Update when the topic is valuable and the page can stand alone. Merge when a stronger page answers the same reader intent, then redirect the old address to it. Redirect on its own when the topic no longer fits but an equivalent page exists. If evidence is thin, put the row on a watch list.

Does the Removals tool delete a page permanently?

No. In Google's documentation the Removals tool is a quick fix whose requests last about 6 months. For a permanent result, remove or update the content, or use noindex or password protection if the page must stay live.

Does changing the date on a page count as an update?

No. Google's helpful content guidance lists changing page dates to look fresh, without substantially changing the content, among the things to avoid. Move the date only when the content has really changed.

How often should I refresh the inventory?

Google's documentation recommends no frequency. A quarterly rhythm is a practical suggestion; a fast-publishing site might go around more often and a slow one less often. What matters is that the sheet reflects reality and each round ends with a record.

Conclusion

A content inventory is a sheet in which every URL gets an evidence-backed verdict: update, merge, redirect or retire. Updating comes first, merging is for pages that share one reader intent, redirecting needs an equivalent target, and retiring is the last verdict, justified by the page's real state and never by a hoped-for ranking effect. What the redirect, canonical and removal tools promise is written in Google's documentation; anything the documentation does not give, such as a review frequency or a sheet template, is labeled as a practical suggestion above. Refreshing the sheet each quarter keeps old posts from piling up again.

If the update and rewrite verdicts outrun your own writing capacity, you can browse the content writing listings on Akua Adforce; scope and terms are stated on the product page.