Checkliste für Website-Launch und Relaunch

Warum

Ohne klares Bild der Käufer entstehen Texte, die zu jedem passen und niemanden überzeugen.

So prüfst du

Schreib drei Sätze: Wer kauft, was hält diese Person gerade auf, und was gibt am Ende den Ausschlag?

Warum

Erst das Ziel entscheidet, welcher Button oben steht und was du später misst.

So prüfst du

Benenn genau eine Handlung als Hauptziel, etwa eine Terminbuchung, und notier, woran du sie im Tracking erkennst.

Warum

Wer weiß, was die drei stärksten Alternativen zeigen, sieht schnell, wo die eigene Seite austauschbar klingt.

So prüfst du

Lies drei Seiten der Konkurrenz wie ein Kunde und notier jeweils Angebot, Preisangabe, Belege und den ersten Button.

Warum

Seiten, die an den Suchbegriffen der Kunden vorbei formuliert sind, findet niemand, egal wie gut sie aussehen.

So prüfst du

Sammle Begriffe aus Kundengesprächen, prüf sie in der Google-Suche und in einem Keyword-Werkzeug und notier, was die Suchenden jeweils erwarten.

Warum

Zwei Seiten zum selben Thema konkurrieren in der Suche gegeneinander, und keine rankt richtig.

So prüfst du

Leg eine Tabelle an: URL, Hauptthema, Suchintention. Steht ein Thema zweimal darin, leg die Seiten zusammen.

Warum

Die Struktur bestimmt URLs, Navigation und interne Links. Spätere Änderungen kosten Weiterleitungen und oft auch Rankings.

So prüfst du

Zeichne die Seitenhierarchie mit allen URLs auf, bevor das erste Layout entsteht.

Warum

Die Fragen, die im Verkaufsgespräch immer wieder kommen, muss die Website beantworten.

So prüfst du

Frag Vertrieb oder Kundenservice nach den zehn häufigsten Fragen und Einwänden und notier zu jedem einen Beleg: Zahl, Referenz oder Zitat.

Warum

Ohne Ausgangswert lässt sich nach dem Launch nicht sagen, ob die neue Seite besser ist.

So prüfst du

Notier mit Datum: Besuche, Anfragen, Conversion-Rate und die wichtigsten Rankings.

Warum

Nach dem Umzug fehlt sonst die Liste der alten URLs und Rankings, an der du den Relaunch misst.

So prüfst du

Exportier aus der Search Console Seiten und Suchanfragen der letzten 16 Monate, dazu die Seiten mit Backlinks und die Core Web Vitals.

Warum

Ob ChatGPT oder Perplexity dich nach dem Launch häufiger nennen, siehst du nur im Vergleich mit einem Wert von vorher.

So prüfst du

Stell ChatGPT, Perplexity, Gemini und der Google-Suche mit KI-Übersicht die fünf bis zehn wichtigsten Kundenfragen und speicher die Antworten mit Datum.

Warum

Wer nur einen Ratgeber liest oder als Kunde zum Login kommt, zählt in jeder Statistik mit und lässt die Website erfolgreicher aussehen, als sie ist.

So prüfst du

Ordne deine meistbesuchten Seiten und Suchbegriffe einer von drei Gruppen zu: Interessenten mit Kaufabsicht, Leser ohne Kaufabsicht und Bestandskunden. Die Conversion-Rate berechnest du dann nur für die Interessenten.

Warum

Personas beschreiben oft, wen man gern als Kunden hätte, und nicht, wer tatsächlich kauft.

So prüfst du

Leg neben jedes Profil die Zahlen aus deinem Kundenbestand: Anzahl, Umsatz je Kunde und Betriebsgröße. Passt beides nicht zusammen, ist genau das dein wichtigstes Ergebnis. Dann klärst du, wen die Website eigentlich ansprechen soll.

Warum

Erst wenn du weißt, welchen Anteil eines Markts du schon erreichst, siehst du, wo noch Wachstum liegt und wo kaum noch etwas zu holen ist.

So prüfst du

Hol dir die Zahl der Betriebe oder Haushalte je Zielgruppe aus der amtlichen Statistik oder von Branchenverbänden, notier Quelle und Stichtag und teil deine Kundenzahl durch diesen Wert.

Warum

Bekommt eine kleine Produktlinie die meisten Besuche und das meiste Werbebudget, arbeitet die Website am Geschäft vorbei.

So prüfst du

Stell je Produktlinie drei Anteile nebeneinander: am Umsatz, an den Besuchen und am Werbebudget. Weichen sie deutlich voneinander ab, plan die Seitenstruktur vom Umsatz her und nicht von den Besuchen.

Warum

Fachmedien, Verbände und Portale, die deine Konkurrenz verlinken, erreichen deine Zielgruppe schon heute.

So prüfst du

Lass dich in einem Backlink-Werkzeug die verweisenden Seiten deiner zwei bis drei stärksten Wettbewerber anzeigen und markier jede, die noch nicht auf dich verlinkt.

Warum

Sucht kaum jemand nach deinem Angebot, gewinnst du Kunden eher über Verbände, Fachmedien und Messen als über zusätzliche Anzeigen.

So prüfst du

Liste Verbände, Fachzeitschriften, Messen und Communitys deiner Branche auf, jeweils mit Mitgliederzahl, Auflage oder Besucherzahl und dem Stand der Angabe.

Warum

Weichen Name, Adresse oder Telefonnummer von Plattform zu Plattform ab, wissen Kunden, Suchmaschinen und KI-Assistenten nicht mehr, welche Angabe stimmt.

So prüfst du

Leg eine verbindliche Fassung fest: Firmenname, Adresse in genau einer Schreibweise, Telefon, Website, Gründungsjahr und eine Beschreibung in einem Satz. Mit dieser Fassung gleichst du jeden Eintrag im Netz ab.

Warum

Viele Kunden sehen deinen Karteneintrag vor deiner Website, und manchmal verweist er noch auf eine alte Domain.

So prüfst du

Such deinen Firmennamen in allen großen Kartendiensten, nicht nur im bekanntesten. Prüf je Eintrag, ob du ihn beansprucht hast und ob Name, Kategorie, Adresse mit Hausnummer und Website stimmen.

Warum

Verwaiste Konten, doppelte Profile und fremde Firmen mit ähnlichem Namen fallen Kunden eher auf als dir.

So prüfst du

Such auf jeder Plattform nach deinem Firmennamen und notier je Konto Follower, Datum des letzten Beitrags und ob es auf die Website verlinkt. Verwaiste Konten belebst du wieder oder legst sie still.

Warum

Ein Profil, das du nicht selbst anlegst, eröffnet womöglich ein unzufriedener Kunde mit der ersten Bewertung.

So prüfst du

Prüf die allgemeinen Bewertungsportale und die deiner Branche: Note, Anzahl, Datum der letzten Bewertung und wie viele davon du beantwortet hast.

Warum

Widerspricht die häufigste Kritik einem Versprechen deiner Website, glaubt dieses Versprechen niemand.

So prüfst du

Lies alle Bewertungen mit einem oder zwei Sternen, sortier sie nach Thema und beantworte die offenen. Das häufigste Thema gehört in die Positionierung, nicht nur in den Support.

Warum

Suchmaschinen und KI-Assistenten lesen aus Verzeichnissen und Fachlisten ab, wer du bist und was du anbietest.

So prüfst du

Prüf allgemeine Branchenbücher, B2B-Verzeichnisse, Firmendatenbanken und die Listen von Kammer, Verband und Fachmessen: Stimmen die Angaben mit deinen Firmendaten überein? Fachlisten findest du oft nur über eine eigene Websuche.

Warum

KI-Assistenten lesen Preise, Verfügbarkeit und Bewertungen auch direkt aus Marktplatz-Einträgen. Schwache Produktdaten dort fallen auf deine Marke zurück.

So prüfst du

Verkaufst du Produkte, prüf deine Einträge auf den großen Marktplätzen und bei deinen wichtigsten Händlern: Titel, Bilder, Preis, Verfügbarkeit und Bewertungen.

