Content-Audits durchführen: Unterperformende Seiten identifizieren

1. Warum Content-Audits für große Kataloge unverzichtbar sind

Große Magento-Shops mit mehreren tausend Produkten, hunderten Kategorien und Jahren an Blog-Content sammeln zwangsläufig eine Menge Seiten an, die längst nicht mehr zur Sichtbarkeit oder zum Umsatz beitragen. Automatisch generierte Layered-Navigation-Seiten, Blogartikel aus 2019 mit veralteten Magento-1-Referenzen oder nahezu identische Kategorievarianten summieren sich zu einem digitalen Ballast, den Google und Nutzer gleichermaßen registrieren. Ohne systematischen Content-Audit bleibt dieser Ballast unsichtbar, bis er sich in sinkenden Rankings und schrumpfendem organischem Traffic bemerkbar macht.

Googles Helpful-Content-System bewertet nicht mehr nur einzelne Seiten isoliert, sondern zieht Rückschlüsse aus der Gesamtqualität einer Domain. Ein hoher Anteil an dünnem oder veraltetem Content kann dadurch auch starke, gut gepflegte Seiten in Mitleidenschaft ziehen. Hinzu kommt das begrenzte Crawl-Budget: Bei einem Katalog mit 50.000 URLs verschwendet Googlebot Ressourcen auf wertlose Filterkombinationen, statt neue Produkte oder aktualisierte Kategorieseiten zeitnah zu erfassen. Ein regelmäßiger Content-Audit ist deshalb kein einmaliges Aufräumprojekt, sondern fester Bestandteil einer nachhaltigen SEO-Strategie für große Kataloge.

2. Audit-Methodik: Inventar, Performance-Daten, Qualitätsbewertung

Ein belastbarer Content-Audit läuft in drei klar getrennten Phasen ab: Inventar, Performance-Daten und Qualitätsbewertung. In der Inventarphase wird die gesamte Domain gecrawlt - etwa mit Screaming Frog oder Sitebulb - und jede URL mit Seitentyp, Indexierbarkeit, Canonical-Ziel und HTTP-Status erfasst. Erst dieses vollständige Inventar macht sichtbar, wie viele Kategorie-, Produkt- und CMS-Seiten überhaupt existieren, bevor irgendeine Bewertung stattfindet.

In der zweiten Phase werden die Inventar-URLs mit Performance-Daten aus Search Console und Analytics angereichert: Impressionen, Klicks, durchschnittliche Position, Sitzungen und Engagement-Rate pro URL. Die dritte Phase, die Qualitätsbewertung, kombiniert quantitative Signale wie Wortanzahl und Duplicate-Content-Anteil mit einer stichprobenartigen manuellen Prüfung, ob eine Seite fachlich noch korrekt und für Nutzer tatsächlich hilfreich ist. Das Ergebnis ist eine zentrale Tabelle oder Datenbank, die als Grundlage für alle folgenden Entscheidungen dient.

{
  "url": "https://mironsoft.de/damen/jacken/winterjacken.html",
  "pageType": "category",
  "pageviews": 42,
  "impressions": 1180,
  "clicks": 9,
  "avgPosition": 34.6,
  "wordCount": 187,
  "lastModified": "2023-11-02",
  "backlinks": 0,
  "decision": "improve",
  "notes": "Automatisch generierte Filterkombination, kein eigener Einleitungstext"
}

3. Search Console und Analytics als Datenquellen für Content-Decay

Content-Decay beschreibt den schleichenden Rückgang von organischem Traffic und Rankings einer Seite, die früher gut performt hat. Die Search-Console-Leistungsberichte sind die zuverlässigste Datenquelle dafür, weil sie Impressionen und Klicks pro URL über lange Zeiträume liefern. Ein Vergleich der letzten zwölf Monate mit den zwölf Monaten davor - gefiltert nach Seiten mit sinkenden Klicks bei gleichbleibenden oder steigenden Impressionen - macht Decay sichtbar, bevor er in den Umsatzzahlen ankommt.

