Website

Defekte Website-Änderung mit Versions-Snapshots finden und rückgängig machen

Verfolgt einen kürzlich aufgetretenen Fehler auf einer gehosteten Website bis zum verursachenden Snapshot und zur betroffenen Datei zurück, vergleicht die Datei vorher und nachher und stellt nach deiner Freigabe nur das Nötige wieder her.

Wann du ihn nutzt

Wenn auf deiner gehosteten Website nach einer Änderung etwas kaputtgegangen ist und du die Ursache finden und sicher rückgängig machen willst.

Was du bekommst

Die verursachende Datei, anhand von Snapshots identifiziert und mit Vorher-Nachher-Diff, die kleinstmögliche Wiederherstellung nach deiner Freigabe, live bestätigt, plus eine 4-Zeilen-Störungsnotiz fürs Management.

Ändert er etwas in meinem Konto?

Nur mit deiner Freigabe. Der Assistent zeigt zuerst eine Vorschau jeder Änderung und wartet auf dein Okay.

Vor dem Senden ausfüllen

[URL der betroffenen Seite][ungefährer Zeitpunkt der Änderung]

Auf meiner gehosteten Website ist nach einer kürzlichen Änderung etwas kaputtgegangen: [Symptom beschreiben, z. B. Formular fehlt, Layout auf Mobilgeräten defekt]. Finde die Ursache und mach sie mit dem kleinstmöglichen Rollback rückgängig. 0. Liste zuerst meine Server und Websites auf. Versions-Snapshots gibt es nur auf Opus-Growth-Hosting-Servern. Wenn [URL der betroffenen Seite] zu einer WordPress-Website gehört, die über das Plugin verbunden ist, brich ab und sag mir Bescheid, denn diese Rollback-Methode greift dort nicht. Wenn auf dem Server mehrere Websites laufen, nimm die Website, die [URL der betroffenen Seite] ausliefert. 1. Lies [URL der betroffenen Seite] live aus: HTTP-Status, Response-Header und HTML (bei großen Seiten die Outline-Ansicht verwenden). Erstelle Screenshots für Desktop und Mobil. 2. Liste die automatischen Snapshots auf und blättere zurück, bis die letzten 14 Tage abgedeckt sind. Wähle die Snapshots rund um [ungefährer Zeitpunkt der Änderung]. Snapshots enthalten Zeit und Label, aber nicht den Namen der Person, die die Änderung vorgenommen hat. Stütze dich also nur auf Zeit und Label und rate nicht, wer was geändert hat. 3. Zeige für jede verdächtige Datei den Diff zwischen dem Snapshot kurz vor der Änderung und der aktuellen Datei. Lies die aktuelle Datei, wenn du mehr Kontext brauchst. Erkläre in einfachen Worten, was sich geändert hat und warum das das Symptom verursacht. 4. Empfiehl die engste mögliche Korrektur: eine Datei, einen Ordner oder die ganze Website nur dann, wenn mehrere Dateien betroffen sind. Liste alle späteren Änderungen seit diesem Snapshot auf, die dabei ebenfalls verloren gingen. Wenn die Website einen Quellordner .src/ hat (ein Build-Projekt), weise mich darauf hin, dass eine Wiederherstellung beim nächsten Rebuild überschrieben wird, sofern die Korrektur nicht auch in die Quelle übernommen wird. Führe die Wiederherstellung zuerst als Vorschau aus und zeig sie mir. Wende nichts an, bevor ich zugestimmt habe. Nach meiner Freigabe: Stelle wieder her, lies die Seite erneut live aus, erstelle neue Screenshots und bestätige, dass das Symptom verschwunden und der Status 200 ist. Schließe mit einer Incident-Notiz in 4 Zeilen für das Management ab: was kaputtging, wann (basierend auf den Snapshot-Zeiten), Dauer der Auswirkung und was wiederhergestellt wurde.