Warum

Manche KI-Assistenten stützen sich auf einen anderen Suchindex als den der meistgenutzten Suchmaschine. Wer dort fehlt, taucht auch in ihren Antworten seltener auf.

So prüfst du

Such deine acht bis zehn wichtigsten Begriffe in jeder großen Suchmaschine, am besten im privaten Fenster, und notier, wer statt dir oben steht.

Warum

Welche Seiten ein KI-Assistent als Quelle nennt, bestimmt mit, wen er empfiehlt. Oft sind das Ratgeberportale, Videos und Testseiten, nicht deine Wettbewerber.

So prüfst du

Notier zu jeder KI-Antwort auf deine Kundenfragen die genannten Quellen und zähl, welche Seiten immer wieder auftauchen. Dort willst du erwähnt werden.

Warum

Wer nach wenigen Sekunden nicht weiß, was du anbietest und für wen, ist wieder weg.

So prüfst du

Zeige die Seite jemandem fünf Sekunden lang auf dem Smartphone und lass dir danach sagen, was du verkaufst.

Warum

Stehen drei gleich starke Buttons nebeneinander, klicken viele Besucher gar keinen.

So prüfst du

Markier auf jeder Seite den einen Button, der zählt. Alle anderen Links treten optisch zurück.

Warum

Ein Button, der ins Leere führt, kostet genau die Besucher, die schon kaufen wollten.

So prüfst du

Klick jeden Button auf Desktop und Smartphone und prüf, ob das Ziel hält, was die Beschriftung verspricht.

Warum

Fehlen Preis oder Ablauf, fragen viele Interessenten nicht nach, sondern schauen sich woanders um.

So prüfst du

Lies jede Angebotsseite mit drei Fragen: Was kostet es, was muss ich beisteuern, und was passiert nach dem Klick?

Warum

Eine falsche Zahl in einer Überschrift übersteht jede Stilprüfung und fällt erst dem Kunden auf.

So prüfst du

Rechne jede Zahl aus der Originalquelle nach, nicht aus einem Diagramm, Screenshot oder einer früheren Zusammenfassung.

Warum

Ein Kundenlogo ohne Erlaubnis kann eine Abmahnung und eine verärgerte Kundenbeziehung nach sich ziehen.

So prüfst du

Leg zu jedem Logo, Zitat und Foto die schriftliche Freigabe mit Datum ab. Fotos von Personen nur mit ausdrücklicher Zustimmung.

Warum

Holprige oder übersetzt klingende Sätze kosten Vertrauen, bevor das Angebot überhaupt ankommt.

So prüfst du

Lies jeden Text laut. Klingt ein Satz nach Übersetzung oder nach Werbeprospekt, schreib ihn neu.

Warum

Lorem ipsum, ein Tutorial-Video aus dem Template oder ein leerer Blogbeitrag wirken live sofort unfertig.

So prüfst du

Durchsuch alle Seiten und CMS-Einträge nach „Lorem“, „Test“, „TODO“ und leeren Feldern, auch in der zweiten Sprache.

Warum

Eine vertauschte Ziffer in der Telefonnummer fällt erst auf, wenn die Anrufe ausbleiben.

So prüfst du

Tipp auf dem Smartphone auf jede Telefonnummer und E-Mail-Adresse. Kopierbuttons kopieren den richtigen Text.

Warum

Seitentitel, Fehlermeldungen und Bestätigungsmails sieht fast jeder Besucher, lektoriert werden sie selten.

So prüfst du

Prüf Seitentitel, Meta-Beschreibungen, Alt-Texte, Formularfehler, Bestätigungsmails, Cookie-Banner und die 404-Seite.

Warum

Wechselt eine Seite zwischen „du“ und „Sie“, wirkt sie zusammengestückelt.

So prüfst du

Such nach „Sie“, „Ihr“ und „du“ und nach den Schreibweisen deiner Produkt- und Firmennamen.

Warum

Eine wörtlich übersetzte Seite erkennt jeder Muttersprachler am ersten Satz.

So prüfst du

Lass jede Sprache von jemandem lesen, der sie als Muttersprache spricht, und achte auf Datums-, Zahlen- und Währungsformate (1.500 € gegenüber €1,500).

Warum

Ein Copyright von vor zwei Jahren oder ein alter Preis lässt die ganze Seite verwaist wirken.

So prüfst du

Prüf am Tag der Veröffentlichung Jahreszahlen, Stand-Angaben, Preise, Team und Referenzen.

Warum

Layouts brechen erst mit der längsten Überschrift, dem längsten Namen oder dem englischen Text.

So prüfst du

Setz die längsten echten Inhalte ein und lass optionale Felder testweise leer.

Warum

Eine Datenschutzerklärung, die andere Dienste nennt, als die Seite lädt, beschreibt nicht, was passiert, und ist damit angreifbar.

So prüfst du

Vergleich Betreiber, Anschrift und jeden genannten Dienst mit dem, was der Browser beim Laden tatsächlich anfragt.

Warum

Seit dem 14.05.2024 gilt § 5 DDG statt TMG, und viele Impressen verweisen noch auf das alte Gesetz.

So prüfst du

Prüf den Verweis auf § 5 DDG. Bei redaktionellen Inhalten wie einem Blog braucht es zusätzlich eine verantwortliche Person nach § 18 Abs. 2 MStV.

Warum

Wer online an Verbraucher verkauft, braucht mehr als Impressum und Datenschutzerklärung.

So prüfst du

Klär mit deiner Rechtsberatung, welche Pflichtinformationen dein Angebot verlangt und ob sie vor dem Kaufabschluss sichtbar sind.

Warum

Seit dem 28.06.2025 gilt das BFSG für viele Dienstleistungen, die Verbraucher online abschließen, etwa Shops und verbindliche Terminbuchungen.

So prüfst du

Prüf, ob dein Angebot darunter fällt. Kleinstunternehmen mit Dienstleistungen (unter 10 Beschäftigte, höchstens 2 Mio. € Umsatz oder Bilanzsumme) sind ausgenommen und halten die Begründung schriftlich fest.

Warum

Viele Dienste kommen über Integrationen, Schriften oder Test-Werkzeuge dazu, die niemand bewusst eingebaut hat.

So prüfst du

Öffne die Seite in einem privaten Fenster, lies in den Entwicklerwerkzeugen alle Anfragen, Cookies und den lokalen Speicher aus und notier jeden fremden Host.

Warum

Für jeden Dienst, der personenbezogene Daten verarbeitet, brauchst du eine vertragliche Grundlage.

So prüfst du

Leg für jeden Dienst den Vertrag zur Auftragsverarbeitung ab und notier, wo die Daten liegen und wann sie gelöscht werden.

Warum

Nach § 25 TDDDG darf nichts Einwilligungspflichtiges laden, bevor der Besucher zugestimmt hat.

So prüfst du

Lade die Seite ohne Klick im Banner und prüf im Netzwerk-Tab, dass kein Analyse- oder Marketingdienst anfragt.

Warum

Ist Ablehnen schwerer zu finden als Zustimmen, gilt die Einwilligung nicht als freiwillig.

So prüfst du

Ablehnen steht auf der ersten Ebene gleichwertig neben Zustimmen, keine Kategorie ist vorausgewählt, und ein Link im Footer öffnet die Einstellungen erneut.

Warum

Ein Banner, das nur gut aussieht, schützt dich nicht, wenn die Dienste trotz Ablehnung laden.

So prüfst du

Spiel alle drei Fälle im echten Browser durch und prüf jeweils Cookies und Netzwerkanfragen.

Warum

Jeder Dienst, der läuft, aber nicht in der Erklärung steht, ist eine Lücke.

So prüfst du

Jeder gemessene Dienst steht darin, und keiner steht darin, der nicht läuft.

Warum

Lädt eine Schrift von Google Fonts, geht die IP-Adresse jedes Besuchers ohne Einwilligung an Google.

So prüfst du

Prüf im Netzwerk-Tab auf Anfragen an fonts.googleapis.com und fonts.gstatic.com. Auch ungenutzte Schriften in den Projekteinstellungen können sie auslösen.