Google Analytics 4 ergänzt diese Sicht um Engagement-Metriken: durchschnittliche Interaktionszeit, engagierte Sitzungen und die Conversion-Rate pro Landingpage zeigen, ob eine Seite trotz stabiler Rankings an Relevanz für Nutzer verliert. Für große Kataloge lohnt sich der Export über die Search-Console-API oder eine BigQuery-Anbindung, weil das UI-Interface bei mehreren zehntausend URLs schnell an Grenzen stößt und keine Bulk-Exports mit Custom-Dimensionen erlaubt.

#!/usr/bin/env bash
# Export URL inventory plus Search Console clicks/impressions into one CSV

# 1. Crawl inventory export from Screaming Frog (headless mode)
screamingfrog --crawl "https://mironsoft.de" \
  --headless --save-crawl \
  --output-folder ./audit --export-tabs "Internal:HTML"

# 2. Pull Search Console performance data via the API (last 12 months)
gsc-cli query \
  --site-url "https://mironsoft.de" \
  --start-date "$(date -d '12 months ago' +%F)" \
  --end-date "$(date +%F)" \
  --dimensions page \
  --metrics clicks,impressions,ctr,position \
  --output ./audit/gsc-performance.json

# 3. Join crawl inventory with GSC data on the URL column and write one CSV
jq -s '
  .[0].rows as $gsc |
  .[1] | map(. as $row |
    ($gsc[] | select(.keys[0] == $row.url)) as $metrics |
    { url: $row.url, wordCount: $row.wordCount,
      clicks: $metrics.clicks, impressions: $metrics.impressions }
  )
' ./audit/gsc-performance.json ./audit/internal_html.json \
  | jq -r '(.[0] | keys_unsorted), (.[] | [.[]]) | @csv' \
  > ./audit/content-audit-inventory.csv

echo "Inventory with GSC metrics written to content-audit-inventory.csv"

4. Thin und veralteter Content: Erkennungsmerkmale

Thin Content zeigt sich in Magento-Shops in wiederkehrenden Mustern: automatisch generierte Layered-Navigation-Seiten mit austauschbarem Text, Produktseiten mit reiner Herstellerbeschreibung ohne eigene Ergänzung, sowie Kategorieseiten, die nur aus einer Produktliste ohne einleitenden Text bestehen. Ein verlässliches quantitatives Signal ist eine Wortanzahl unter 300 Wörtern kombiniert mit null Impressionen über die letzten zwölf Monate - diese Kombination deutet fast immer auf eine Seite hin, die weder für Google noch für Nutzer einen eigenständigen Mehrwert bietet.

Veralteter Content zeigt sich anders: Blogartikel, die noch Magento-1-Befehle oder längst abgelöste Extensions referenzieren, Screenshots mit alter Admin-Oberfläche oder Preisangaben, die seit Jahren nicht aktualisiert wurden. Bis zur Überarbeitung lässt sich eine identifizierte Thin-Content-Seite temporär mit einem Canonical-Tag auf eine themenverwandte, stärkere Seite sowie einem noindex-Meta-Tag entschärfen, damit sie kein Crawl-Budget mehr bindet, ohne sofort gelöscht werden zu müssen.

<!-- Temporary tag pattern for a thin category page pending improvement -->
<head>
  <!-- Points crawlers and users to the stronger, related page -->
  <link rel="canonical" href="https://mironsoft.de/damen/jacken/winterjacken.html">

  <!-- Keeps this specific thin variant out of the index while it is queued for a refresh -->
  <meta name="robots" content="noindex, follow">
</head>

5. Das Prune-Improve-Keep-Framework

Das Prune-Improve-Keep-Framework übersetzt die gesammelten Daten in drei klare Handlungsoptionen. Prune bedeutet, eine Seite per 301-Redirect zu konsolidieren, per 410 zu entfernen oder dauerhaft auf noindex zu setzen - passend für Seiten ohne Traffic, ohne Backlinks und ohne strategischen Wert. Improve betrifft Seiten mit vorhandenem, aber sinkendem Potenzial: Sie erhalten aktualisierten Content, zusätzliche Tiefe oder ein internes Verlinkungs-Update. Keep markiert Seiten, die bereits gut performen und unverändert bleiben, abgesehen von normaler technischer Pflege.

