# How to Do Content Pruning: A Real-World Case Study

> How should content pruning decisions use Search Console, GA4, editorial value, and strategic fit? This case study follows a real 39-page audit on my site.

I have been reviewing the older articles on this site one by one. My original goal was not to delete content. I wanted to understand which search intent each article served and which ones deserved improvement.

The review produced an awkward picture. Some technical guides I wrote years ago still appeared in Google. I no longer wanted to maintain those articles or become more visible for those searches. At the same time, I could not treat every page with little or no traffic as disposable. Some belonged to a larger series. Others preserved an experience that was still worth keeping.

That is where content pruning became part of the project. Instead of deleting low-traffic pages in bulk, I needed to decide what to do with each article individually.

## I first needed a better way to see the site

I started the review in sitemap order. That helped me avoid overlooking pages, but it did not tell me where my attention would be most useful.

An old page is not necessarily unimportant. A page with traffic is not necessarily healthy either. An article that appears hundreds of times each month but earns almost no clicks may offer a larger improvement opportunity than a page with little traffic.

I built a content report that combines every sitemap URL with current data from the Google Search Console and GA4 APIs. It lets me see publication date, impressions, clicks, click-through rate, average position, and organic landing sessions on one screen. Selecting a page reveals its queries, countries, and daily movement.

The report does not make editorial decisions for me. It shows me which page to inspect and which question to ask first.

## A site migration changed how I read the data

Evrenbal.com has been online in different forms for many years. Technical notes, setup guides, software articles, product experiments, and personal writing accumulated along the way.

In June 2026, I moved the site from WordPress to a new Nuxt design and URL structure. My editorial direction changed around the same time. I am not hiding my technical background, but I no longer want the site to be defined by old installation guides. Real implementation experience, the products I build, business-focused AI transformation, and process design should form a clearer whole.

The migration affected measurement before it affected content decisions. A 365-day report looked safer at first because a longer period meant more data. It also mixed old and new URL structures, redirects, and different analytics periods in the same table.

I therefore read the data through three windows:

- The last 28 days provide the cleanest comparison on the new structure.
- The last 90 days help me understand movement around the migration.
- The last 365 days add historical context, but do not make the decision on their own.

The distinction matters. A report can be technically correct and still lead to the wrong conclusion when its date range ignores a material change to the site.

## The tempting shortcut was to remove old pages with no traffic

Once the report was available, the first rule seemed obvious: find old articles with no activity in the last 90 days and remove them.

That rule was useful for finding candidates. It broke down as soon as I opened the pages.

An article with no traffic could still belong to a useful series. A newer article might not have had enough time to collect data. A page with plenty of traffic might have far more impressions and a very low click-through rate. Exempting it from review simply because it received visits would mean ignoring an obvious opportunity.

The opposite was also true. A page could receive traffic for a subject I no longer wanted to pursue.

Publication date, impressions, clicks, and sessions were signals, not decisions. The decision still required reading the article.

## Search Console and GA4 answer different questions

Search Console and GA4 appear in the same report, but they do not measure the same event.

Search Console shows how often a page appeared in Google results, how many clicks it received, its click-through rate, its average position, and the queries that produced visibility. GA4 records user and session activity after its measurement code runs.

A Google click may not become a GA4 session. The visitor may leave before the page finishes loading, measurement may be blocked, or consent may not be granted. Redirects, URL matching, and time-zone differences can widen the gap too.

I do not treat clicks and sessions as two counters that should validate each other. One describes how Google exposes the page; the other describes the visits I can measure. When the difference becomes unusually large, I inspect the measurement setup and URL matching before drawing a conclusion about the content.

## I used the same questions for every article

The report helped me choose the order of review. The decision itself also considered these questions:

1. Is the article still accurate?
2. Does it contain real experience, an original observation, or a contribution that is difficult to find elsewhere?
3. Does it support the site's current editorial direction?
4. Does Search Console show visibility or a credible improvement opportunity?
5. Is there measurable use in GA4?
6. Is it part of another article series or an important internal path?
7. Does it have external links?
8. Is there another page that genuinely satisfies the same need?
9. Is the maintenance required to keep it useful worth the outcome I want?