Warum

Ein eingebettetes Video, eine Karte oder ein Kalender überträgt Daten schon beim Seitenaufruf.

So prüfst du

Zeige zuerst ein Vorschaubild mit Hinweis und lade den Dienst erst nach Klick. Ein direkter Link bleibt als Alternative sichtbar.

Warum

Wer Daten eingibt, soll vor dem Absenden wissen, was damit passiert.

So prüfst du

Am Absendebutton stehen Zweck, Empfänger und Speicherdauer mit Link zur Datenschutzerklärung.

Warum

Ohne bestätigte Anmeldung kannst du nicht nachweisen, dass jemand den Newsletter wirklich wollte.

So prüfst du

Melde dich mit einer echten Adresse an, bestätig, melde dich wieder ab und prüf, dass danach keine Mails mehr kommen.

Warum

Verbrauchern musst du nach der Preisangabenverordnung Gesamtpreise inklusive Umsatzsteuer zeigen.

So prüfst du

Prüf jede Preisangabe: brutto für Verbraucher, im B2B netto mit deutlichem Hinweis „zzgl. MwSt.“.

Warum

Seit dem 02.08.2026 gelten die Transparenzpflichten aus Art. 50 der KI-Verordnung, unter anderem für Deepfakes.

So prüfst du

Kennzeichne realistisch wirkende KI-Inhalte, vor allem Personen und Stimmen, als künstlich erzeugt.

Warum

Eine Desktop-Lizenz deckt eine Schrift auf der Website oft nicht ab.

So prüfst du

Leg zu jeder Schrift, jedem Musikstück und jedem Icon-Set die Lizenz ab und prüf, ob sie die Nutzung im Web erlaubt.

Warum

Superlative wie „der schnellste Anbieter“ oder Garantien ohne Beleg verstoßen gegen das Wettbewerbsrecht (UWG).

So prüfst du

Streich jeden Superlativ und jede Garantie, die du nicht mit Zahlen oder Quellen belegen kannst.

Warum

Besucher der englischen Version müssen verstehen, worin sie einwilligen.

So prüfst du

Prüf Banner, Impressum und Datenschutzerklärung in jeder Sprachversion auf Vollständigkeit und gleichen Inhalt.

Warum

Wer mit einer KI spricht, muss das nach Art. 50 der KI-Verordnung erkennen können.

So prüfst du

Der Bot gibt sich zu Beginn als KI zu erkennen, und die Datenschutzerklärung beschreibt, was mit den Gesprächsinhalten passiert.

Warum

Tracking, Formulare und Newsletter sind Verarbeitungen, die ins Verzeichnis nach Art. 30 DSGVO gehören.

So prüfst du

Trag jede Verarbeitung der Website mit Zweck, Datenkategorien, Empfängern und Löschfrist ein.

Warum

Auskunfts- und Löschanfragen musst du innerhalb eines Monats beantworten (Art. 12 Abs. 3 DSGVO).

So prüfst du

Schick eine Testmail an die Adresse aus der Datenschutzerklärung und prüf, wer sie liest und bearbeitet.

Warum

Ein API-Schlüssel im Frontend-Code ist für jeden Besucher lesbar, und Bots suchen gezielt danach.

So prüfst du

Durchsuch den ausgelieferten Code, eigene Skripte im CMS, Source Maps und die Git-Historie nach Schlüsseln und Passwörtern.

Warum

Ein gelöschter Schlüssel steht noch in Caches, Archiven und der Git-Historie.

So prüfst du

Erzeug beim Anbieter einen neuen Schlüssel und sperr den alten. Löschen allein reicht nicht.

Warum

Was im Browser landet, ist öffentlich.

So prüfst du

Bewahr Zugangsdaten in einem Passwortmanager auf und gib sie nur über Umgebungsvariablen an den Server.

Warum

Ohne gültiges Zertifikat zeigen Browser eine Warnseite statt deiner Website.

So prüfst du

Ruf http:// und https:// mit und ohne www auf. Jede Variante landet per Weiterleitung auf https.

Warum

Erlaubt ein CAA-Eintrag die Zertifizierungsstelle deines Hosters nicht, scheitert die nächste Zertifikatsverlängerung unbemerkt.

So prüfst du

Frag die CAA-Einträge der Domain ab. Gibt es welche, müssen sie die Stellen von Hosting und CDN erlauben.

Warum

Lädt eine HTTPS-Seite Bilder oder Skripte über HTTP, blockiert der Browser sie oder warnt.

So prüfst du

Prüf die Browserkonsole auf Meldungen zu „Mixed Content“.

Warum

Jeder überflüssige Admin-Zugang ist ein weiterer Weg in dein System.

So prüfst du

Gib jeder Person nur die Rechte, die sie braucht, und schaff geteilte Konten ab.

Warum

Wer das Passwort für Registrar oder DNS hat, kann deine Website und deine E-Mails umleiten.

So prüfst du

Aktivier 2FA bei Registrar, DNS, Hosting, CMS, CDN, Formular- und Maildienst und entfern Zugänge ehemaliger Beteiligter.

Warum

Eine Prüfung nur im Browser lässt sich mit einem Klick in den Entwicklerwerkzeugen umgehen.

So prüfst du

Schick Formular- und API-Anfragen testweise ohne Browser, etwa mit curl, und prüf, ob der Server ungültige Daten ablehnt.

Warum

Header wie HSTS und Content-Security-Policy schließen ganze Klassen von Angriffen aus.

So prüfst du

Prüf die Header in den Entwicklerwerkzeugen oder mit securityheaders.com: HSTS, CSP oder mindestens frame-ancestors, X-Content-Type-Options und Referrer-Policy.

Warum

Eine veraltete Bibliothek bringt ihre bekannten Lücken mit auf deine Seite.

So prüfst du

Führ npm audit oder das Gegenstück deines Paketmanagers aus und aktualisier betroffene Pakete.

Warum

Ein Skript, das immer die neueste Version lädt, kann sich über Nacht ändern, ohne dass du es merkst.

So prüfst du

Ersetz „latest“ in CDN-Adressen durch eine feste Versionsnummer und notier zu jedem Fremdskript seinen Zweck.

Warum

Eine Fehlermeldung mit Datenbankpfad oder E-Mail-Adresse verrät Angreifern mehr als nötig.

So prüfst du

Lös absichtlich Fehler aus, etwa mit ungültigen Formulardaten, und lies, was Seite und Logs ausgeben.

Warum

Ohne diese Einträge kann jeder Mails in deinem Namen verschicken, und deine eigenen landen öfter im Spam.

So prüfst du

Prüf die Einträge mit einem DNS-Werkzeug. Domains ohne Mailversand bekommen v=spf1 -all und DMARC mit p=reject.

Warum

Läuft die Domain ab, sind Website und E-Mail auf einen Schlag weg.

So prüfst du

Aktivier die automatische Verlängerung und die Transfersperre und notier das Ablaufdatum.

Warum

Läuft deine Domain ab, kommt die Warnung sonst an eine Adresse, die genau dann nicht mehr funktioniert.

So prüfst du

Hinterleg bei Registrar und DNS-Anbieter eine Adresse auf einer anderen Domain.

Warum

Ohne Rate Limiting kann ein Bot in kurzer Zeit tausende Anfragen an dein Formular schicken.

So prüfst du

Begrenz Anfragen pro IP in der Firewall oder im Code und prüf, dass erwünschte Crawler nicht gesperrt werden.

Warum

Wer eine Sicherheitslücke findet, weiß dann, wem er sie melden kann.

So prüfst du

Leg unter /.well-known/security.txt eine Kontaktadresse für Sicherheitsmeldungen ab.

Warum

Der Seitentitel ist das Erste, was Suchende in Google von dir sehen.

So prüfst du

Jede Seite hat in jeder Sprache einen eigenen Titel bis etwa 60 Zeichen und eine Beschreibung bis etwa 155 Zeichen.

Warum

Suchmaschinen, KI-Systeme und Screenreader lesen die Gliederung einer Seite an ihren Überschriften ab.

