How to Audit Content Before Updating, Merging or Removing Pages

When you review a website’s pages, low traffic or old publication dates alone do not tell you what to change. A content audit reviews each page’s purpose, whether it still helps readers, and what the available evidence says about how people use it. That review helps you decide whether to keep a page, update it, combine it with another page, or remove it.

Start with the page’s purpose and check several kinds of evidence before choosing an action. Search performance, visitor behavior, links, and technical health each show something different. Together, they can support a decision, but no single metric proves that a page should stay or go.

Build a page inventory before judging performance

Start with a complete list of URLs from your content management system or a site crawl. Compare that list with your sitemaps, Search Console data, analytics, server logs, and link data where available. Google recommends several of these sources for finding URLs during a site move. Using them to build an audit inventory is a practical adaptation, not a Google formula for deciding what to delete. Choose a review period that accounts for seasonal changes, especially for topics whose interest varies during the year. See Google’s guidance on identifying URLs during a site move.

For each page, record its URL, title, type, intended audience, and purpose. Add its search performance and meaningful visitor actions, along with internal links, external links, current status code, and canonical URL. A canonical URL is the version of a page that search engines treat as the preferred one when they find duplicate or very similar URLs. These details help you see whether a page has a content problem or a technical problem. For example, a page that seems to have little search activity might have a canonical pointing elsewhere, a crawl problem, or a distinct role that analytics does not measure.

Keep a note of the planned action and its reason. That record makes it easier to check later whether the change addressed the problem you found.

Check the page’s purpose and its search evidence

Read the page as a visitor would. Ask what question or task it addresses, who it is for, and whether a reader can still get a useful answer from it. Check facts, instructions, product details, dates, and cited sources. Look for missing context or steps, and compare the page with other pages on your site that cover similar ground.

Google’s people-first content guidance offers questions for evaluating whether a page helps its intended audience. Those questions support editorial judgment; they do not produce a score that determines whether a page ranks or should be removed. A page can also help in ways search traffic does not capture, such as helping an existing customer or prompting a visitor to complete a desired action.

Then review Search Console and analytics. Search Console shows Google Search impressions, clicks, queries and related performance data. Impressions count how often a page appears in search results. Clicks count how often people select its result, and queries are the searches people entered. Analytics can show visits and actions on your site, but only interpret those actions if tracking is set up to measure them reliably. Compare relevant periods and search types. For seasonal subjects, compare similar parts of the year rather than assuming a recent decline reflects a change to the page.

Read the numbers as clues. Impressions with few clicks give you a reason to inspect whether the page matches the queries and whether its search result title and description represent it clearly. Few observed clicks do not prove that the page has no value. Search Console omits some queries for privacy and limits the rows shown in reports. It can also assign performance to the canonical URL rather than another duplicate URL. Its performance report documentation explains these limitations.

If several URLs appear for similar searches, check what each page offers. Similar queries do not prove that pages serve the same audience or need. If performance appears under an unexpected URL, check the canonical and redirects before concluding that the content itself underperforms. Google can choose a different canonical URL from the one the site owner indicates, based on evidence it finds across the pages. Its canonicalization guidance describes how that selection works.

Choose an action that fits the problem

Keep the page when it serves a distinct need, remains accurate, and works technically. A small ranking decline on its own does not justify a major rewrite. Google advises site owners to assess core update effects carefully and avoid drastic changes in response to small position shifts in its core updates guidance.

Update the page when its purpose remains valid but its facts are stale, its answer is incomplete, or readers cannot use it easily. Make changes that improve the answer or its usability, then make the visible publication date reflect the actual change. Changing a date without meaningful work does not make the page more useful. For time-sensitive material, see how to update a guide without merely changing its date.

Merge pages when they substantially overlap and one destination can genuinely serve their combined purpose. Preserve useful information from each page, remove repetition, and make the resulting page clear about the shared subject. Map each retired URL to the new destination. Similar wording or shared keywords alone are weak grounds for a merge: readers may need separate pages for different audiences, tasks, or stages of a decision.

Remove a page when its content is no longer needed and no suitable replacement exists. Return a real 404 or 410 status, which tells a browser and crawler that the URL is unavailable or permanently gone. Do not redirect an unrelated page to the homepage just to avoid an error. Google warns that it can treat irrelevant redirects as soft 404s. A soft 404 is a URL that appears to lead somewhere but does not provide a suitable replacement. Its crawling error guidance explains how to distinguish real errors from pages that return an error-like message with a successful status.

Check every URL change after release

Before retiring a URL, check whether other pages link to it and whether external sites refer to it. Update internal links to point directly to the retained or merged page. For a merge, test each old URL and confirm that its redirect reaches the relevant final destination without passing through unnecessary redirects. Google recommends direct permanent redirects to the final URL and cautions against redirect chains in its redirect guidance.

After an update or merge, confirm that the intended page loads, returns the right status, and lets search engines access its content. Check that its canonical points to the intended URL and that the sitemap and internal links no longer promote retired URLs. For a removal, confirm that the URL returns the intended 404 or 410 rather than a successful status with a generic error message.

Do not expect a search result to change as soon as you publish. Google says recrawling can take days to weeks, and a request to recrawl does not guarantee indexing. Record the relevant performance before the change. After Google has had time to revisit the pages, compare the same pages, queries, and time periods. A change in performance is evidence to investigate, not proof that the edit caused it.

What the audit means for AI search

For Google AI Overviews and AI Mode, Google says a page must be indexed and eligible to appear with a search snippet to be eligible as a supporting link. Google describes no additional technical requirements or special markup for these features, and eligibility does not guarantee inclusion. Google also reports AI-feature traffic within the Search Console Performance report’s Web search type. Its AI features guidance does not provide a way to predict whether a particular page will appear.

That makes the audit’s basic checks relevant: keep useful, accessible pages crawlable, make their information accurate, and preserve links to pages that still serve readers. Updating, merging, or removing a page does not guarantee more visibility in AI results.

Key Takeaways

• Review purpose before traffic: Low Search Console activity is a prompt to investigate, not proof that a page has no value.
• Use several kinds of evidence: Combine page quality, search data, visitor actions, links, and technical checks before choosing what to change.
• Merge only when needs overlap: Send each retired URL to a relevant consolidated page, and use a real 404 or 410 when no replacement exists.
• Check the result after release: Test status codes, redirects, canonicals, internal links, and search performance after crawlers have had time to revisit the URLs.
• Treat AI visibility as uncertain: Google’s indexing and snippet eligibility rules apply to its AI search features, but inclusion is not guaranteed.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com