Content Pruning: Eine Fallstudie aus der Praxis

Ich prüfe die älteren Artikel dieser Website einen nach dem anderen. Mein ursprüngliches Ziel war nicht, Inhalte zu löschen. Ich wollte verstehen, welche Suchabsicht jeder Artikel erfüllt und welche Beiträge eine Verbesserung verdienen.

Die Prüfung ergab ein unbequemes Bild. Einige technische Leitfäden, die ich vor Jahren geschrieben hatte, erschienen weiterhin bei Google. Ich wollte diese Artikel weder weiter pflegen noch für diese Suchanfragen sichtbarer werden. Gleichzeitig konnte ich nicht jede Seite mit wenig oder keinem Traffic als entbehrlich behandeln. Einige gehörten zu einer größeren Reihe. Andere bewahrten eine Erfahrung, die weiterhin erhaltenswert war.

So wurde Content Pruning Teil des Projekts. Statt Seiten mit geringem Traffic in großer Zahl zu löschen, musste ich für jeden Artikel einzeln entscheiden, was mit ihm geschehen sollte.

Zuerst brauchte ich einen besseren Blick auf die Website

Ich begann die Prüfung in der Reihenfolge der Sitemap. So konnte ich vermeiden, Seiten zu übersehen. Die Reihenfolge zeigte mir aber nicht, wo meine Aufmerksamkeit am meisten bewirken würde.

Eine alte Seite ist nicht zwangsläufig unwichtig. Eine Seite mit Traffic ist auch nicht automatisch gesund. Ein Artikel, der jeden Monat Hunderte Male erscheint und fast keine Klicks erhält, kann eine größere Verbesserungsmöglichkeit darstellen als eine Seite mit wenig Traffic.

Ich baute einen Inhaltsbericht, der jede URL aus der Sitemap mit aktuellen Daten aus den APIs von Google Search Console und GA4 verbindet. Auf einem Bildschirm sehe ich Veröffentlichungsdatum, Impressionen, Klicks, Klickrate, durchschnittliche Position und organische Landing-Sessions. Wenn ich eine Seite auswähle, erscheinen die dazugehörigen Suchanfragen, Länder und täglichen Veränderungen.

Der Bericht trifft keine redaktionellen Entscheidungen für mich. Er zeigt mir, welche Seite ich prüfen und welche Frage ich zuerst stellen sollte.

Eine Website-Migration veränderte meine Lesart der Daten

Evrenbal.com ist seit vielen Jahren in unterschiedlichen Formen online. Technische Notizen, Einrichtungsleitfäden, Softwareartikel, Produktexperimente und persönliche Texte haben sich im Laufe der Zeit angesammelt.

Im Juni 2026 zog ich die Website von WordPress auf ein neues Nuxt-Design mit einer neuen URL-Struktur um. Etwa zur selben Zeit änderte sich meine redaktionelle Richtung. Ich verstecke meinen technischen Hintergrund nicht. Die Website soll aber nicht länger durch alte Installationsleitfäden definiert werden. Echte Umsetzungserfahrung, die Produkte, die ich entwickle, geschäftsorientierte KI-Transformation und Prozessgestaltung sollen ein klareres Ganzes ergeben.

Die Migration wirkte sich auf die Messung aus, bevor sie die Inhaltsentscheidungen beeinflusste. Ein Bericht über 365 Tage erschien zunächst sicherer, weil ein längerer Zeitraum mehr Daten bedeutet. Er vermischte aber alte und neue URL-Strukturen, Weiterleitungen und unterschiedliche Analysezeiträume in derselben Tabelle.

Deshalb lese ich die Daten in drei Zeitfenstern:

• Die letzten 28 Tage liefern den saubersten Vergleich auf der neuen Struktur.
• Die letzten 90 Tage helfen mir, Bewegungen rund um die Migration zu verstehen.
• Die letzten 365 Tage ergänzen historischen Kontext, entscheiden aber nicht allein.