So prüfst du

Prüf mit einer Browser-Erweiterung oder der Barrierefreiheitsansicht, dass H1 bis H3 ohne Sprünge aufeinander folgen.

Warum

Ein vergessenes noindex aus der Testphase hält die ganze Website aus Google heraus.

So prüfst du

Prüf im Quelltext jeder wichtigen Seite das robots-Meta-Tag und im Netzwerk-Tab den Header X-Robots-Tag.

Warum

Eine indexierte Testumgebung konkurriert mit deiner echten Website um dieselben Suchbegriffe.

So prüfst du

Such in Google nach site: plus deine Staging-Adresse. Testumgebungen bekommen ein Passwort oder noindex.

Warum

Sind Varianten wie mit und ohne www parallel erreichbar, verteilen sich Links und Signale auf mehrere Adressen.

So prüfst du

Ruf alle Varianten auf: mit und ohne www, mit und ohne Schrägstrich am Ende. Jede leitet in einem Schritt per 301 auf die Hauptadresse.

Warum

Ein falsches Canonical sagt Google, dass eine andere Seite die eigentliche ist.

So prüfst du

Prüf auf jeder Seitenvorlage, dass das Canonical auf die eigene öffentliche Adresse zeigt.

Warum

Eine Sitemap voller Weiterleitungen, Testseiten und noindex-Seiten schickt Google an die falschen Stellen.

So prüfst du

Ruf /sitemap.xml auf und prüf Stichproben: Jede URL antwortet mit 200 und ist indexierbar.

Warum

Eine Zeile aus der Entwicklungsphase kann ganze Verzeichnisse für Suchmaschinen sperren.

So prüfst du

Ruf /robots.txt auf, prüf jede Disallow-Zeile und verweis auf die Sitemap. Für das Ausschließen einzelner Seiten ist noindex der richtige Weg, nicht robots.txt.

Warum

Eine Seite, auf die kein Link zeigt, finden weder Google noch Besucher.

So prüfst du

Crawl die Website mit einem SEO-Werkzeug und such nach Seiten ohne eingehende interne Links.

Warum

Google ignoriert fehlerhaftes Markup, und Angaben, die nicht auf der Seite stehen, verstoßen gegen die Richtlinien.

So prüfst du

Teste wichtige Seiten mit dem Rich Results Test und dem Schema Markup Validator.

Warum

Ohne hreflang zeigt Google der deutschen Suche womöglich die englische Seite.

So prüfst du

Jede Sprachversion verweist auf alle anderen und auf sich selbst, dazu kommt ein x-default. Das lang-Attribut passt zur Sprache.

Warum

Dort siehst du, welche Seiten Google indexiert und warum es andere auslässt.

So prüfst du

Leg eine Domain-Property an, bestätig sie per DNS und reich die Sitemap ein.

Warum

Der Bing-Index speist auch Microsoft Copilot und wird von KI-Suchen mitgenutzt.

So prüfst du

Importier die Property aus der Search Console, reich die Sitemap ein und aktivier IndexNow, wenn dein System es unterstützt.

Warum

Jede alte URL ohne Weiterleitung verliert ihre Rankings und Backlinks.

So prüfst du

Sammle alte URLs aus Crawl, Sitemap, Search Console und Backlink-Daten und teste jede Weiterleitung einzeln.

Warum

Leitet jede alte URL auf die Startseite, wertet Google das als Soft-404, und die Rankings sind trotzdem weg.

So prüfst du

Jede alte URL leitet in einem Schritt auf die inhaltlich passende neue Seite.

Warum

Leere Kategorien, Tag-Seiten und Vorlagenseiten ohne Inhalt landen sonst im Index und ziehen den Gesamteindruck der Website nach unten.

So prüfst du

Setz solche Seiten auf noindex, nimm sie aus der Sitemap oder lösch sie.

Warum

Bei lokalen Suchen zeigt Google das Unternehmensprofil vor den normalen Ergebnissen.

So prüfst du

Name, Adresse und Telefonnummer stehen im Google-Unternehmensprofil genau so wie auf der Website.

Warum

Andere Endungen oder alte Markennamen, die ins Leere laufen, verschenken Besucher und Links.

So prüfst du

Jede weitere Domain leitet per 301 auf die Hauptdomain und hat ein gültiges Zertifikat.

Warum

Wer KI-Crawler aus Versehen sperrt, taucht in ChatGPT oder Perplexity nicht als Quelle auf.

So prüfst du

Prüf in der robots.txt die Einträge für OAI-SearchBot, GPTBot, ClaudeBot, Claude-SearchBot, PerplexityBot und Google-Extended und entscheide für jeden einzeln.

Warum

Cloudflare kann KI-Crawler je nach Einstellung von sich aus sperren, ohne dass es in deiner robots.txt steht.

So prüfst du

Prüf AI Crawl Control und die Bot-Einstellungen und vergleich die ausgelieferte robots.txt mit deiner eigenen.

Warum

Die meisten KI-Crawler führen kein JavaScript aus und sehen nur, was im ausgelieferten HTML steht.

So prüfst du

Ruf die Seite mit curl ab oder öffne den Quelltext und prüf, ob Überschriften, Texte und Preise darin stehen.

Warum

KI-Antworten übernehmen am liebsten Sätze, die für sich allein verständlich sind.

So prüfst du

Schreib in ganzen Sätzen, wer du bist, was du anbietest, für wen, wo und zu welchem Preis. Dieselben Angaben stehen auf LinkedIn und in Verzeichnissen.

Warum

Organization- oder Person-Markup mit sameAs verknüpft deine Website mit deinen Profilen.

So prüfst du

Hinterleg Organization oder Person mit sameAs, dazu Service, Article und BreadcrumbList, wo sie sichtbaren Inhalt beschreiben.

Warum

KI-Systeme suchen zu einer Frage den Abschnitt, der sie am direktesten beantwortet.

So prüfst du

Formulier wichtige H2 als Fragen deiner Kunden und beantworte sie im ersten Satz darunter.

Warum

Bei einem Artikel ohne Datum und Autor bleibt offen, ob er aktuell ist und wer dafür geradesteht.

So prüfst du

Zeige bei Artikeln Autor, Veröffentlichungs- und Aktualisierungsdatum und hinterleg beides im Article-Markup.

Warum

Die Datei fasst deine Website für Sprachmodelle zusammen. Dass sie die Sichtbarkeit verbessert, ist bisher nicht belegt.

So prüfst du

Leg sie als Ergänzung an, nie als Ersatz für die Punkte oben.

Warum

Im Browser-Tab und auf dem Homescreen ist das Icon oft das Einzige, was von deiner Marke zu sehen ist.

So prüfst du

Hinterleg ein SVG-Favicon, ein PNG mit 32 px und ein Apple Touch Icon mit 180 px und prüf es auf hellem und dunklem Tab.

Warum

Ohne Vorschaubild sieht ein geteilter Link auf LinkedIn wie ein leerer Kasten aus.

So prüfst du

Jede wichtige Seite hat in jeder Sprache Titel, Beschreibung und ein Bild mit 1200 × 630 px über eine absolute URL.

Warum

LinkedIn und Facebook speichern alte Vorschauen und zeigen sie weiter, bis du sie neu einlesen lässt.

So prüfst du

Prüf die Links im LinkedIn Post Inspector und im Sharing Debugger von Meta und teste sie zusätzlich in Slack und WhatsApp.

Warum

Screenreader lesen den Alt-Text vor, und Suchmaschinen erkennen daran, was das Bild zeigt.

So prüfst du

Beschreib informative Bilder in einem Satz, dekorative bekommen ein leeres alt-Attribut. Jede Sprache bekommt eigene Texte.

Warum

Ein unkomprimiertes Foto kann größer sein als der ganze Rest der Seite.

So prüfst du

Nutz AVIF oder WebP und srcset mit passenden Größen und prüf in PageSpeed Insights die Hinweise zur Bildgröße.

Warum

Ohne feste Maße springt der Text beim Laden nach unten, und Besucher klicken daneben.

So prüfst du

