Google Core Update

Du oeffnest die Google Search Console und traust deinen Augen kaum. Hunderte Soft 404 Fehler haben sich ueber Nacht aufgetuermt. Dazu noch jede Menge Crawling Fehler, ein AMP Plugin das zickt, und gefuehlt jede zweite URL die auf einem weissen Nichts landet. Glueckwunsch: Du bist in einem Szenario gelandet, das Webmaster jeden Tag schlaflose Naechte mit Tassen von Kaffee beschert.

Aber hier ist die gute Nachricht. All das laesst sich beheben. Und zwar nicht mit Betrinken, weinen, Beten oder Hoffen, sondern mit konkreten, technischen Massnahmen, die du Schritt fuer Schritt umsetzen kannst.

Dieser Dreamcodes Guide ist dein praxiserprobtes Handbuch fuer genau diese Situation. Wir schauen uns gemeinsam an, was Soft 404 Fehler ueberhaupt sind, warum sie sich nach einem Core Update oder nach dem Deaktivieren von Plugins wie AMP explosionsartig vermehren koennen, und wie du mit sauberen 301 Redirects auf Server Ebene sowie einer klugen noindex Strategie wieder Herr der Lage wirst.

Ok, Stop! Etwas zu schnell. Falls du nicht weisst, was ein Soft 404 Fehler eigentlich ist: Soft 404 Fehler entstehen, wenn eine Seite technisch einen HTTP 200 Statuscode zurueckgibt (Seite gefunden), der Inhalt aber leer, duenn oder nicht vorhanden ist. Google erkennt das und wertet es als faktisch nicht vorhandene Seite. Das kostet Crawl-Budget und kann deine gesamte Sichtbarkeit beeintraechtigen.

In diesem Dreamcodes Guide zeigen wir dir:

• Wie Soft 404 Fehler entstehen und wie du sie sicher erkennst
• Auch warum AMP Plugins besonders haeufig solche Fehler ausloesen (Schräg, aber wahr)
• Wie du saubere 301 Redirects auf Server Ebene aufsetzt (mit echtem Code)
• Wann noindex Tags das Crawl Budget retten und wann sie es sabotieren
• Wie du nach einem Google Core Update systematisch vorgehst
• Und zu guter letzt, die haeufigsten Fehler und wie du sie vermeidest

1. Was sind Soft 404 Fehler wirklich?

Stell dir vor, du gehst zu einem Restaurant, fragst nach dem Tagesgericht und der Kellner bringt dir einen leeren Teller. Technisch hat er deinen Auftrag ausgefuehrt. Praktisch hast du nichts bekommen. Genau das ist ein Soft 404 Fehler.

Technisch ausgedrueckt: Der Server liefert einen HTTP Statuscode 200 zurueck, also ein Signal das bedeutet, alles ist gut, Seite existiert. Aber Google schaut sich den Inhalt der Seite an und stellt fest: Da ist nichts Sinnvolles. Keine Inhalte, kaum Text, eine leere Seite oder eine generische Fehlermeldung die dennoch mit einem 200er ausgeliefert wird.

Der Unterschied zum echten 404

Ein echter 404 Fehler ist eigentlich das Ehrlichere. Der Server sagt klar: Diese Seite existiert nicht. Der HTTP Statuscode 404 (Not Found) oder 410 (Gone) teilt dem Googlebot mit: Komm hier nicht mehr vorbei, hier gibt es nichts zu holen.

Der Soft 404 ist dagegen eine Art Luege, die der Server erzaehlt. Er behauptet, alles sei in Ordnung, aber de facto ist die Seite wertlos. Google hat smarte Algorithmen entwickelt, um genau das zu erkennen, und straft es entsprechend ab.

Fehlertyp	HTTP Statuscode	Was Google sieht	SEO Auswirkung
Echter 404	404 Not Found	Seite existiert nicht	Neutral (wenn korrekt)
410 Gone	410 Gone	Seite dauerhaft entfernt	Gut (klares Signal)
Soft 404	200 OK (faelschlicherweise)	Inhalt leer oder sinnlos	Negativ (verschwendet Crawl-Budget)

Typische Ursachen fuer Soft 404 Fehler

Die Bandbreite ist gross. Hier sind die gaengigsten Ausloser, die uns in der Praxis am haeufigsten begegnen:

• Plugin Abschaltung ohne Redirect Bereinigung (klassisches AMP Szenario)
• WooCommerce Produktseiten ohne Produkte oder mit leeren Varianten
• Suchergebnisseiten die keinen Treffer liefern aber trotzdem 200 zurueckgeben
• Paginierungsseiten die nach Content-Loeschung leer laufen (zB. /page/47/)
• Tag und Kategorieseiten ohne zugewiesene Beitraege
• Weiterleitungen auf eine generische Homepage statt auf relevante Inhalte
• JavaScript-Frameworks (React, Vue, Angular) die dynamisch leere Seiten erzeugen

Praxis Erfahrung Ein ecommerce Betreiber mit rund 8.000 Produktseiten deaktivierte nach einem Update ein veraltetes Facetten Navigations Plugin. Resultat: Ueber 2.400 URLs tauchten innerhalb von zwei Wochen als Soft 404 in der Search Console auf. Das Crawl Budget sank messbar, relevante Produktseiten wurden seltener gecrawlt.

2. Das AMP Problem: Wenn ein Plugin zur Fehlerquelle wird

AMP steht fuer Accelerated Mobile Pages, Googles einstiges Lieblingskind fuer schnelle mobile Seiten. Viele WordPress Betreiber haben vor Jahren ein AMP Plugin installiert, weil es fuer bessere Rankings sorgen sollte.

Das Problem: AMP ist technisch komplex. Jede AMP faehige Seite bekommt eine zweite URL mit dem Suffix /amp/ oder ?amp=1. Das verdoppelt schlagartig die Anzahl deiner indexierbaren URLs. Und wenn du das Plugin dann deaktivierst oder entfernst, ohne sauber aufzuraeumen, hinterlassst du ein Trummerfeld.

Was passiert beim Deaktivieren ohne Redirect?

Google hat die AMP URLs gecrawlt und im Index gespeichert. Nutzer haben diese URLs bookmarked. Andere Webseiten verlinken auf sie. Wenn du das Plugin einfach abschaltest, zeigen alle diese URLs auf nichts, oder schlimmer noch: auf eine leere Seite die trotzdem 200 zurueckgibt.

Das Ergebnis siehst du dann in deiner Search Console: Dutzende, manchmal Hunderte Soft 404 Fehler, alle mit dem Muster /beitragsname/amp/ oder /?amp=1.

Die korrekte AMP Abschaltung in drei Phasen

1. Phase 1: Vor dem Deaktivieren (Bestandsaufnahme)

Exportiere alle AMP URLs aus der Google Search Console. Gehe in den Abschnitt Seiten und filtere nach dem AMP Status. Notiere alle URLs die aktuell indexiert sind. Das ist dein Arbeitsvorrat fuer die Redirect Erstellung.

• Phase 2: Redirects einrichten (bevor das Plugin aus ist)

Das ist der entscheidende Schritt. Richte zuerst alle Weiterleitungen ein, und erst dann deaktivierst du das Plugin. Nicht umgekehrt. Sonst hast du eine Zeitluecke in der Googlebot ins Leere laeuft.

• Phase 3: Plugin deaktivieren und Search Console beobachten

Nach dem Einrichten der Redirects kannst du das Plugin deaktivieren. Beobachte in den naechsten Tagen aktiv die Search Console. Neue Fehler sollten nicht auftauchen. Bestehende AMP Fehler werden sich langsam auflosen, da Google die Redirects folgt und den Index aktualisiert.