Die Unterscheidung ist wichtig. Ein Bericht kann technisch korrekt sein und trotzdem zur falschen Schlussfolgerung führen, wenn sein Zeitraum eine wesentliche Veränderung der Website ignoriert.

Die verführerische Abkürzung war, alte Seiten ohne Traffic zu entfernen

Als der Bericht verfügbar war, schien die erste Regel offensichtlich: alte Artikel ohne Aktivität in den vergangenen 90 Tagen finden und entfernen.

Diese Regel half dabei, Kandidaten zu identifizieren. Sie brach zusammen, sobald ich die Seiten öffnete.

Ein Artikel ohne Traffic konnte weiterhin zu einer nützlichen Reihe gehören. Ein neuerer Artikel hatte vielleicht noch nicht genügend Zeit, Daten zu sammeln. Eine Seite mit viel Traffic konnte erheblich mehr Impressionen als Klicks und eine sehr niedrige Klickrate aufweisen. Sie nur wegen ihrer Besuche von der Prüfung auszunehmen hätte bedeutet, eine offensichtliche Möglichkeit zu ignorieren.

Das Gegenteil galt ebenfalls. Eine Seite konnte Traffic für ein Thema erhalten, das ich nicht mehr weiterverfolgen wollte.

Veröffentlichungsdatum, Impressionen, Klicks und Sessions waren Signale, keine Entscheidungen. Die Entscheidung verlangte weiterhin, den Artikel zu lesen.

Search Console und GA4 beantworten unterschiedliche Fragen

Search Console und GA4 erscheinen in demselben Bericht, messen aber nicht dasselbe Ereignis.

Search Console zeigt, wie häufig eine Seite in den Google-Ergebnissen erschien, wie viele Klicks sie erhielt, ihre Klickrate, ihre durchschnittliche Position und die Suchanfragen, die zur Sichtbarkeit führten. GA4 erfasst Nutzer- und Sitzungsaktivität, nachdem der Messcode ausgeführt wurde.

Ein Klick bei Google muss nicht zu einer GA4-Sitzung werden. Der Besucher kann die Seite verlassen, bevor sie vollständig geladen ist, die Messung kann blockiert sein oder die Einwilligung fehlt. Weiterleitungen, URL-Abgleich und Unterschiede bei Zeitzonen können die Lücke ebenfalls vergrößern.

Ich behandle Klicks und Sessions nicht als zwei Zähler, die einander bestätigen sollten. Der eine beschreibt, wie Google die Seite zeigt. Der andere beschreibt die Besuche, die ich messen kann. Wird der Unterschied ungewöhnlich groß, prüfe ich zunächst die Messkonfiguration und den URL-Abgleich, bevor ich eine Schlussfolgerung über den Inhalt ziehe.

Für jeden Artikel stellte ich dieselben Fragen

Der Bericht half mir, die Reihenfolge der Prüfung festzulegen. Die Entscheidung selbst berücksichtigte außerdem diese Fragen:

1. Ist der Artikel noch korrekt?
2. Enthält er echte Erfahrung, eine eigene Beobachtung oder einen Beitrag, der anderswo schwer zu finden ist?
3. Unterstützt er die heutige redaktionelle Richtung der Website?
4. Zeigt die Search Console Sichtbarkeit oder eine glaubwürdige Verbesserungsmöglichkeit?
5. Gibt es in GA4 eine messbare Nutzung?
6. Gehört der Artikel zu einer anderen Reihe oder zu einem wichtigen internen Pfad?
7. Hat er externe Links?
8. Gibt es eine andere Seite, die tatsächlich denselben Bedarf erfüllt?
9. Ist der Pflegeaufwand, der nötig wäre, um den Artikel nützlich zu halten, das gewünschte Ergebnis wert?

Die letzte Frage veränderte die Richtung der Prüfung. Vielleicht könnte ich einen Artikel aktualisieren und damit mehr Traffic gewinnen. Mehr Sichtbarkeit in einem Thema, für das ich nicht stehen möchte, ist für sich genommen aber kein Grund, Zeit dafür aufzuwenden.