Jedes Bild hat width und height oder ein festes Seitenverhältnis im CSS. Der CLS-Wert in PageSpeed Insights zeigt, ob noch etwas springt.

Warum

Bilder, die noch niemand sieht, bremsen den Aufbau des sichtbaren Teils.

So prüfst du

Setz loading="lazy" auf alle Bilder unterhalb des ersten Bildschirms.

Warum

Das große Bild oben ist meist das Element, an dem Google die Ladezeit misst (LCP).

So prüfst du

Kein loading="lazy" auf dem Hauptbild, bei Bedarf fetchpriority="high".

Warum

Ein Stockfoto ohne passende Lizenz kann eine teure Abmahnung auslösen.

So prüfst du

Leg zu jedem Bild Quelle, Lizenz und die nötige Namensnennung ab.

Warum

Bildgeneratoren erfinden gern unleserliche Buchstaben, die auf einer Firmenwebsite sofort auffallen.

So prüfst du

Prüf jedes generierte Bild in voller Größe. Text gehört als HTML über das Bild, nicht ins Bild.

Warum

Ein Video, das ungefragt mit Ton startet, vergrault Besucher und verstößt gegen WCAG.

So prüfst du

Posterbild setzen, Autoplay nur mit muted und playsinline, Untertitel bei gesprochenem Inhalt, Pause muss möglich sein.

Warum

Nachgezeichnete oder unscharfe Logos wirken unprofessionell und können gegen die Markenrichtlinien verstoßen.

So prüfst du

Nimm die SVG aus dem Pressebereich der Marke oder aus einer gepflegten Sammlung wie svgl.

Warum

Die Geräteansicht im Browser zeigt kein echtes Touch-Verhalten und keine echte Bildschirmtastatur.

So prüfst du

Teste auf mindestens einem iPhone, einem Android-Gerät und einem Tablet.

Warum

Safari stellt manches anders dar als Chrome, und auf dem iPhone nutzt jeder Browser die Technik von Safari.

So prüfst du

Prüf Chrome, Safari, Firefox und Edge, dazu Safari auf iOS.

Warum

Ein einziges zu breites Element lässt die ganze Seite auf dem Smartphone seitlich wackeln.

So prüfst du

Zieh das Fenster auf 320 px Breite zusammen und scroll jede Seite einmal durch.

Warum

Wörter wie „Barrierefreiheitsstärkungsgesetz“ laufen auf dem Smartphone aus jeder Überschrift.

So prüfst du

Setz das lang-Attribut korrekt und nutz hyphens: auto oder weiche Trennstellen in großen Überschriften.

Warum

Wer keine Maus nutzt, kommt sonst nicht durch Menü, Dialoge und Formulare.

So prüfst du

Leg die Maus weg und geh die Seite nur mit Tab, Umschalt und Tab, Enter, Leertaste und Escape durch.

Warum

Ohne sichtbaren Fokus weiß ein Tastaturnutzer nicht, wo er gerade ist.

So prüfst du

Jedes fokussierte Element bekommt einen deutlichen Rahmen, und der erste Tab springt auf „Zum Inhalt springen“.

Warum

Hellgrauer Text auf Weiß ist für viele Menschen schlicht nicht lesbar.

So prüfst du

Fließtext braucht 4,5:1, große Schrift und Bedienelemente 3:1. Miss mit den Entwicklerwerkzeugen oder einem Kontrastrechner.

Warum

Zu kleine Links dicht nebeneinander führen auf dem Smartphone ständig zu Fehlklicks.

So prüfst du

Mindestens 24 × 24 px (WCAG 2.2, Kriterium 2.5.8), auf Touch-Geräten besser 44 px.

Warum

Ein Platzhaltertext verschwindet beim Tippen und ersetzt kein Label.

So prüfst du

Jedes Feld hat ein sichtbares Label, und Fehlermeldungen sagen, was falsch ist und wie es richtig geht.

Warum

Viele Menschen vergrößern die Schrift, und dann überlappen Texte oder Buttons verschwinden.

So prüfst du

Zoom im Browser auf 200 % und prüf, ob alles lesbar und bedienbar bleibt.

Warum

Erst beim Vorlesen fällt auf, dass ein Button nur „Button“ heißt oder ein Dialog den Fokus verliert.

So prüfst du

Geh die wichtigsten Abläufe mit VoiceOver auf Mac und iPhone durch.

Warum

Mit Landmarks springen Screenreader-Nutzer direkt zu Navigation oder Hauptinhalt.

So prüfst du

Nutz header, nav, main und footer und zeichne fremdsprachige Passagen mit einem eigenen lang-Attribut aus.

Warum

Animationen können bei Menschen mit Gleichgewichtsstörungen Schwindel auslösen.

So prüfst du

Stell im Betriebssystem „Bewegung reduzieren“ ein und prüf, ob Animationen ausbleiben. Was länger als fünf Sekunden von selbst läuft, lässt sich pausieren.

Warum

WebGL- und Video-Hintergründe kosten Akku und Rechenleistung, auch wenn sie gerade niemand sieht.

So prüfst du

Animierte Hintergründe pausieren außerhalb des sichtbaren Bereichs und bei inaktivem Tab und zeigen ohne WebGL ein Standbild.

Warum

Kurze Übergänge bei Hover, Laden und Erfolg zeigen, dass die Seite reagiert. Lange Effekte halten auf.

So prüfst du

Halte Übergänge kurz und nutz dieselben wenigen Animationen auf der ganzen Website.

Warum

Ein dunkles Logo auf dunklem Grund verschwindet, ohne dass es jemand bemerkt.

So prüfst du

Stell das System auf dunkel und geh jede Seite durch, auch Formulare und Banner.

Warum

Ein Banner, das sich nicht per Tastatur schließen lässt, sperrt Tastaturnutzer aus der ganzen Seite aus.

So prüfst du

Das Banner ist per Tastatur bedienbar, verdeckt keine Bedienelemente und lässt Impressum und Datenschutzerklärung erreichbar.

Warum

Umlaute, lange Namen und eingefügte Adressen bringen schlecht gebaute Formulare aus dem Tritt.

So prüfst du

Teste leere Pflichtfelder, ungültige E-Mails, Umlaute, sehr lange Eingaben und Text aus der Zwischenablage.

Warum

Nur im Browser geprüfte Eingaben lassen sich umgehen und landen ungefiltert in deinem System.

So prüfst du

Schick ungültige Daten direkt an den Server und prüf, ob er sie ablehnt.

Warum

Ohne Spam-Schutz gehen echte Anfragen zwischen Bot-Nachrichten unter.

So prüfst du

Nutz Cloudflare Turnstile oder ein Honeypot-Feld und prüf, ob der Server das Ergebnis tatsächlich auswertet.

Warum

Wer zweimal klickt, schickt sonst zwei Anfragen, und im CRM entstehen Dubletten.

So prüfst du

Deaktivier den Button nach dem ersten Klick und prüf, ob ein Doppelklick zwei Einträge erzeugt.

Warum

Meldet ein Formular Erfolg, obwohl der Versand scheiterte, ist die Anfrage verloren und der Kunde wartet vergeblich.

So prüfst du

Simulier im Netzwerk-Tab einen Ausfall und prüf, ob eine verständliche Fehlermeldung mit Alternative erscheint.

Warum

Erst im Postfach oder CRM zeigt sich, ob eine Anfrage vollständig ankommt.

So prüfst du

Schick eine echte Anfrage und prüf am Ziel jedes Feld, ob im Postfach, im CRM oder in der Datenbank.

Warum

Landet die Benachrichtigung im Spam oder geht die Antwort an dich selbst statt an den Kunden, verlierst du die Anfrage.

So prüfst du

Prüf Posteingang und Spamordner und klick auf „Antworten“: Die Antwort muss an die anfragende Person gehen.

Warum

Jeder Schritt, der nur auf dem Papier getestet ist, kann live scheitern.

So prüfst du

Spiel jeden Ablauf mit Testdaten bis zur Bestätigung durch, Zahlungen im Testmodus des Anbieters.

Warum