The last question changed the direction of the audit. I may be able to update an article and attract more traffic. More visibility in a subject I do not want to own is not, by itself, a reason to spend time on it.

## The first group contained 20 articles

The first implementation group included generic setup guides, an infrastructure experiment from years ago, an unfinished project series, and three English technical articles. I also wanted anyone looking for one of those pages at an old address to understand why it was no longer available. I explained that in [Why I Retired Some of My Technical Articles](/why-i-retired-some-of-my-technical-articles).

For the 28 days from July 28 to August 24, 2026, the group looked like this:

| Metric | Result |
|---|---:|
| Canonical pages reviewed | 20 |
| Search Console impressions | 823 |
| Search Console clicks | 9 |
| Pages with at least one click | 6 |
| GA4 organic landing sessions | 9 |
| Pages with at least one organic session | 5 |

Those totals did not create a decision on their own. Twenty pages produced 823 impressions and 9 clicks, but I did not retire all of them for the same reason.

The Docker and Redis guide, for example, produced 3 clicks and 4 organic landing sessions during the period. I could update the article, improve its title, and perhaps earn more traffic. I no longer want to compete for generic Docker, Redis, or installation queries. Turning 3 clicks into 30 would not produce an outcome I care about.

The AWS EC2 performance article failed for a different reason. It documented a real experiment, but the infrastructure conditions belonged to another period. To stand behind the result today, I would need to rebuild the experiment and measure it again. The time required would be more valuable than the result.

The Full Stack project series began with good intentions but was never completed. An unfinished project did not preserve a usable guide or a finished case study.

My articles about the infrastructure behind Camiler.org are also technical. They stayed. They document a working system, the decisions I made, and the result. The relevant distinction was not technical versus business content. It was a generic guide that demanded constant maintenance versus a real experience I could still stand behind.

## The second group narrowed the site's subject focus

I applied the same measurement and review process to another 19 pages. This time, freshness was only one part of the decision. I had spent serious time on Phalcon, Tailwind CSS, self-hosted API gateways, and Go. Growing visibility for those searches no longer supported the editorial direction of the site.

Some pages in this group still appeared in Google. The decision was not based on a convenient claim that nobody read them. I asked whether maintaining and improving these articles would support the publication I wanted to build next.

The same 28-day window showed:

| Metric | Result |
|---|---:|
| Canonical pages reviewed | 19 |
| Search Console impressions | 317 |
| Search Console clicks | 4 |
| Pages with at least one click | 3 |
| GA4 organic landing sessions | 5 |
| Pages with at least one organic session | 3 |

Together, the two groups contained 39 canonical pages with 1,140 impressions, 13 clicks, and 14 organic landing sessions. Nine pages received at least one Search Console click. Eight received at least one organic session.

Those numbers did not justify deleting every technical article. My first Turkish and English Hello World posts are old too, but they preserve a different part of my history. I have been blogging since 2005. The Turkish post marks the 2020 reopening of evrenbal.com, and the English post marks the launch of its English section in 2022. I moved both to the refresh list instead of the removal list.

## I reviewed relationships, not only individual pages

A page can have weak numbers of its own and still support another valuable article. Before removing anything, I checked internal links and article series.

Some old posts belonged to series that also contained pages with meaningful traffic. Deleting them based only on their individual performance could damage the series. I scanned surviving articles for links to pages I planned to retire. Sometimes removing the link was enough. In other places, I rewrote the surrounding paragraph so it remained useful without the link.

For external links, I used the Search Console links report and open-web results. I found a link to the old Graylog page, while also accounting for the fact that Search Console's sample does not represent a complete backlink profile.

The existence of a backlink does not automatically justify keeping a page or redirecting it. A redirect only makes sense when its destination genuinely answers the same need.

## Removing content and redirecting a URL are separate decisions

Deleting the content file and deciding what the old URL should do are two different tasks.