Die erste Gruppe umfasste 20 Artikel

Zur ersten Umsetzungsgruppe gehörten allgemeine Einrichtungsleitfäden, ein mehrere Jahre altes Infrastrukturexperiment, eine unvollendete Projektserie und drei englische Technikartikel. Wer eine dieser Seiten unter einer alten Adresse suchte, sollte außerdem verstehen, warum sie nicht mehr verfügbar war. Dies habe ich in Warum ich einige technische Artikel ausgemustert habe erklärt.

Für die 28 Tage vom 28. Juli bis zum 24. August 2026 sah die Gruppe so aus:

Diese Summen führten nicht automatisch zu einer Entscheidung. Zwanzig Seiten erzeugten 823 Impressionen und neun Klicks. Ich nahm aber nicht alle aus demselben Grund aus der Veröffentlichung.

Der Docker- und Redis-Leitfaden brachte in diesem Zeitraum beispielsweise drei Klicks und vier organische Landing-Sessions. Ich hätte den Artikel aktualisieren, den Titel verbessern und vielleicht mehr Traffic gewinnen können. Ich möchte jedoch nicht mehr um allgemeine Docker-, Redis- oder Installationsanfragen konkurrieren. Aus drei Klicks dreißig zu machen würde kein Ergebnis erzeugen, das mir wichtig ist.

Der AWS-EC2-Performanceartikel scheiterte aus einem anderen Grund. Er dokumentierte ein echtes Experiment, doch die Infrastrukturbedingungen stammten aus einer anderen Zeit. Um heute hinter dem Ergebnis stehen zu können, müsste ich das Experiment neu aufbauen und erneut messen. Die dafür nötige Zeit wäre wertvoller als das Ergebnis.

Die Full-Stack-Projektserie begann mit guten Absichten, wurde aber nie fertiggestellt. Ein unvollendetes Projekt bewahrte weder einen brauchbaren Leitfaden noch eine abgeschlossene Fallstudie.

Meine Artikel über die Infrastruktur von Camiler.org sind ebenfalls technisch. Sie blieben. Sie dokumentieren ein funktionierendes System, meine Entscheidungen und das Ergebnis. Die entscheidende Unterscheidung lautete nicht „technischer oder geschäftlicher Inhalt“, sondern „allgemeiner Leitfaden mit dauerhaftem Pflegebedarf oder echte Erfahrung, hinter der ich weiterhin stehen kann“.

Die zweite Gruppe schärfte den thematischen Fokus der Website

Ich wandte denselben Mess- und Prüfprozess auf weitere 19 Seiten an. Diesmal war Aktualität nur ein Teil der Entscheidung. Ich hatte ernsthaft Zeit in Phalcon, Tailwind CSS, selbst gehostete API-Gateways und Go investiert. Mehr Sichtbarkeit für diese Suchanfragen unterstützte die redaktionelle Richtung der Website nicht mehr.

Einige Seiten dieser Gruppe erschienen weiterhin bei Google. Die Entscheidung beruhte nicht auf der bequemen Behauptung, niemand lese sie. Ich fragte, ob Pflege und Verbesserung dieser Artikel die Publikation unterstützen würden, die ich als Nächstes aufbauen wollte.

Im selben 28-Tage-Zeitraum ergaben sich:

Zusammen enthielten beide Gruppen 39 kanonische Seiten mit 1.140 Impressionen, 13 Klicks und 14 organischen Landing-Sessions. Neun Seiten erhielten mindestens einen Klick in der Search Console. Acht erhielten mindestens eine organische Session.

Diese Zahlen rechtfertigten nicht, jeden technischen Artikel zu löschen. Meine ersten türkischen und englischen Hello-World-Beiträge sind ebenfalls alt, bewahren aber einen anderen Teil meiner Geschichte. Ich blogge seit 2005. Der türkische Beitrag markiert die Wiedereröffnung von evrenbal.com im Jahr 2020, der englische den Start des englischen Bereichs 2022. Beide kamen auf die Aktualisierungs- statt auf die Entfernungsliste.