0. Liste zuerst meine Server und Websites auf. Versions-Snapshots gibt es nur auf Opus-Growth-Hosting-Servern. Wenn [URL der betroffenen Seite] zu einer WordPress-Website gehört, die über das Plugin verbunden ist, brich ab und sag mir Bescheid, denn diese Rollback-Methode greift dort nicht. Wenn auf dem Server mehrere Websites laufen, nimm die Website, die [URL der betroffenen Seite] ausliefert.

1. Lies [URL der betroffenen Seite] live aus: HTTP-Status, Response-Header und HTML (bei großen Seiten die Outline-Ansicht verwenden). Erstelle Screenshots für Desktop und Mobil.

2. Liste die automatischen Snapshots auf und blättere zurück, bis die letzten 14 Tage abgedeckt sind. Wähle die Snapshots rund um [ungefährer Zeitpunkt der Änderung]. Snapshots enthalten Zeit und Label, aber nicht den Namen der Person, die die Änderung vorgenommen hat. Stütze dich also nur auf Zeit und Label und rate nicht, wer was geändert hat.

3. Zeige für jede verdächtige Datei den Diff zwischen dem Snapshot kurz vor der Änderung und der aktuellen Datei. Lies die aktuelle Datei, wenn du mehr Kontext brauchst. Erkläre in einfachen Worten, was sich geändert hat und warum das das Symptom verursacht.

4. Empfiehl die engste mögliche Korrektur: eine Datei, einen Ordner oder die ganze Website nur dann, wenn mehrere Dateien betroffen sind. Liste alle späteren Änderungen seit diesem Snapshot auf, die dabei ebenfalls verloren gingen. Wenn die Website einen Quellordner .src/ hat (ein Build-Projekt), weise mich darauf hin, dass eine Wiederherstellung beim nächsten Rebuild überschrieben wird, sofern die Korrektur nicht auch in die Quelle übernommen wird.

Führe die Wiederherstellung zuerst als Vorschau aus und zeig sie mir. Wende nichts an, bevor ich zugestimmt habe. Nach meiner Freigabe: Stelle wieder her, lies die Seite erneut live aus, erstelle neue Screenshots und bestätige, dass das Symptom verschwunden und der Status 200 ist.

Schließe mit einer Incident-Notiz in 4 Zeilen für das Management ab: was kaputtging, wann (basierend auf den Snapshot-Zeiten), Dauer der Auswirkung und was wiederhergestellt wurde.

In Claude öffnen In ChatGPT öffnen Im Forum diskutieren

Diese Prompts funktionieren am besten, wenn dein KI-Assistent über Opus Growth mit deinen Konten verbunden ist.

Konten kostenlos verbinden

Weitere Prompts

WebsiteÄndert nach deiner Freigabe

Meta-Titel und -Beschreibungen für Seiten mit niedriger organischer CTR neu schreiben

Findet Seiten auf Seite 1 mit vielen Impressionen, aber wenigen Klicks, vergleicht sie mit der CTR deiner gesamten Website und schreibt Meta-Titel und -Beschreibung passend zu den Suchanfragen, die tatsächlich Traffic bringen, neu.

Wann du ihn nutztWenn deine Seiten auf Seite eins ranken und Impressionen bekommen, aber kaum geklickt werden, weil Titel und Beschreibungen wohl nicht überzeugen.

Verwende die Search-Console-Property [Search Console property] und die WordPress-Website [WordPress site].

Schritt 1. Baseline. Hole die letzten 90 Tage mit der Dimension "date" und addiere die gesamten Klicks und die gesamten Impressionen. Durchschnittliche Website-CTR = Gesamtklicks / Gesamtimpressionen. Zeige diese Zahl zuerst an.

Schritt 2. Kandidaten. Hole die letzten 90 Tage nach Seite, sortiert nach Impressionen. Behalte Seiten mit mindestens 500 Impressionen, einer durchschnittlichen Position zwischen 1 und 10 und einer CTR unter 2 %. Nimm die Top 10 nach Impressionen.