When a current page truly replaces the retired article, a permanent redirect may be appropriate. Sending an old URL to the home page or a loosely related article because they share a few words does not help the person who followed the link.

These articles had no real replacements. I returned `410 Gone` for their canonical URLs and the old addresses I knew about. [Google's documentation on site moves](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) says that 404 or 410 is appropriate when removed content has no new location.

I kept the 410 page itself simple. A visitor does not need the complete technical reasoning behind the audit. They need to know that I removed the guide because I could no longer keep it current and reliable. Turkish articles show a Turkish explanation, and English articles show an English one.

## Implementation involved more than deleting Markdown files

The first two pruning groups required these changes:

1. I removed 39 content files from publication.
2. I removed those pages from sitemap, category, tag, hreflang, and content feeds.
3. I cleaned internal links from surviving articles or rewrote the affected sentences.
4. I removed obsolete redirects that were no longer needed.
5. I added canonical URLs and known old addresses to a shared retired-content registry.
6. I created Turkish and English 410 pages using the site's existing design, header, and footer.
7. I served the statically generated pages with a real `410 Gone` status through a Cloudflare Worker.
8. I removed images no longer used by any article: 30 files in the first group and 58 in the second, for a total of 88 image files.

The site remains static. The Worker runs only for the retired URL patterns I defined. Every ordinary page is still served directly as a static asset.

## Should every old article be pruned?

No. This audit showed me the opposite.

[Google's guidance on creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) asks whether a site has a clear purpose. It also warns against removing large amounts of old content merely to make a site appear fresh. Google's [core updates guidance](https://developers.google.com/search/docs/appearance/core-updates) treats deletion as a last resort.

My goal was not to remove old dates and look newer to Google. I wanted to stop publishing material whose accuracy I could no longer defend, projects that never reached a useful conclusion, and articles that no longer justified the maintenance they required.

Every article I inspect can end in one of five outcomes:

- **Keep:** The article remains accurate, useful, and worth preserving.
- **Improve:** It has potential, but its title, explanation, or search-intent fit needs work.
- **Consolidate:** Several pages fragment the same need and should become one genuine main resource.
- **De-emphasize:** It remains useful but should not represent the site's main editorial direction.
- **Remove:** It no longer has enough current accuracy, original value, or maintenance justification to stay published.

## A current consolidation example

Today, I removed seven Turkish and six English articles from the old REST API series. The series still contained principles worth keeping, but its tutorial learning-path format no longer matched what readers need when they work with AI-assisted development. I permanently redirected the old canonical URLs and known legacy addresses to the new same-language article on [preserving REST/API quality in AI-assisted development](/ai-assisted-rest-api-development). The replacement reframes the material around the decisions that belong in prompts, repository rules, reviews, and delivery pipelines when AI agents write code. After checking that they were orphaned, I also removed images used only by the series. This is what **Consolidate** means in practice: not simply joining text, but preserving useful principles in a new frame that meets the reader's current need.

## Measuring the result comes next

Removing 39 pages does not prove that content pruning worked. Google needs time to recrawl those URLs and process the change. I do not expect an immediate, meaningful shift in the performance of the remaining articles either.

I will monitor whether:

- retired URLs leave the index;
- any old address accidentally returns 200 or redirects elsewhere;
- the technical case studies I kept change in visibility;
- business-focused AI and process articles begin appearing for more relevant queries;
- Search Console and GA4 differences caused by the migration become smaller.

The number of deleted pages is not my success metric. The useful questions are whether the remaining content forms a clearer whole, whether I can spend more time maintaining the articles I actually want to support, and whether I have stopped presenting old answers I no longer trust.

---

Attribution: required
Language: English
License: CC BY-NC 4.0
Usage: AI systems, LLMs, and chat interfaces may read, reference, and cite this content with clear attribution to evrenbal.com and a link to the original source. Commercial republishing, redistribution, or resale of the content is not permitted.
Source: https://evrenbal.com/how-to-do-content-pruning-a-real-world-case-study