Ich prüfte Beziehungen, nicht nur einzelne Seiten

Eine Seite kann selbst schwache Zahlen haben und dennoch einen anderen wertvollen Artikel stützen. Vor jeder Entfernung prüfte ich deshalb interne Links und Artikelserien.

Einige alte Beiträge gehörten zu Reihen, die auch Seiten mit bedeutsamem Traffic enthielten. Sie allein wegen ihrer eigenen Leistung zu löschen hätte die Reihe beschädigen können. Ich suchte in den verbleibenden Artikeln nach Links zu Seiten, die ich ausmustern wollte. Manchmal genügte es, den Link zu entfernen. An anderer Stelle schrieb ich den umgebenden Absatz so um, dass er ohne den Link nützlich blieb.

Für externe Links nutzte ich den Linkbericht der Search Console und Ergebnisse aus dem offenen Web. Ich fand einen Link zur alten Graylog-Seite und berücksichtigte zugleich, dass die Stichprobe der Search Console kein vollständiges Backlink-Profil darstellt.

Die Existenz eines Backlinks rechtfertigt nicht automatisch, eine Seite zu behalten oder weiterzuleiten. Eine Weiterleitung ist nur sinnvoll, wenn ihr Ziel tatsächlich denselben Bedarf beantwortet.

Inhalt entfernen und URL weiterleiten sind getrennte Entscheidungen

Die Inhaltsdatei zu löschen und festzulegen, was die alte URL tun soll, sind zwei verschiedene Aufgaben.

Wenn eine heutige Seite den ausgemusterten Artikel tatsächlich ersetzt, kann eine permanente Weiterleitung passend sein. Eine alte URL zur Startseite oder zu einem lose verwandten Artikel zu senden, nur weil beide einige Wörter gemeinsam haben, hilft der Person nicht, die dem Link gefolgt ist.

Für diese Artikel gab es keinen echten Ersatz. Ihre kanonischen URLs und die mir bekannten alten Adressen liefern deshalb 410 Gone. Googles Dokumentation zu Websiteumzügen erklärt, dass 404 oder 410 richtig ist, wenn entfernte Inhalte keinen neuen Ort haben.

Die 410-Seite selbst blieb schlicht. Besucher brauchen nicht die vollständige technische Begründung der Prüfung. Sie müssen wissen, dass ich den Leitfaden entfernt habe, weil ich ihn nicht mehr aktuell und verlässlich pflegen konnte. Türkische Artikel zeigen eine türkische Erklärung, englische eine englische.

Die Umsetzung verlangte mehr als das Löschen von Markdown-Dateien

Die ersten beiden Content-Pruning-Gruppen führten zu diesen Änderungen:

1. Ich nahm 39 Inhaltsdateien aus der Veröffentlichung.
2. Ich entfernte die Seiten aus Sitemap, Kategorien, Tags, hreflang und Inhaltsfeeds.
3. Ich bereinigte interne Links in den verbleibenden Artikeln oder schrieb die betroffenen Sätze um.
4. Ich entfernte veraltete Weiterleitungen, die nicht mehr nötig waren.
5. Ich nahm kanonische URLs und bekannte alte Adressen in ein gemeinsames Register für ausgemusterte Inhalte auf.
6. Ich erstellte türkische und englische 410-Seiten im vorhandenen Design mit Kopf- und Fußbereich der Website.
7. Ich lieferte die statisch erzeugten Seiten über einen Cloudflare Worker mit dem echten Status 410 Gone aus.
8. Ich entfernte Bilder, die kein Artikel mehr verwendete: 30 Dateien in der ersten und 58 in der zweiten Gruppe, insgesamt 88 Bilddateien.

Die Website bleibt statisch. Der Worker läuft nur für die von mir definierten Muster ausgemusterter URLs. Jede normale Seite wird weiterhin direkt als statische Datei ausgeliefert.

Sollte jeder alte Artikel entfernt werden?