Schritt 3. Für jede dieser 10 Seiten:
- Hole die Suchanfragen nur für diese Seite (Dimension "query", gefiltert auf die Seiten-URL, sortiert nach Impressionen) und behalte die Top 5.
- Finde die passende WordPress-Beitrags- oder Seiten-ID, indem du nach dem Slug suchst. Wenn eine URL keine eindeutige Zuordnung hat (Archiv, Kategorie, Startseite), markiere sie und mach weiter.
- Lies den aktuellen Meta-Titel und die aktuelle Meta-Beschreibung aus dem SEO-Plugin.

Überspringe jede Seite, deren aktueller Titel bereits die Haupt-Suchanfrage enthält UND deren CTR innerhalb von 20 % des Website-Durchschnitts aus Schritt 1 liegt. Nenne den Grund für das Überspringen.

Liefere eine Tabelle mit diesen Spalten: URL, Beitrags-ID, Impressionen, CTR, Position, Haupt-Suchanfragen, aktueller Titel, aktuelle Beschreibung, vorgeschlagener Titel, vorgeschlagene Beschreibung.
- Vorgeschlagener Titel: max. 60 Zeichen, Haupt-Suchanfrage möglichst am Anfang.
- Vorgeschlagene Beschreibung: max. 155 Zeichen, ein konkreter Nutzen und ein Call-to-Action.
- Verwende nur Fakten, die auf der Seite stehen. Erfinde keine Preise, Garantien oder Zahlen.

Diese Tabelle ist die Vorschau. Schreibe keine SEO-Felder, bevor ich zugestimmt habe. Schreibe nach meiner Freigabe nur die freigegebenen Zeilen (überschreibe die bestehenden Werte nur für diese Zeilen), leere dann den Cache, damit die neuen Tags live gehen, und lies die SEO-Felder jeder geänderten Seite erneut aus, um zu bestätigen, dass sie übernommen wurden.

WebsiteÄndert nach deiner Freigabe

Die Website-Navigation rund um Seiten aufbauen, die wirklich konvertieren

Gleicht die GA4-Landingpage-Performance mit deinen WordPress-Menüs ab, markiert wertvolle Seiten, die in der Navigation fehlen, toten Ballast und defekte Links, und schlägt ein schlankeres Hauptmenü vor.

Wann du ihn nutztWenn dein Website-Menü überladen oder veraltet wirkt und Besucher vermutlich nicht zu den Seiten führt, die wirklich konvertieren.

Vergleiche mein Navigationsmenü mit dem, was tatsächlich konvertiert.

Hole aus der GA4-Property [GA4 property] die letzten 90 Tage nach Landingpage: Sitzungen und Key Events. Berechne die Key-Event-Rate als Key Events / Sitzungen.

Lies dann alle Menüs auf [WordPress site], einschließlich der Hauptnavigation und des Footers, mit allen Links.

Ordne die Menülinks den GA4-Zeilen anhand des URL-Pfads zu (ignoriere Domain, abschließende Schrägstriche und Query-Strings). Wenn ein Link keine GA4-Zeile hat, behandle ihn als 0 Sitzungen und weise darauf hin.

Prüfe jeden Menülink auf Probleme:
- Rufe jede verlinkte URL ab und erfasse den HTTP-Status. Alles mit 4xx oder 5xx ist defekt; Weiterleitungen sind erwähnenswert.
- Markiere Links, die auf Entwurfs- oder private Seiten, auf alte Slugs oder auf http statt https zeigen.

Liefere drei Listen:
1. Seiten mit mindestens 20 Key Events, die nicht im Hauptmenü stehen.
2. Menülinks, die auf Seiten mit weniger als 50 Sitzungen oder null Key Events in 90 Tagen zeigen.
3. Defekte oder veraltete Links, jeweils mit Begründung.

Schlage dann ein neues Hauptmenü vor:
- Max. 7 Punkte auf oberster Ebene, geordnet nach kommerzieller Wichtigkeit.
- Exakte Bezeichnungen mit 2 bis 3 Wörtern in einfacher Sprache, wie ein Kunde sie verwenden würde.
- Die Kontaktseite bleibt der letzte Punkt.
- Verschiebe Seiten mit geringem Wert ins Footer-Menü, statt sie zu löschen.