Lädt der Kalender oder das Formular eines Drittanbieters nicht, steht der Besucher vor einer leeren Fläche.

So prüfst du

Blockier den Dienst testweise im Browser. Eine E-Mail-Adresse oder Telefonnummer bleibt als Alternative sichtbar.

Warum

E-Mail-Adressen in URL-Parametern landen in Logs, Analytics und im nächsten geteilten Link.

So prüfst du

Schick ein Testformular ab und prüf die Adresszeile, die Weiterleitung und die gesendeten Analytics-Ereignisse.

Warum

Mit dem richtigen Feldtyp öffnet das Smartphone die passende Tastatur, und der Browser füllt Daten selbst aus.

So prüfst du

Nutz type="email" und type="tel" und autocomplete-Werte wie name, email und tel.

Warum

Übernimmt die Bestätigungsmail frei eingegebenen Text, nutzen Spammer dein Formular als Versandweg.

So prüfst du

Prüf die Vorlage: Sie enthält keine Feldinhalte und keine Links aus Eingaben.

Warum

Buchungen in eingebetteten Kalendern oder Formularen zählt dein Analytics sonst nicht als Conversion.

So prüfst du

Buch einen Testtermin und prüf, ob das Ereignis ankommt und der Rückweg auf deine Seite funktioniert.

Warum

Anfragen, die jahrelang im Formulardienst liegen, sind ein Datenschutzrisiko ohne Nutzen.

So prüfst du

Leg fest, wann Einträge gelöscht werden, und richte eine Erinnerung oder eine automatische Löschung ein.

Warum

Ein Wert vom eigenen schnellen Rechner sagt nichts über ein Mittelklasse-Smartphone im Mobilfunknetz.

So prüfst du

Teste Startseite, eine Leistungsseite und einen Artikel in PageSpeed Insights, mobil zuerst.

Warum

Als gut gilt eine Seite bei LCP bis 2,5 s, INP bis 200 ms und CLS bis 0,1.

So prüfst du

Miss LCP und CLS im Labor. INP gibt es nur aus echten Nutzerdaten, im Labor dient Total Blocking Time als Näherung.

Warum

Was im Büro-WLAN flüssig läuft, ruckelt auf einem älteren Smartphone.

So prüfst du

Drossle in den Entwicklerwerkzeugen auf „Slow 4G“ und eine vierfach verlangsamte CPU und lade die Seite neu.

Warum

Laborwerte sind eine Schätzung. Was Besucher erleben, zeigen erst Felddaten.

So prüfst du

Prüf nach vier Wochen den Bericht „Core Web Vitals“ in der Search Console.

Warum

Jedes Fremdskript verlängert die Ladezeit, auch wenn niemand mehr seine Daten auswertet.

So prüfst du

Liste alle Skripte im Netzwerk-Tab auf, streich ungenutzte und verlagere Tracking, wo es geht, auf den Server.

Warum

Eine Schriftfamilie in acht Schnitten kann mehr laden als alle Bilder zusammen.

So prüfst du

Nutz WOFF2, nur die nötigen Schnitte und Zeichen, lade die wichtigste Schrift vor und setz font-display.

Warum

Ohne Caching lädt jeder Besucher bei jedem Seitenwechsel alles neu.

So prüfst du

Prüf in den Response-Headern Brotli oder gzip und lange Cache-Zeiten für versionierte Dateien. Nach einer Veröffentlichung ist die neue Version sofort sichtbar.

Warum

Ein JavaScript-Fehler kann Menü, Formular oder Tracking lahmlegen, ohne dass es optisch auffällt.

So prüfst du

Öffne auf jeder Seitenvorlage die Konsole und beheb rote Meldungen und 404-Anfragen.

Warum

Tote Links ärgern Besucher und verschenken interne Linkkraft.

So prüfst du

Crawl die Website mit einem Link-Checker und öffne die wichtigsten Ziele zusätzlich von Hand.

Warum

Liefert die Fehlerseite den Status 200, hält Google sie für eine normale Seite.

So prüfst du

Ruf eine erfundene URL auf und prüf im Netzwerk-Tab den Statuscode.

Warum

Eine Seite, die versehentlich 301 oder 500 liefert, ist für Besucher und Google weg.

So prüfst du

Frag die wichtigsten URLs mit curl -I oder einem Crawler ab. Jede antwortet mit 200.

Warum

Werbeblocker sperren viele Fremdskripte. Hängt das Formular an einem davon, kommt keine Anfrage an.

So prüfst du

Teste die Seite mit aktivem Werbeblocker: Inhalte, Navigation und Formular funktionieren weiter.

Warum

Wer erst nach dem Launch überlegt, was er messen will, hat aus den ersten Wochen keine Daten.

So prüfst du

Schreib auf, welche Ereignisse zählen: Anfragen, Buchungen, Käufe und die wichtigsten Klicks, jeweils mit Namen und Parametern.

Warum

Ein Ereignis, das bei jedem Neuladen der Danke-Seite feuert, verdoppelt deine Conversions.

So prüfst du

Lös jedes Ereignis einmal aus und prüf in der Echtzeit- oder Debug-Ansicht Anzahl und Werte.

Warum

Läuft Analytics zugleich über eine Integration im CMS und über den Tag Manager, zählt alles doppelt, und einer der Wege umgeht meist den Consent.

So prüfst du

Prüf CMS-Integrationen, Tag Manager und eigene Skripte und behalte für jeden Dienst genau einen Weg.

Warum

Bei kleinen Websites machen Testbesuche und Bots schnell einen großen Teil der Zahlen aus.

So prüfst du

Leg Filter für interne Zugriffe an und prüf auffällige Länder, Quellen und Sitzungen mit null Sekunden.

Warum

Erst im echten Browser zeigt sich, ob Dienste nach einer Ablehnung wirklich stumm bleiben.

So prüfst du

Teste im privaten Fenster mit leeren Cookies. Je nach Einstellung lädt Zaraz für automatisierte Anfragen gar nicht, eine Prüfung per curl sagt dann nichts.

Warum

Ohne Consent Mode v2 schränkt Google Messung und Remarketing für Besucher aus dem EWR ein.

So prüfst du

Prüf mit dem Tag Assistant, ob die Consent-Werte nach Zustimmung und Ablehnung richtig übergeben werden.

Warum

Werkzeuge wie Microsoft Clarity zeichnen Klicks, Scrollen und Eingaben auf. Clarity verlangt seit dem 31.10.2025 für Besucher aus EWR, Großbritannien und der Schweiz ein Consent-Signal.

So prüfst du

Lade das Werkzeug erst nach Zustimmung, übergib das Consent-Signal und prüf, ob Formularfelder maskiert sind.

Warum

Senden Browser und Server dasselbe Ereignis, zählt die Plattform es doppelt.

So prüfst du

Prüf Conversions API oder Measurement Protocol mit Test-Ereignissen und deduplizier über eine gemeinsame Event-ID.

Warum

Mal „linkedin“, mal „LinkedIn“: Uneinheitliche Parameter zerlegen eine Kampagne in mehrere Zeilen.

So prüfst du

Leg Schreibweisen für Quelle, Medium und Kampagne fest und bau Kampagnenlinks nur noch danach.

Warum

GA4 löscht Detaildaten in der Standardeinstellung schon nach zwei Monaten.

So prüfst du

Stell die Datenaufbewahrung auf 14 Monate, entscheide bewusst über Google Signals und leg einen Filter für internen Traffic an.

Warum

Ein Test ohne Hypothese und Mindestlaufzeit liefert Zufall, der wie ein Ergebnis aussieht.

So prüfst du

Leg Hypothese und Laufzeit vorab fest, prüf, ob die Variante ohne Flackern lädt, und teste nicht auf Rechtsseiten.

Warum

Werbeblocker filtern die Standardpfade unter /cdn-cgi/zaraz/ nach Muster, eigene Pfade auf deiner Domain fallen nicht auf.

So prüfst du

Stell Initialization, Main und Track in den Zaraz-Einstellungen auf eigene Pfade, etwa /_zi, /_zm und /_zt. Mit keinem davon darf eine Adresse deiner Website beginnen.