Nein. Diese Prüfung zeigte mir das Gegenteil.

Googles Leitfaden für hilfreiche, verlässliche und für Menschen geschriebene Inhalte fragt, ob eine Website einen klaren Zweck hat. Er warnt außerdem davor, große Mengen alter Inhalte nur zu entfernen, damit die Website frischer wirkt. Googles Hinweise zu Core Updates behandeln das Löschen als letztes Mittel.

Mein Ziel war nicht, alte Datumsangaben zu entfernen und Google gegenüber neuer zu wirken. Ich wollte Material nicht länger veröffentlichen, dessen Genauigkeit ich nicht mehr vertreten kann, Projekte ohne brauchbaren Abschluss und Artikel, deren Pflegeaufwand nicht mehr durch das gewünschte Ergebnis gerechtfertigt ist.

Jeder geprüfte Artikel kann zu einem von fünf Ergebnissen führen:

• Behalten: Der Artikel bleibt korrekt, nützlich und erhaltenswert.
• Verbessern: Er besitzt Potenzial, doch Titel, Erklärung oder Passung zur Suchabsicht müssen überarbeitet werden.
• Konsolidieren: Mehrere Seiten zerteilen denselben Bedarf und sollten zu einer echten Hauptressource werden.
• Weniger betonen: Der Artikel bleibt nützlich, soll aber die redaktionelle Hauptrichtung der Website nicht repräsentieren.
• Entfernen: Es fehlen genügend aktuelle Genauigkeit, eigener Wert oder eine Rechtfertigung für die erforderliche Pflege.

Ein aktuelles Beispiel für Konsolidierung

Heute nahm ich sieben türkische und sechs englische Artikel der alten REST-API-Reihe aus der Veröffentlichung. Die Reihe enthielt weiterhin erhaltenswerte Prinzipien. Ihr Lernpfad im Tutorial-Format passte aber nicht mehr zu dem, was Leser in der KI-gestützten Entwicklung brauchen. Ich leitete die alten kanonischen URLs und die bekannten früheren Adressen dauerhaft auf den gleichsprachigen neuen Artikel über REST/API-Qualität in KI-gestützter Entwicklung weiter. Der Ersatz ordnet das Material neu: Welche Entscheidungen gehören in Prompts, Repository-Regeln, Reviews und Auslieferungspipelines, wenn KI-Agenten Code schreiben? Nachdem ich geprüft hatte, dass die Bilder verwaist waren, entfernte ich auch die Dateien, die nur diese Reihe verwendet hatte. Das bedeutet Konsolidieren in der Praxis: nicht Texte zusammenzukleben, sondern nützliche Prinzipien in einem neuen Rahmen zu bewahren, der den heutigen Bedarf der Leser erfüllt.

Als Nächstes muss das Ergebnis gemessen werden

39 Seiten zu entfernen beweist nicht, dass Content Pruning funktioniert hat. Google braucht Zeit, um die URLs erneut zu crawlen und die Änderung zu verarbeiten. Auch für die Leistung der verbleibenden Artikel erwarte ich keine sofortige bedeutsame Veränderung.

Ich werde beobachten, ob:

• ausgemusterte URLs aus dem Index verschwinden;
• eine alte Adresse versehentlich Status 200 liefert oder an eine andere Stelle weiterleitet;
• sich die Sichtbarkeit der technischen Fallstudien verändert, die ich behalten habe;
• geschäftsorientierte Artikel über KI und Prozesse bei relevanteren Suchanfragen erscheinen;
• die durch die Migration entstandenen Unterschiede zwischen Search Console und GA4 kleiner werden.

Die Zahl der gelöschten Seiten ist nicht mein Erfolgsmaß. Die nützlichen Fragen lauten: Bilden die verbleibenden Inhalte ein klareres Ganzes? Kann ich mehr Zeit in die Pflege der Artikel investieren, die ich tatsächlich unterstützen will? Und habe ich aufgehört, alte Antworten zu präsentieren, denen ich selbst nicht mehr vertraue?