Zeige das aktuelle und das vorgeschlagene Menü nebeneinander, mit der genauen Liste der Menüaktionen, die du ausführen würdest (hinzufügen, umbenennen, neu verlinken, neu ordnen, entfernen), als Vorschau. Ändere nichts, bevor ich zugestimmt habe. Wende die Änderungen nach der Freigabe an, leere den Cache und lies die Menüs erneut aus, um die finale Struktur zu bestätigen.

WebsiteÄndert nach deiner Freigabe

Plugin- und Tracking-Check, bevor er deine Conversions kaputt macht

Eine Aktionsliste Plugin für Plugin, die veraltete, doppelte und konfligierende Plugins sowie doppelt feuernde Tags markiert.

Wann du ihn nutztWenn deine WordPress-Seite zu viele Plugins hat, Updates sich stauen oder doppelte Tags vermutlich die Conversions aufblähen, auf die deine Anzeigen optimieren.

Führe einen Plugin- und Tracking-Check für [WordPress-Website] durch.

Lies Folgendes aus:
- Die WordPress- und PHP-Version.
- Alle installierten Plugins, mit ihrem Aktivstatus und ob ein Update verfügbar ist.
- Jede Stelle, an der ein GTM- oder GA4-Tag feuert.
- Die aktuellen Caching- und Speed-Einstellungen.

Liefere eine Tabelle mit diesen Spalten: Plugin, aktiv?, Update verfügbar?, Rolle (SEO, Cache, Formulare, Tracking, Page Builder, Sonstiges), Risiko, Empfehlung (behalten, updaten, deaktivieren oder löschen).

Markiere diese Probleme ausdrücklich:
- Mehr als ein SEO-Plugin.
- Mehr als ein Caching-Plugin.
- Inaktive Plugins, die gelöscht werden können.
- Jedes GTM- oder GA4-Tag, das von mehr als einer Stelle aus feuert. Doppeltes Feuern bläht die Conversions auf, auf die meine Ads optimieren.

Fasse den Page Builder, das Formular-Plugin und WooCommerce nicht an.

Zeige die Aktionsliste zuerst als Vorschau. Gehe danach ein Plugin nach dem anderen an, und zwar erst nach meiner Freigabe für jedes einzelne. Bestätige nach jeder Änderung, dass die Startseite weiterhin Status 200 zurückgibt, bevor du weitermachst.

WebsiteÄndert nach deiner Freigabe

Alte Telefonnummer auf der gesamten Website sicher ersetzen

Eine vollständige Übersicht, wo die alte Nummer vorkommt, ein Dry-Run-Diff des Massen-Ersetzens und eine Liste der Stellen, die manuell korrigiert werden müssen.

Wann du ihn nutztWenn sich deine Telefonnummer geändert hat und die alte Nummer nirgends mehr auf deiner Website auftauchen darf.

Unsere Telefonnummer hat sich von [alte Nummer] auf [neue Nummer] geändert. Weder Ads- noch organische Besucher dürfen irgendwo noch die alte sehen.

1. Finde auf meiner WordPress-Website jeden Beitrag und jede Seite, die die alte Nummer in einem der gängigen Formate enthält: mit Leerzeichen, ohne Leerzeichen, mit Ländervorwahl und innerhalb von tel:-Links.
2. Prüfe die Menüs auf tel:-Links und die Contact-Form-7-Einstellungen auf die alte Nummer.
3. Lies meinen Business-Profile-Standort aus und sag mir, welche Nummer dort aktuell angezeigt wird.

Liefere:
- Eine Liste der Seiten mit der Anzahl der Vorkommen auf jeder Seite.
- Alle Stellen, die ein Suchen/Ersetzen im Inhalt nicht erreichen kann, etwa Menüs, Formulareinstellungen oder Business Profile.

Führe das Massen-Suchen/Ersetzen zuerst als Dry Run aus und zeig mir für jede Seite den Diff. Wende es erst nach meiner Freigabe an und leere danach den Cache.

Ändere Business Profile in dieser Aufgabe nicht. Sag mir nur, ob es aktualisiert werden muss.