Warum

Ein Loader, der noch auf den alten Pfad zeigt, läuft auf 404, und Banner und Tracking fehlen, ohne dass etwas sichtbar kaputtgeht.

So prüfst du

Such im Quelltext nach /cdn-cgi/zaraz/i.js und ersetz jeden Fund durch den neuen Pfad.

Warum

Ob Cloudflare das Zaraz-Skript selbst einfügt, hängt vom Setup ab.

So prüfst du

Ruf das ausgelieferte HTML ab und zähl die Script-Tags von Zaraz. Es muss genau eines sein.

Warum

Bei Cloudflare Workers mit Static Assets fügt die Edge das Zaraz-Skript nicht automatisch ein.

So prüfst du

Setz autoInjectScript auf false und schreib den Loader vor </head> ins HTML.

Warum

Cloudflare dokumentiert die Selektoren des Consent-Modals nicht, handgeschriebenes CSS bleibt deshalb Raterei.

So prüfst du

Erzeug das CSS mit dem Zaraz Consent Banner Designer und setz es unter Zaraz, Consent, Custom CSS ein.

Warum

Zaraz prüft nur, womit eine Adresse beginnt. Mit dem Track-Pfad /t bekommen echte Besucher auf jeder Seite, die mit /t anfängt, eine Fehlermeldung statt Inhalt.

So prüfst du

Vergleich jede Adresse aus der Sitemap mit deinen drei Zaraz-Pfaden, keine darf so beginnen. Prüf danach eine Seite in einem normalen Browser: curl und Headless-Browser sehen den Fehler nicht, weil Zaraz automatisierte Abrufe durchreicht.

Warum

Anzeigenlinks tragen UTM-Parameter, und Meta hängt an jeden Klick noch eine eigene Kennung an. Lädt die Zielseite nur ohne diese Zusätze richtig, zahlst du für jeden Klick, der auf einer Fehlerseite landet.

So prüfst du

Ruf jede Zielseite einmal mit dem fertigen Anzeigenlink auf und einmal mit angehängtem ?fbclid=test. Vergleich Status, Seitentitel und Inhalt mit dem Abruf ohne Zusätze und prüf, ob die Parameter nach Weiterleitungen noch in der Adresse stehen. Ein Status 200 allein reicht nicht, es muss wirklich deine Zielseite antworten.

Warum

Die webflow.io-Adresse ist sonst eine vollständige Kopie deiner Website in Google.

So prüfst du

Deaktivier in den Site Settings unter SEO die Indexierung der Webflow-Subdomain und setz die globale Canonical-URL.

Warum

Eine Analytics-ID unter Integrations oder eine Google-Schrift unter Fonts lädt an jedem Cookie-Banner vorbei.

So prüfst du

Geh Integrations und Fonts durch und entfern alles, was über deinen Consent-Manager laufen soll oder nicht genutzt wird.

Warum

Steht die Datenerhebung auf „immer“, sammeln beide Werkzeuge Daten vor jeder Zustimmung.

So prüfst du

Stell die Datenerhebung von Analyze und Optimize auf Einwilligung um und verbinde sie mit deinem Banner.

Warum

Ein fest eingetragener /de-Link schickt Besucher der englischen Version zurück ins Deutsche.

So prüfst du

Verlink interne Seiten als Seitenlink statt als URL und klick die Navigation in jeder Sprache durch.

Warum

Unübersetzte Slugs, SEO-Felder oder Alt-Texte verraten sofort, dass die zweite Sprache nachgeschoben wurde.

So prüfst du

Prüf je Sprache Slug, Seitentitel, Beschreibung, Open-Graph-Bild und Alt-Texte, auch in CMS-Einträgen.

Warum

Leere Vorlagenseiten, falsche Bildfelder oder Entwürfe in Listen fallen erst live auf.

So prüfst du

Prüf, ob Entwürfe nirgends verlinkt sind, dünne Vorlagenseiten noindex haben, das Open-Graph-Bild am richtigen Feld hängt und das gewollte Datum erscheint.

Warum

Empfänger, Antwortadresse und Meldungen sind in Webflow eigene Einstellungen, die beim Bauen leicht vergessen werden.

So prüfst du

Prüf in den Site Settings Empfänger der Benachrichtigung, Antwortadresse und Spam-Schutz und übersetz Erfolgs- und Fehlermeldung.

Warum

Webflow leitet alte URLs nur weiter, wenn sie in den Einstellungen eingetragen sind.

So prüfst du

Trag jede alte URL in den Site Settings unter Publishing bei den 301-Weiterleitungen ein und teste sie nach dem Veröffentlichen.

Warum

Alles im Custom Code steht öffentlich im Quelltext jeder Seite.

So prüfst du

Such im Custom Code von Website, Seiten und Embeds nach Schlüsseln und Passwörtern und leg den Code zusätzlich versioniert außerhalb von Webflow ab.

Warum

Ein Klick auf „Publish“ mit falsch gesetzten Domains bringt halbfertige Seiten live.

So prüfst du

Veröffentlich Zwischenstände nur auf der webflow.io-Adresse und die eigene Domain erst nach Freigabe.

Warum

Ein benanntes Backup findest du im Notfall schneller als einen von vielen automatischen Ständen.

So prüfst du

Leg unter Backups einen benannten Stand an, bevor du auf die eigene Domain veröffentlichst.

Warum

Ungenutzte Klassen, Interaktionen und Assets blähen CSS und Datenmenge auf.

So prüfst du

Nutz im Style Manager „Clean up“, lösch ungenutzte Interaktionen und Assets und aktivier die Minify-Optionen, falls angeboten.

Warum

Mit falschem SSL-Modus oder zu aggressivem Cache drohen Weiterleitungsschleifen oder alte Inhalte nach dem Publish.

So prüfst du

Stell SSL auf Full (strict) und richte die Cache-Regeln so ein, dass eine Veröffentlichung sofort sichtbar ist.

Warum

Formularlimit, CMS-Einträge, Bandbreite und Sprachen hängen am Site-Plan.

So prüfst du

Vergleich die Grenzen deines Plans mit dem, was die Website zum Launch und im ersten Jahr braucht.

Warum

404-Seite, Passwortseite und Suchergebnisse bleiben sonst im Webflow-Standard und auf Englisch.

So prüfst du

Öffne jede Utility-Seite in jeder Sprache und pass Design und Texte an.

Warum

Beim Übersetzen kann Webflow ein Icon, das als SVG im Element steckt, durch ein leeres Element ersetzen, und niemand bekommt eine Warnung.

So prüfst du

Vergleich nach jedem Übersetzungsdurchgang die Icons und Grafiken jeder Seite in beiden Sprachen und halte Text und Icon in getrennten Elementen.

Warum

Eine .env-Datei im Repository ist für alle mit Zugriff lesbar und bei einem öffentlichen Repository für jeden.

So prüfst du

Prüf .gitignore und den Build-Ordner auf .env und .dev.vars und leg Secrets mit wrangler secret oder im Secrets Store ab.

Warum

Im Modus single-page-application liefert jede unbekannte URL Status 200 und wird zur Soft-404.

So prüfst du

Setz not_found_handling für Websites auf 404-page und prüf eine erfundene URL auf Status 404.

Warum

Fehler in _headers oder _redirects fallen erst live auf.

So prüfst du

Ruf betroffene URLs mit curl -I ab und prüf Header, Statuscodes und Weiterleitungsziele.

Warum

Die workers.dev-Adresse ist sonst eine zweite, öffentlich erreichbare Kopie deiner Website.

So prüfst du

Deaktivier die workers.dev-Route oder schütz Vorschauen mit Cloudflare Access.

Warum

Hydration-Fehler und fehlende Umgebungsvariablen zeigen sich oft erst im Produktions-Build.

So prüfst du

Bau und starte die Produktionsversion lokal und lies jede Warnung.

Warum

Öffentliche Source Maps zeigen deinen vollständigen Quellcode samt Kommentaren.

So prüfst du