Wichtig: AMP Redirect in der .htaccess (Apache) Dieser Code muss oberhalb der WordPress-Standardregeln (ueber # BEGIN WordPress) eingefuegt werden:

# AMP zu Non-AMP Weiterleitung RewriteEngine On RewriteCond %{REQUEST_URI} (.+)/amp(/.*)?$ RewriteCond %{REQUEST_URI} !^/wp-content/(.*)$ RewriteRule ^ %1/ [R=301,L]   # Alternativ fuer ?amp=1 Parameter RewriteCond %{QUERY_STRING} ^amp=1$ RewriteRule ^(.*)$ /$1? [R=301,L]

Der Ausschluss des wp content Ordners ist wichtig, weil dort Bilddateien liegen koennen, die AMP im Dateinamen tragen. Die wuerden sonst faelschlicherweise weitergeleitet.

Fuer Nginx Server sieht die entsprechende Konfiguration so aus:

# Nginx: AMP Redirect in server block location ~* ^(.+)/amp(/.*)?$ {     rewrite ^(.+)/amp(/.*)?$ $1/ permanent; }

3. 301 Redirects auf Server Ebene: Sauber und skalierbar

Redirects gibt es wie Sand am Meer. WordPress Plugins, PHP Codes, Datenbank Eintraege … Und die meisten davon haben einen entscheidenden Nachteil: Sie sind langsam, instabil und abhaengig davon, dass WordPress korrekt laeuft.

Ein 301 Redirect auf Server Ebene, also direkt in der .htaccess (Apache) oder in der Nginx Konfiguration, wird ausgefuehrt, bevor WordPress auch nur hochgefahren ist. Kein Plugin Overhead, keine Datenbankabfrage, keine Ladezeit. Der Server sieht die Anfrage, prueft seine Regeln und leitet sofort weiter. Das ist nicht nur schneller, sondern auch deutlich zuverlaessiger.

Wann ist ein Server-Redirect zwingend notwendig?

• Nach dem Loeschen ganzer URL Strukturen (z.B. alle AMP URLs, alte Kategoriepfade)
• Bei Relaunch mit geaenderter URL-Struktur
• Wenn viele URLs gleichzeitig umgeleitet werden muessen (100+)
• Wenn Plugin basierte Redirects Performance-Probleme verursachen
• Bei Migrationen von HTTP zu HTTPS
• Nach Domain-Umzuegen

301 vs. 302: Die richtige Wahl

Diese Unterscheidung klingt technisch, hat aber direkte SEO-Konsequenzen.

Redirect-Typ	Bedeutung	Link-Equity	Wann verwenden
301	Permanent verschoben	Wird uebertragen (~99%)	Seite dauerhaft umgezogen
302	Temporaere Weiterleitung	Wird NICHT uebertragen	Nur kurze Tests
410	Dauerhaft entfernt	Keine (Seite tot)	Inhalt bewusst geloescht

Faustformel Wenn eine Seite fuer immer weg ist und du nichts Passendes zum Weiterleiten hast: 410. Wenn eine Seite umgezogen ist oder du relevanten Inhalt als Ziel hast: 301. Den 302 verwendest du fast nie, ausser bei echten temporaeren Umleitungen waehrend Wartungsarbeiten.

Grundstruktur der .htaccess Weiterleitungen

Hier ist ein sauberes Basis Template, das in der Praxis funktioniert. Die Reihenfolge der Direktiven ist entscheidend:

# =================================== # 301 Redirects – Server-Level # Stand: 2025 # ===================================   # Einzelne URL weiterleiten Redirect 301 /alter-pfad/ https://www.example.de/neuer-pfad/   # Ganze Verzeichnisstruktur weiterleiten RedirectMatch 301 ^/alte-kategorie/(.*)$ https://www.example.de/neue-kategorie/$1   # Alle AMP URLs auf kanonische Version weiterleiten RewriteEngine On RewriteCond %{REQUEST_URI} ^(.+)/amp/?$ RewriteRule ^ %1/ [R=301,L]   # HTTP zu HTTPS (falls noch nicht umgestellt) RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]   # www zu non www (oder umgekehrt, konsistent waehlen!) RewriteCond %{HTTP_HOST} ^www\.example\.de [NC] RewriteRule ^(.*)$ https://example.de/$1 [R=301,L]

Redirect Ketten vermeiden

Ein haesslicher Fehler, den viele machen: Sie bauen Redirect Ketten. URL A leitet auf URL B weiter, URL B leitet auf URL C weiter. Googlebot folgt zwar bis zu 5 Weiterleitungen in einer Kette, aber jeder zusaetzliche Hop kostet Crawl Budget und verlangsamt die Link Equity Uebertragung.

Goldene Regel … Pruefe vor jedem neuen Redirect, ob das Ziel selbst schon weitergeleitet wird. Ein einfaches Tool dafuer: httpstatus.io oder die URL Pruefung in Screaming Frog. Ziel ist immer: genau ein Hop von der alten zur finalen URL.

Massen Redirects mit RegEx effizient erstellen

Wenn du 500 AMP-URLs hast, wirst du nicht 500 einzelne Redirect-Zeilen schreiben wollen. Regular Expressions (RegEx) retten dich hier. Das Muster (.+) fangt den variablen Teil der URL ein und $1 setzt ihn als Platzhalter in die Ziel-URL ein:

# Alle URLs mit /amp/ am Ende auf die Basisseite umleiten RedirectMatch 301 ^/(.*)/amp/?$ https://www.example.de/$1/   # Alte Blogstruktur (/blog/YYYY/MM/slug/) auf neue (/blog/slug/) umleiten RedirectMatch 301 ^/blog/[0-9]{4}/[0-9]{2}/(.+)/?$ https://www.example.de/blog/$1/   # Alle URLs mit ?sessionid= Parameter bereinigen RewriteCond %{QUERY_STRING} ^sessionid= RewriteRule ^(.*)$ /$1? [R=301,L]

4. noindex strategisch einsetzen: Crawl Budget retten

Noindex ist vielleicht das mächtigste und gleichzeitig missverstandenste Werkzeug im technischen SEO Werkzeugkasten. Falsch eingesetzt sabotierst du deine eigene Sichtbarkeit. Richtig eingesetzt sorgst du dafuer, dass Googlebot seine wertvolle Zeit auf deine besten Seiten verwendet.

Was Crawl Budget bedeutet und warum es wichtig ist

Google hat fuer jede Website ein begrenztes Crawl Budget, also eine Menge an Ressourcen, die Googlebot bereit ist, fuer das Crawlen deiner Seite aufzuwenden. Bei kleinen Websites mit 50 Seiten ist das kein Thema. Bei grossen Websites mit Zehntausenden URLs dagegen schon.

Wenn Googlebot sein Budget damit verbringt, leere Kategorieseiten, Suchergebnisseiten ohne Treffer, duplizierte Parameter-URLs und veraltete AMP-Seiten zu crawlen, bleibt weniger Budget fuer deine wichtigen, rankingstarken Seiten. Im schlimmsten Fall werden neue Inhalte tagelang nicht gecrawlt, weil das Budget bereits ausgeschoepft ist.

Die noindex Entscheidungsmatrix

Hier die praktische Entscheidungshilfe, die wir in technischen Audits verwenden:

Seitentyp	Empfehlung	Begruendung
Tag-Seiten mit 1-2 Posts	noindex	Zu duenn fuer eigenstaendigen Mehrwert
Suchergebnisseiten (?s=)	noindex + nofollow	Unendliche URL Variation, kein eigener Wert
Filterseiten ohne Produkte	noindex oder 404	Leerer Inhalt = Soft 404 Gefahr
Paginierung /page/2/ etc.	Indexieren (mit rel=next/prev alt.)	Kann wertvoll sein, wenn Inhalt vorhanden
Danke-Seiten, Login-Seiten	noindex	Keine Suchintention bedienbar
Duplicate Content durch Parameter	Canonical oder noindex	Canonical bevorzugt um Link-Equity zu buendeln

So implementierst du noindex korrekt

Es gibt mehrere Wege, einer Seite das noindex Tag mitzugeben. Der sauberste ist der Meta Tag im HTML Head:

<!– Im <head>-Bereich der Seite –> <meta name=“robots“ content=“noindex, follow“>   <!– Kombination aus noindex und nofollow –> <meta name=“robots“ content=“noindex, nofollow“>   <!– Alternativ: X-Robots-Tag im HTTP-Header –> <!– Fuer nicht-HTML-Ressourcen (PDFs, Bilder) –> Header set X-Robots-Tag „noindex, follow“

In WordPress kannst du noindex Tags ueber dein SEO-Plugin steuern. Yoast SEO, RankMath und Slim SEO bieten alle eine saubere Moeglichkeit, bestimmte Post Typen, Kategorien oder einzelne Seiten auf noindex zu setzen.

Der kritischste Fehler bei noindex

Warnung: Der haeufigste noindex Fehler Niemals eine Seite gleichzeitig in der robots.txt blockieren UND mit noindex ausstatten. Klingt paradox, aber: Wenn Googlebot die Seite nicht crawlen darf (robots.txt), kann er das noindex Tag auch nicht lesen. Die Seite bleibt dann unter Umstaenden weiterhin indexiert, weil Google das noindex nie gesehen hat.

Die Regel lautet: Entweder robots.txt-Blockierung (zum Crawling verhindern) oder noindex (zum Indexierung verhindern). Nie beides auf derselben URL.

5. Systematische Fehlerbereinigung nach einem Core Update

Ein Google Core Update ist keine gezielte Strafe. Es ist eine Neubewertung. Google aktualisiert seine Algorithmen, um Qualitaet besser zu messen, und wenn deine Website technische Leichen mitschleppt (tote URLs, Soft 404 Leichen, Crawl Budget Raeuber), fliegt das jetzt mit hoeherer Wahrscheinlichkeit auf.

Hier ist das praxiserprobte Vorgehen, das nach jedem grossen Core Update funktioniert.

Schritt 1: Bestandsaufnahme in der Search Console

Oeffne die Google Search Console und navigiere zu Indexierung > Seiten. Dort findest du alle URLs aufgelistet, die Google gecrawlt hat, sortiert nach Status. Klicke auf Soft 404 und exportiere die Liste als CSV. Das ist deine Arbeitsbasis.

Was du dabei beachten solltest: Die Search Console zeigt nicht alle Fehler sofort. Es kann sein, dass Google nur eine repraesentative Stichprobe zeigt. Nutze zusaetzlich Screaming Frog (Desktop-Crawler) um deine gesamte Website zu crawlen und eine vollstaendige URL Liste zu erstellen.

Schritt 2: URLs kategorisieren

Nicht jede Soft 404 URL erfordert dieselbe Massnahme. Sortiere die exportierten URLs in drei Gruppen:

• Gruppe A: URL existiert noch, aber Inhalt ist zu duenn. Massnahme: Inhalt verbessern oder 301 auf bessere Seite.
• Gruppe B: URL existiert nicht mehr, aber es gibt eine relevante Alternative. Massnahme: 301 Redirect auf die Alternative.
• Gruppe C: URL existiert nicht mehr, keine sinnvolle Alternative. Massnahme: Echten 410 Status zurueckgeben.

Schritt 3: Massnahmen priorisieren

Starte mit Gruppe B, also mit den URLs, die du sauber weiterleiten kannst. Das gibt schnell positive Signale an Google. Danach kommt Gruppe C (410er setzen), und zuletzt Gruppe A, die Content Verbesserungen erfordern und mehr Zeit kosten.

Schritt 4: Validierung anstossen

Nachdem du Redirects eingerichtet und noindex Tags gesetzt hast, gehe in die Search Console zurueck und klicke auf den Button Fehlerbehebung ueberpruefen. Damit signalisierst du Google, dass die betroffenen URLs erneut gecrawlt werden sollen. Googlebot wird innerhalb von wenigen Tagen bis Wochen vorbeischauen und den Status aktualisieren.

Geduld ist keine Schwaeche Google braucht Zeit. Manchmal Wochen, manchmal Monate, um alle URLs neu zu bewerten und den Status in der Search Console zu aktualisieren. Das bedeutet nicht, dass deine Massnahmen nicht wirken. Behalte die Entwicklung im Blick, aber reagiere nicht panisch auf langsame Fortschritte.

Schritt 5: robots.txt und Sitemap bereinigen

Pruefe deine robots.txt und stelle sicher, dass keine wichtigen Bereiche versehentlich geblockt sind. Dann aktualisiere deine XML-Sitemap: Entferne alle URLs, die du auf noindex gesetzt hast oder die einen 301 Redirect erhalten haben. In der Sitemap sollten nur indexierbare 200 Seiten stehen.

<!– Sitemap sollte NUR diese Seiten enthalten: –> <!– HTTP 200 + kein noindex Tag + kanonische Version –>   <!– NICHT in die Sitemap aufnehmen: –> <!– Seiten mit noindex –> <!– Seiten mit Redirect (301, 302, 410) –> <!– Seiten mit Canonical auf eine andere URL –>

6. Das Crawl Budget aktiv steuern

Crawl Budget Optimierung klingt nach etwas, das nur Enterprise Websites betrifft. Falsch. Sobald deine Website mehr als einige Hundert Seiten hat, zahlt es sich aus, das Crawl Budget bewusst zu steuern.

Was das Crawl Budget beeinflusst

Google berechnet das Crawl Budget fuer jede Website individuell. Zwei Hauptfaktoren spielen eine Rolle:

• Crawl Rate Limit: Wie viele Anfragen dein Server pro Sekunde verarbeiten kann, ohne ueberlastet zu sein. Google respektiert das.
• Crawl Demand: Wie interessant und aktuell Google deine Seiten einschaetzt. Haeufig aktualisierte, verlinkte Seiten werden oefter gecrawlt.

Seiten die Crawl Budget verschwenden ohne Gegenwert sind:

• URL Parameter Variationen (Tracking Parameter, Session-IDs, Sortierfilter)
• Duplizierte Inhalte durch Facettennavigation
• Endlose Paginierungsseiten jenseits der letzten relevanten Seite
• Staging-Umgebungen die versehentlich crawlbar sind
• Testseiten und Drafts die nicht geloescht wurden

Parameter URLs in der Search Console blockieren

Google bietet in der Search Console unter Crawling die Moeglichkeit, bestimmte URL Parameter als unwichtig zu markieren. Das ist besonders sinnvoll fuer Tracking-Parameter wie ?utm_source= oder Sortierparameter wie ?sortby=preis.

Alternativ und technisch sauberer kannst du in der robots.txt bestimmte Parameter Kombinationen blockieren:

User-agent: *   # URL Parameter blockieren die keinen einzigartigen Inhalt erzeugen Disallow: /*?sort= Disallow: /*?filter= Disallow: /*?sessionid= Disallow: /*?ref=   # Staging Umgebungen absolut blocken Disallow: /staging/ Disallow: /test/   # Interne Suchseiten Disallow: /?s= Disallow: /search/

7. Haeufige Fehler und wie du sie vermeidest

Aus Hunderten technischen Audits und Fehlerbereinigungen kondensieren sich immer wieder dieselben Muster. Hier sind die gefaehrlichsten:

Fehler 1: Redirects auf die Homepage

Wenn du keine sinnvolle Zielseite fuer eine geloeschte Seite kennst, leitest du einfach auf die Homepage weiter. Problem: Google erkennt das als Soft Redirect und ignoriert die Weiterleitung fuer Ranking-Zwecke. Besser ist es, entweder eine echte thematisch verwandte Seite zu finden oder gleich einen 410 Status zu setzen.

Fehler 2: noindex vergessen rueckgaengig zu machen

Haesslicher Klassiker: Vor einem Relaunch wird eine Seite oder die ganze Domain mit noindex ausgestattet, damit Google nicht die Baustelle indexiert. Und dann geht der Relaunch live, und keiner entfernt das noindex-Tag. Passiert erschreckend oft. Lege dir immer eine explizite Erinnerung nach dem Go-Live an.

Fehler 3: Zu viele Redirects auf einmal aendern

Wenn du 1.000 URLs gleichzeitig umleitest und dabei Fehler machst, Redirect Schleifen erzeugst oder wichtige URLs versehentlich auf falsche Ziele leitest, kann das kurzfristig Rankings vernichten. Besser: Batch weise vorgehen, maximal 100-200 URLs auf einmal, und jedes Batch validieren bevor das naechste kommt.

Fehler 4: Die Sitemap nicht aktualisieren

Nach einer grossen Bereinigung schlummert in der XML Sitemap oft noch der komplette alte Stand. Wenn du Seiten auf noindex gesetzt oder 301 Redirects eingerichtet hast, muessen diese URLs aus der Sitemap raus. Eine Sitemap mit Redirect URLs oder noindex Seiten ist ein technisches Anti Signal an Google.

Fehler 5: Kanonisierung und noindex mischen

Canonical Tags und noindex erledigen technisch verschiedene Aufgaben. Ein Canonical Tag sagt: Dieser Inhalt existiert auch woanders, das Original ist dort. Ein noindex Tag sagt: Indexiere diese Seite gar nicht. Setze beide Tags auf dieselbe Seite, entsteht ein Widerspruch den Google unterschiedlich ausloesen kann. Nutze entweder das eine oder das andere, nicht beides kombiniert.

8. Profi Tipps fuer technisch saubere Websites

Tipp 1: Log Datei Analyse als Diagnose Werkzeug

Die Search Console zeigt dir Symptome. Deine Server Logfiles zeigen dir die Ursache. In den Access Logs siehst du, welche URLs der Googlebot wie haeufig besucht, wo er auf Fehler stoesst und ob er Redirect-Ketten aufloest. Tools wie GoAccess (kostenlos) oder Logfile-Analyser in Screaming Frog machen das auswertbar.

Tipp 2: Crawl Budget Report in der Search Console

Unter Einstellungen findest du in der Search Console den Crawling Statistik-Bericht. Dort siehst du, wie oft Googlebot deine Seite besucht, welche Antwort Codes er erhaelt und ob die Crawl Rate im Zeitverlauf zurueckgeht. Ein Rueckgang der Crawl Aktivitaet nach einem Update ist oft ein fruehes Warnsignal.

Tipp 3: Screaming Frog regelmaessig einsetzen

Screaming Frog ist das Schweizer Taschenmesser fuer technisches SEO. Crawle deine Website mindestens einmal pro Quartal damit und achte besonders auf: 404 Fehler, Redirect-Ketten, fehlende oder doppelte Title Tags und Seiten mit zu wenig Content (unter 300 Woerter).

Tipp 4: Stagierungs Domain absichern

Deine Staging Umgebung muss absolut nicht crawlbar sein. Nutze HTTP Basic Authentication als erste Schicht, ergaenze noindex im Meta Tag als zweite Schicht und blocke Googlebots in der robots.txt als dritte Schicht. Drei Sicherheitsebenen fuer etwas, das trotzdem regelmaessig schieflaeuft.

Tipp 5: Automatisierte Ueberwachung einrichten

Richte in der Google Search Console eMail Benachrichtigungen ein. Aktiviere ausserdem ein externes Monitoring (zB. UptimeRobot oder Pingdom) das dich sofort benachrichtigt, wenn deine Website oder wichtige URLs nicht mehr erreichbar sind. Probleme erkennen bevor Google sie erkennt, das ist das Ziel.

9. Praxisbeispiel: Komplette Bereinigung nach AMP Abschaltung

Lasse uns das alles an einem konkreten Beispiel durchspielen. Angenommen: Du betreibst einen WordPress Blog mit 800 Artikeln. Du hast vor drei Jahren das offizielle AMP Plugin installiert. Jetzt willst du es loswerden, weil du auf Core Web Vitals optimierst und AMP mehr Aufwand als Nutzen bringt.

Ausgangssituation

• 800 Blogposts, alle mit /amp/-Version indexiert
• Insgesamt also rund 1.600 indexierte URLs
• AMP-URLs machen etwa 35 Prozent des organischen Traffics aus

Tag 1: Vorbereitung

• Search Console exportieren: Alle AMP-URLs herunterladen (Bereich Seiten, Filter AMP)
• Redirect Regel via .htaccess einrichten (RegEx Muster fuer alle /amp/ URLs)
• Redirect testen: 5-10 AMP URLs manuell mit dem Browser oder httpstatus.io testen
• Curl-Test auf dem Server durchfuehren zur Bestaetigung

# Testen ob Redirect korrekt funktioniert: curl -I https://www.example.de/mein-artikel/amp/   # Erwartete Ausgabe: HTTP/2 301 location: https://www.example.de/mein-artikel/

Tag 2: Plugin deaktivieren

• AMP-Plugin in WordPress deaktivieren
• Website im Inkognito-Modus testen: Keine /amp/ URL sollte noch AMP Inhalte liefern
• Screaming Frog Crawl: Alle URLs in der exportierten Liste pruefen ob 301 korrekt antwortet
• Search Console: URL Prueftool fuer 3-5 ehemalige AMP URLs manuell pruefen

Woche 2 – 4: Monitoring

Beobachte taeglich die Search Console. Die AMP URLs werden schrittweise aus dem Index entfernt oder auf die neuen kanonischen URLs umgeschwenkt. Der organische Traffic ueber AMP URLs wird sich auf die normalen URLs verlagern. Insgesamt sollte sich der Traffic stabilisieren oder leicht steigen, da die Link Equity nun gebundelt auf den kanonischen URLs liegt.

10. FAQ: Die wichtigsten Fragen und Antworten

Wie lange dauert es, bis Google Soft 404 Fehler aktualisiert?

Das ist leider keine exakte Wissenschaft. Bei grossen Websites mit viel Crawl Budget: ein bis vier Wochen. Bei kleineren Websites: vier bis zwolf Wochen. Wichtig: Habe Geduld. Solange die technischen Fixes korrekt umgesetzt sind, lauft der Prozess. Druck durch erneute Validierungs Anfragen in der Search Console kann den Prozess leicht beschleunigen.

Soll ich alle Soft 404 Fehler beheben?

Nein. Wenn eine URL keine externen Backlinks hat, keinen organischen Traffic hatte und kein Ranking Potenzial besitzt, kann ein 410 Status die effizienteste Loesung sein. Konzentriere dich zuerst auf URLs mit Backlinks, historischem Traffic oder thematischer Relevanz fuer deine Kernthemen.

Kann ein Core Update dauerhaften Rankingverlust verursachen?

Ja. Wenn Google systematisch feststellt, dass deine Website schwache Inhaltsqualitaet, technische Fehler oder ein schlechtes Nutzererlebnis bietet, koennen Rankings dauerhaft sinken. Die Erholung setzt erst beim naechsten Core Update ein, wenn Google deine verbesserte Website neu bewertet. Schnelle Fixes allein helfen wenig, wenn die inhaltliche Qualitaet grundsaetzlich schwach ist.

Was ist besser: noindex oder den Inhalt verbessern?

Kommt auf die Ressourcen an. Wenn du die Kapazitaet hast, den Inhalt zu einer echten, hilfreichen Seite auszubauen: Immer Inhalt verbessern und indexieren lassen. Wenn du Dutzende Seiten mit strukturell schwachem Inhalt hast und keine Kapazitaet: noindex als kurzfristige Massnahme, um das Crawl Budget zu schuetzen, bis du die Seiten richtig aufbauen kannst.

Brauche ich fuer jeden Redirect ein Plugin?

Nein. Fuer Massen-Redirects und strukturelle Weiterleitungen (zB. alle AMP URLs) ist die .htaccess oder Nginx Konfiguration auf Server Ebene die bessere Wahl. Fuer einzelne, gelegentliche Redirects ist ein Plugin wie Redirection bequemer und fuer Nicht Server Admins zugaenglicher.

Verliere ich Backlink Wert durch 301 Redirects?

Frueherer Mythos: 301 Redirects uebertragen nur einen Teil des Link Equity. Das hat Google mehrfach bestaetigt und relativiert. Aktuelle Aussagen von Google Mitarbeitern deuten darauf hin, dass ein sauberer 301 Redirect den Grossteil des Link Equity uebertraegt. Redirect Ketten (mehrere Hops) verlieren dagegen tatsaechlich an Uebertragungsqualitaet.

Wie erkenne ich ob meine robots.txt korrekt ist?

Die einfachste Methode: Google Search Console, Abschnitt robots.txt-Tester (unter Crawling). Dort kannst du einzelne URLs eingeben und sehen, ob sie blockiert wuerden. Alternativ: robots.txt direkt unter domain.de/robots.txt aufrufen und manuell pruefen.

Abschluss: Technische Sauberkeit als Wettbewerbsvorteil

Google Core Updates werden nicht aufhoeren. Sie werden haeufiger, praeziser und smarter. Was sich aendert, ist die Faehigkeit von Google, schlechte Technik, duenne Inhalte und verschwendetes Crawl Budget zu erkennen und abzustrafen.

Der gute Teil daran: Wer seinen technischen Haushalt in Ordnung haelt, hat einen messbaren Wettbewerbsvorteil. Nicht weil er Google austrickst, sondern weil Google gute Technik belohnt. Schnelle Server, saubere Redirect Strukturen, kein Ballast im Index, klare Crawling Signale. Das ist keine dunkle Kunst. Das ist Handwerk.

Nimm dir nach jedem Core Update zwei bis drei Stunden Zeit, deine Search Console zu analysieren. Exportiere die Fehler URLs. Kategorisiere sie. Und dann arbeite die Liste durch. Nicht in Panik, sondern systematisch.

Denn am Ende gilt eine simple Wahrheit: Google liebt Websites, die fuer echte Menschen gebaut sind und technisch einwandfrei funktionieren. Alles andere ist Laerm.