Die Entscheidung basiert nicht auf Bauchgefühl, sondern auf einer Kombination aus Traffic-Trend, Geschäftswert und Aufwand. Eine Kategorieseite mit sinkendem Traffic, aber hohem Umsatzbeitrag gehört fast immer in Improve, während eine Blogseite ohne Traffic, ohne Backlinks und ohne thematische Relevanz zum aktuellen Sortiment ein klarer Prune-Kandidat ist. Ein einfacher, reproduzierbarer Score aus diesen Faktoren macht die Klassifizierung für hunderte Seiten gleichzeitig handhabbar, statt jede Seite einzeln zu diskutieren.

// Compute a simple decay score and a prune/improve/keep recommendation
function classifyPage(page) {
  const monthsSinceUpdate = monthsBetween(page.lastModified, new Date());
  const trafficTrend = page.clicksLast12m > 0
    ? (page.clicksLast12m - page.clicksPrev12m) / page.clicksPrev12m
    : -1;

  // Weighted decay score: negative traffic trend and content age both increase decay
  const decayScore = (trafficTrend * -50) + (monthsSinceUpdate * 1.5)
    - (page.wordCount < 300 ? 20 : 0)
    + (page.backlinks > 0 ? -15 : 0);

  if (page.impressions === 0 && page.wordCount < 300) {
    return { decision: 'prune', decayScore };
  }
  if (decayScore > 40) {
    return { decision: 'improve', decayScore };
  }
  return { decision: 'keep', decayScore };
}

function monthsBetween(fromDate, toDate) {
  const from = new Date(fromDate);
  const diff = (toDate.getFullYear() - from.getFullYear()) * 12
    + (toDate.getMonth() - from.getMonth());
  return diff;
}

6. Priorisierung: Welche Seiten zuerst bearbeitet werden

Nicht jede identifizierte Problemseite kann gleichzeitig bearbeitet werden, deshalb braucht der Audit eine klare Priorisierung nach Aufwand und potenziellem Impact. Die schnellsten Erfolge liefern Seiten in Position 8 bis 20, die einst weiter oben rankten und mit moderater Überarbeitung realistisch wieder auf die erste Ergebnisseite zurückkehren können. Diese Quick Wins sollten vor aufwendigen Neukonzeptionen priorisiert werden, weil sie den größten Effekt pro investierter Stunde liefern.

Kategorieseiten mit kommerzieller Absicht haben grundsätzlich Vorrang vor informativen Blogartikeln, weil sie direkter zum Umsatz beitragen. Innerhalb der Kategorieseiten priorisieren erfahrene Teams zusätzlich nach Sortimentsgröße und Margenbeitrag der jeweiligen Produktgruppe. Eine einfache Aufwand-Impact-Matrix, in der jede Seite nach geschätztem Zeitaufwand und erwartetem Traffic- oder Umsatzgewinn eingeordnet wird, macht die Reihenfolge für das gesamte Team nachvollziehbar und verhindert, dass Ressourcen in Seiten mit geringem Hebel fließen.

7. Von der Analyse zur Umsetzung: Redirects, Konsolidierung, Refresh

Nach der Entscheidung folgt die technische Umsetzung, die je nach Kategorie unterschiedlich aussieht. Bei Prune-Entscheidungen zur Konsolidierung zweier thematisch überlappender Seiten wird die schwächere URL per 301-Redirect auf die stärkere umgeleitet, ihre internen Links werden aktualisiert, und die Zielseite übernimmt die wertvollsten Inhaltsteile der entfernten Seite. So bleibt vorhandene Linkkraft erhalten, statt beim Löschen verloren zu gehen.

Bei Improve-Entscheidungen bedeutet Umsetzung konkret: Inhalt um fehlende Aspekte ergänzen, veraltete Fakten und Screenshots austauschen, das Veröffentlichungsdatum sichtbar aktualisieren und interne Links von thematisch verwandten, stärkeren Seiten ergänzen. Wichtig ist, jede Umsetzung im Ticket-System zu dokumentieren und nach vier bis acht Wochen erneut in Search Console zu prüfen, ob sich Impressionen und Klicks wie erwartet erholen - nur so lässt sich der Erfolg des Audits objektiv messen.