Prüf, ob .map-Dateien öffentlich abrufbar sind, und entscheide bewusst, ob das so bleiben soll.

Warum

Bindings, Routen und Custom Domain, die nur für die Entwicklung gesetzt sind, fehlen live.

So prüfst du

Prüf in wrangler.jsonc die Produktionsumgebung: KV, D1, R2, Routen und Domain.

Warum

Ohne Logs suchst du Fehler nach dem Launch im Dunkeln.

So prüfst du

Aktivier Workers Logs und prüf Stichproben auf E-Mail-Adressen, IPs und Formularinhalte.

Warum

Ein falscher DNS-Eintrag macht die Website unter Umständen stundenlang unerreichbar.

So prüfst du

Prüf A-, AAAA- und CNAME-Einträge gegen die Vorgaben deines Hosters und ruf alle Domainvarianten auf.

Warum

Wer beim Umzug die MX-Einträge vergisst, bekommt ab dem Launch keine E-Mails mehr.

So prüfst du

Exportier alle Einträge, besonders MX, SPF, DKIM, DMARC und Verifizierungs-TXT, und übernimm sie vollständig.

Warum

Mit hoher TTL landen manche Besucher noch einen Tag lang auf der alten Adresse.

So prüfst du

Senk die TTL einen Tag vorher auf wenige Minuten und erhöh sie nach dem Launch wieder.

Warum

Eine offene Vorschau zeigt Unfertiges und landet im Index.

So prüfst du

Schütz Vorschauen mit Passwort oder Zugriffsschutz.

Warum

Eine Test-API, ein Sandbox-Zahlungskonto oder ein Debug-Schalter im Live-Betrieb fällt erst beim ersten Kunden auf.

So prüfst du

Prüf Umgebungsvariablen, API-Schlüssel und Anbindungen an andere Dienste auf Produktionswerte.

Warum

Ein erreichbarer /.git-Ordner gibt den kompletten Quellcode samt Historie preis.

So prüfst du

Ruf /.git/config, /.env und bekannte Backup-Dateien auf deiner Domain auf. Jede Anfrage muss 404 liefern.

Warum

Ein Backup, das nie zurückgespielt wurde, ist nur eine Hoffnung.

So prüfst du

Leg ein Backup an und spiel es einmal testweise zurück, etwa in eine Staging-Umgebung.

Warum

Bricht nach dem Launch etwas, entscheidet die Zeit bis zum alten Stand über den Schaden.

So prüfst du

Schreib den Rückweg als Befehl oder Klickpfad auf, bevor du veröffentlichst.

Warum

Fällt die Seite nachts aus, merkt es sonst der erste Kunde am Morgen.

So prüfst du

Richte einen Uptime-Check mit Alarm ein, überwach Domain- und Zertifikatsablauf und leg fest, wer reagiert.

Warum

Ein Launch am Freitagnachmittag heißt: Fehler bleiben übers Wochenende stehen.

So prüfst du

Veröffentlich nicht vor Wochenende, Feiertag oder Urlaub und plan in den Tagen danach Zeit für Korrekturen ein.

Warum

Live verhält sich anders als Staging: andere Domain, anderer Cache, echtes DNS.

So prüfst du

Prüf auf der echten Domain Startseite, wichtige Unterseiten, Formulare, Banner und Tracking.

Warum

Wer einen Link ungeprüft weitergibt, riskiert, dass der Kunde den ersten Fehler findet.

So prüfst du

Gib bei der Übergabe genau die öffentliche URL weiter, die du gerade getestet hast.

Warum

Wird das alte Hosting zu früh gekündigt, fehlen Weiterleitungen, E-Mail oder Daten, die noch daran hingen.

So prüfst du

Kündige erst, wenn Weiterleitungen, E-Mail und Formulare auf dem neuen Stand nachweislich laufen.

Warum

Kaputtes Tracking oder ein stummes Formular fällt sonst erst Wochen später auf.

So prüfst du

Richte eine Benachrichtigung ein, wenn Formulareingänge, Conversions oder Tracking-Ereignisse plötzlich auf null fallen.

Warum

Läuft die Domain auf die Agentur, gehört dem Kunden seine eigene Adresse nicht.

So prüfst du

Domain, Hosting, CMS, Analytics und Search Console laufen auf den Kunden. Dienstleister bekommen eigene Zugänge statt geteilter Passwörter.

Warum

Ein Team, das das CMS nicht bedienen kann, ruft für jede Textänderung an oder lässt die Seite veralten.

So prüfst du

Zeige, wie Inhalte gepflegt und Formulareingänge gefunden werden, und gib eine Kurzanleitung mit.

Warum

In einem Jahr weiß sonst niemand mehr, wo das DNS verwaltet wird.

So prüfst du

Schreib auf, wo Code, Zugänge, DNS und Tracking-Konfiguration liegen, und leg die Zugänge in einem gemeinsamen Passwortmanager ab.

Warum

Probleme bei Indexierung, Zustellung und Conversions zeigen sich erst mit etwas Abstand.

So prüfst du

Prüf zu jedem Termin Indexierung, Formulare, E-Mail-Zustellung, Fehler und Conversions.

Warum

Die Nutzerdaten von Chrome sammeln sich über 28 Tage, vorher gibt es kein verlässliches Bild.

So prüfst du

Prüf nach vier Wochen PageSpeed Insights und die Search Console, sofern die Seite genug Besucher hat.

Warum

Nach einem Relaunch zeigen sich fehlende Weiterleitungen als steigende Zahl von 404-Fehlern.

So prüfst du

Prüf Indexierung, 404-Fehler und die Weiterleitungen der alten URLs und vergleich die Klicks mit der Ausgangslage.

Warum

Erst der Vergleich mit dem Ausgangswert zeigt, ob deine Änderungen wirken.

So prüfst du

Stell nach vier und nach zwölf Wochen dieselben Fragen wie vor dem Launch und vergleich die Antworten.

Warum

Alte Links in Profilen und Signaturen schicken Besucher über Umwege oder ins Leere.

So prüfst du

Pass Social-Profile, E-Mail-Signaturen, Unternehmensprofile und Verzeichnisse an und bitte wichtige Partner um aktualisierte Links.

Warum

Wer den Launch bewirbt, bevor alles läuft, schickt die meisten Besucher direkt in die Fehler.

So prüfst du

Kündige auf LinkedIn, im Newsletter und bei Bestandskunden erst an, wenn der Test auf der echten Domain bestanden ist.

Warum

Externe Seiten ziehen um, und Links, die gestern funktioniert haben, laufen ins Leere.

So prüfst du

Crawl die Website einmal im Quartal und beheb tote Links.

Warum

Neue Werkzeuge kommen oft ohne Absprache dazu und laufen dann am Banner vorbei.

So prüfst du

Miss die Anfragen im privaten Fenster neu und gleich sie mit Banner und Datenschutzerklärung ab.

Warum

Bekannte Sicherheitslücken in alten Versionen werden gezielt ausgenutzt.

So prüfst du

Aktualisier Pakete und Fremdskripte und prüf danach die wichtigsten Abläufe.

Warum

Ehemalige Mitarbeitende und Dienstleister haben oft noch lange Zugriff.

So prüfst du

Entfern Zugänge, die niemand mehr braucht, und prüf, ob 2FA überall aktiv ist.

Warum

Ob ein Backup taugt, zeigt sich nur beim Zurückspielen.

So prüfst du

Spiel einmal im Quartal ein Backup testweise zurück.

Warum

Domain, Zertifikat, Hosting und Lizenzen laufen sonst an einem ungünstigen Tag ab.

So prüfst du

Prüf Ablaufdaten und automatische Verlängerungen.

Warum

Ein schleichender Rückgang fällt nur im Vergleich mit dem letzten Quartal auf.

So prüfst du

Vergleich Core Web Vitals, Search Console und KI-Sichtbarkeit mit der letzten Runde.

Warum

Alte Preise, ehemalige Teammitglieder und Referenzen von vor Jahren kosten Vertrauen.

So prüfst du

Prüf Preise, Team, Referenzen und Jahreszahlen.