<!-- Magento url_rewrite entry: 301 redirect a thin category page onto the consolidated target -->
<config>
    <!-- Equivalent to an INSERT into the core_url_rewrite / url_rewrite table -->
    <!--
        request_path:   damen/jacken/winterjacken-slim.html
        target_path:    damen/jacken/winterjacken.html
        redirect_type:  301
        entity_type:    custom
        store_id:       1
    -->
</config>

<!-- Layout XML fallback: redirect handled in a controller plugin when url_rewrite rows are managed via Composer/CI -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <!-- Consolidated target page keeps the merged content block from the pruned page -->
        <referenceContainer name="content">
            <block class="Mironsoft\ContentAudit\Block\ConsolidatedIntro"
                   name="content_audit.consolidated_intro"
                   template="Mironsoft_ContentAudit::consolidated-intro.phtml"/>
        </referenceContainer>
    </body>
</page>

8. Audit-Workflow für einen großen Produktkatalog

Für einen Magento-Katalog mit mehreren zehntausend Produkt- und Kategorieseiten braucht der Audit einen wiederholbaren Workflow statt einer manuellen Einzelfallprüfung. Der Prozess beginnt mit einem vollständigen Crawl über Screaming Frog, kombiniert mit einem Export der url_rewrite-Tabelle direkt aus der Magento-Datenbank, um auch nicht verlinkte, aber indexierte URLs zu erfassen. Anschließend werden Crawl-Daten, Search-Console-Export und Analytics-Export über die URL als Schlüssel in einer BigQuery-Tabelle oder einem Spreadsheet zusammengeführt.

Die Segmentierung nach Attribut-Set, Kategorieebene und Seitentyp erlaubt es, Muster zu erkennen, die bei Einzelbetrachtung untergehen würden - etwa dass sämtliche automatisch generierten Filterseiten einer bestimmten Attributkombination systematisch dünn sind. Ein quartalsweiser Audit-Zyklus mit fest zugewiesenen Verantwortlichkeiten pro Kategorie-Cluster verhindert, dass sich der Rückstand erneut aufbaut, und macht Fortschritt über Search-Console-Trends messbar und dem Team gegenüber nachvollziehbar.

9. Content-Audit-Entscheidungen im direkten Vergleich

Jedes Audit-Signal hat einen eigenen Schwellenwert, eine klare Entscheidungsrichtung und eine konkrete Maßnahme. Die folgende Übersicht fasst zusammen, wie sich die wichtigsten Signale in eine Prune-, Improve- oder Keep-Entscheidung übersetzen lassen.

In der Praxis überschneiden sich die Signale häufig: Eine Seite mit sinkendem Traffic, aber vorhandenen Backlinks und Conversion-Beitrag landet fast immer bei Improve statt bei Prune. Wer die Tabelle als Entscheidungsraster für jede einzelne Seite konsequent anwendet, vermeidet subjektive Einzelentscheidungen und macht den Audit über hunderte Seiten hinweg konsistent.

10. Zusammenfassung

Ein systematischer Content-Audit löst ein Kernproblem großer Magento-Kataloge: Über Jahre gewachsener Content lässt sich nicht mehr aus dem Bauch heraus bewerten. Inventar, Performance-Daten aus Search Console und Analytics sowie eine strukturierte Qualitätsbewertung liefern die Grundlage, um Thin und veralteten Content zuverlässig zu identifizieren. Das Prune-Improve-Keep-Framework übersetzt diese Daten in klare, reproduzierbare Entscheidungen statt Einzelfalldiskussionen für jede der tausenden Seiten.

Der entscheidende Hebel liegt in der Priorisierung nach Aufwand und Impact sowie in der konsequenten technischen Umsetzung über 301-Redirects, Konsolidierung und gezielte Refreshs. Für große Kataloge lohnt sich ein wiederkehrender, quartalsweiser Audit-Workflow mit klaren Verantwortlichkeiten, damit Content-Decay frühzeitig erkannt wird, statt erst nach spürbaren Traffic-Verlusten sichtbar zu werden.

11. FAQ: Content-Audits durchführen