# Website-Checkliste vor dem Go-live: Was wir prüfen, bevor eine Website online gehen darf > URL: https://4eck-media.de/blog/website-checkliste-vor-go-live-qualitaet-statt-pfusch/ > Language: de > Description: Was unterscheidet eine gute Website von technischem Pfusch? Matthias Petri veröffentlicht die interne Before-Live-Checkliste von 4eck Media – von Hero-Bildern und Browser-Tests bis PageSpeed, Accessibility, Markup und SEO. --- Es gibt einen Moment, den jeder kennt, der Websites baut. Das Projekt ist „fertig“. Die Farben stimmen, die Bilder sitzen, der Kunde hat das Design im Meeting gefeiert, und im Projektchat steht die Frage: „Können wir dann diese Woche live gehen?“ Alles in mir will Ja sagen. Genau an dieser Stelle beginnt der Teil unserer Arbeit, über den fast nie jemand spricht. Denn zwischen „sieht fertig aus“ und „ist fertig“ liegt eine Liste. Unsere ist über Jahre gewachsen, und fast jeder Punkt darauf hat eine Vorgeschichte: ein Hero-Bild, das auf dem iPad den Kopf des Geschäftsführers abgeschnitten hat. Ein Kontaktformular, das eine grüne Erfolgsmeldung zeigte und trotzdem keine einzige E-Mail zustellte. Eine Überschrift, die wegen eines einzigen langen deutschen Wortes aus dem Bildschirm lief. Nichts davon war im Design zu sehen. Alles davon war live zu sehen. Für den Kunden ist die Website in so einem Moment nicht zu 95 Prozent fertig. Sie ist kaputt. Er unterscheidet nicht zwischen Design, Frontend, Hosting und Inhaltspflege. Er sieht eine Website, und jeder Fehler trägt das Logo seines Unternehmens. Deshalb veröffentlichen wir hier unsere komplette interne Checkliste für die Zeit vor dem Go-live. Sie ist kein Geheimwissen, und genau das ist der Punkt: Der Unterschied zwischen einer professionellen Website und einem Feierabendprojekt ist selten Talent. Es ist Disziplin. Bei uns in der Agentur gibt es kein „passt schon“ und kein „sieht doch gut aus“. Ein Punkt ist erledigt oder er ist es nicht. Dazwischen gibt es nichts. Dieser Artikel behandelt alles, was vor der Veröffentlichung geprüft wird. Für die Zeit danach gibt es eine zweite Liste und einen [eigenen Artikel über die Prüfungen nach dem Go-live](https://4eck-media.de/blog/website-launch-checkliste-nach-go-live/) – denn eine Website, die online ist, ist noch lange nicht fertig. Fertig ist nicht dasselbe wie geprüft - Designfreigabe bedeutet: Die Richtung stimmt. Sie bedeutet nicht, dass jedes Gerät getestet wurde. - Ein Go-live-Test bewertet Funktion, Darstellung, Technik und Auffindbarkeit gemeinsam. - Vor dem Launch wird vorbereitet; nach dem Launch wird unter echten Produktionsbedingungen bestätigt. - Jeder Prüfpunkt braucht eine verantwortliche Person und ein nachvollziehbares Ergebnis. - Wenn der Kunde den Fehler zuerst findet, war die Qualitätssicherung nicht fertig. ## Ein Design, vier Wahrheiten: Desktop, Notebook, Tablet, Smartphone Websites werden auf großen, ruhigen Monitoren gebaut und auf kleinen, unruhigen Geräten benutzt. Das ist das Grundproblem fast jeder Designabnahme. Der Entwurf wurde auf 27 Zoll gezeigt und freigegeben. Der Besucher kommt mit einem drei Jahre alten Smartphone, hält es mit einer Hand und hat eine halbe Minute Geduld. Deshalb prüfen wir jedes Projekt auf vier Geräteklassen, und zwar nicht nur die Startseite. Leistungsseiten, Blogartikel, Formulare, Übersichten, bei Shops Produkt und Checkout: Jedes Template hat seine eigenen Bruchstellen. Nur die Startseite zu kontrollieren ist keine Website-Prüfung. Es ist eine Startseiten-Prüfung. ![Responsive Webdesign der Bolzakademie auf Tablet und Smartphone mit identischer Startseite](https://4eck-media.de/wp-content/uploads/2026/07/responsive-webdesign-bolzakademie-tablet-smartphone-startseite.avif) ### Desktop und Notebook: der erste Bildschirm entscheidet Auf großen Monitoren achte ich auf zu lange Textzeilen, verlorene Inhalte in riesigen Weißflächen und Container, die ohne Maximalbreite auseinanderlaufen. Ein Layout, das auf 1440 Pixeln ausgewogen wirkt, kann auf einem 27-Zoll-Display zerfallen. Das Notebook ist dabei kein verkleinerter Desktop. Auf 13 bis 15 Zoll ist die Höhe das eigentliche Problem: Browserleiste und Betriebssystem nehmen Platz weg, und ein Hero, der auf dem Monitor elegant wirkt, belegt auf dem Notebook den kompletten sichtbaren Bereich. Ich prüfe deshalb den ersten Bildschirm wie ein Besucher: Ist sofort verständlich, worum es geht? Ist der wichtigste Button erreichbar, oder verdecken ihn Cookie-Banner und Sticky Header? Erkennt man überhaupt, dass es unten weitergeht? ### Tablet: die unangenehme Mitte Tablets werden in vielen Projekten zuletzt getestet. Desktop ist wichtig, Mobile ist wichtig, und dazwischen wird es schon passen. Genau dort entstehen die hässlichsten Fehler: Ein Tablet ist breit genug, um Desktop-Regeln zu aktivieren, aber zu schmal, um deren Inhalte sauber aufzunehmen. Zwei Spalten werden gequetscht, die Navigation passt gerade nicht mehr in eine Zeile, Bilder verlieren ihren Fokus. In unserer Liste stehen dafür iPad mini und iPad Pro – nicht aus Markenliebe, sondern weil wir zwei deutlich unterschiedliche Größenklassen und wiederholbare Testbedingungen brauchen. Und ich drehe das Gerät bewusst: Ein iPad Pro quer ist fast ein Notebook. Dasselbe iPad hochkant stellt Hero, Tabellen und Kartenreihen vor völlig andere Aufgaben. ### Smartphone: nicht schmaler, sondern anders Auf dem Telefon wird eine Website mit dem Daumen bedient, unter Zeitdruck, oft unterwegs. Ein Desktop-Layout einfach zu stapeln reicht nicht. Inhalte müssen priorisiert werden, Buttons brauchen echte Touch-Flächen, Formulare müssen die richtige Tastatur öffnen, Telefonnummern müssen sich antippen lassen. Als Referenz dienen uns iPhone 12 und iPhone 14 Pro plus simulierte Viewports im Browser – die echten Geräte bleiben trotzdem Pflicht, weil keine Simulation Browserleisten, Touch-Verhalten und reale Performance vollständig nachbildet. Ein einziges Element mit fester Breite macht die ganze Seite horizontal verschiebbar. Ein Popup, dessen Schließen-Kreuz außerhalb des Bildschirms liegt, blockiert den Besucher komplett. Und die Prüffrage ist nie nur „Ist alles sichtbar?“, sondern: Steht das Wichtige früh genug? Trifft man den Link, ohne den Nachbarlink zu erwischen? Erscheint die Fehlermeldung am betroffenen Feld oder irgendwo außerhalb des Sichtbereichs? Viele Qualitätsprobleme sind nicht spektakulär genug für einen Bugreport. Sie erzeugen einfach Reibung, und in Analytics sieht man später nur die schlechtere Conversionrate. ## Hero-Bilder: die halbe Stunde, die niemand im Angebot sieht Ich liebe unsere Designer. Wirklich. Aber ein Bild über die volle Bildschirmbreite ist fast immer ein technischer Kompromiss und regelmäßig ein kleiner Kampf. Im Entwurf sitzt das Hero perfekt auf seiner festen Fläche. Im Browser existiert diese Fläche nicht: Der eine Besucher hält ein Tablet hochkant, der nächste sitzt vor einem Ultrawide-Monitor, und beide sollen dasselbe Gesicht, dasselbe Produkt, dieselbe Linie an der richtigen Stelle sehen. Technisch lösen wir das über mehrere Bildgrößen: Unser Theme arbeitet mit sechs Layoutstufen – einer mobilen Basis und den Breiten ab 576, 768, 992, 1200 und 1710 Pixeln. Über srcset und sizes wählt der Browser die passende AVIF-Variante, statt überall das größte Original zu laden. Damit ist die Dateigröße gelöst. Die Bildkomposition ist es nicht: Mit object-fit wird die Fläche gefüllt, aber irgendetwas wird immer abgeschnitten. Mit object-position bestimme ich, welcher Bereich überlebt. Das funktioniert nur, wenn ich das Motiv wirklich auf mehreren Seitenverhältnissen ansehe. Dazu kommt ein Gespräch, das ich regelmäßig führe: „Wir haben doch hochauflösendes Material geschickt.“ Gemeint ist Full HD. 1920 mal 1080 Pixel klingen groß, sind aber für ein vollflächiges Bild auf einem großen Retina-Display schlicht zu wenig – und wenn noch ein Ausschnitt gewählt werden muss, bleiben für die sichtbare Fläche noch weniger echte Pixel. Das Ergebnis ist ein Hero, das auf dem Notebook sauber und auf dem großen Monitor weich aussieht. Natürlich kann KI hochskalieren. Das rettet manche Motive, erfindet aber Details: Haare, Hände, Schrift und Fassaden sind typische Problemzonen. Wenn das Material die Auflösung nicht hergibt, verspreche ich keine Magie – dann ändern wir Ausschnitt, Fläche oder Hero-Typ. Das ist keine Niederlage des Designs. Das ist eine ehrliche Entscheidung. Für ein einziges schwieriges Hero gehen in Summe schnell 30 Minuten drauf: Datei prüfen, Varianten erzeugen, Fokus setzen, Tablet drehen, Ultrawide testen, Kontrast korrigieren, erneut exportieren. Diese halbe Stunde sieht später niemand. Wenn sie fehlt, sieht es jeder. Unsere Hero-Regel - Ein Full-Width-Hero braucht ein Motiv mit ausreichender Reserve – im Zweifel bis 4K. - Das Original wird nicht überall geladen: Theme, srcset und AVIF liefern passende Varianten aus. - Zuschnitt und Objektposition werden auf Mobile, Tablet, Notebook, Desktop und Ultrawide geprüft. - KI-Upscaling wird auf Artefakte kontrolliert und nicht mit echter Detailauflösung verwechselt. - Full-Width bevorzugt auf der Startseite; Unterseiten erhalten einen robusteren zweiten Hero-Typ. ## Browser-Test: Chrome allein ist keine Freigabe Jeder Entwickler hat einen Lieblingsbrowser, und meistens ist es der, in dem auch entwickelt wird. Das ist normal. Problematisch wird es, wenn derselbe Browser gleichzeitig die einzige Qualitätskontrolle ist. Chrome, Firefox, Safari und Edge sprechen heute weitgehend dieselben Standards – aber nicht in jedem Detail: Schriften werden anders gerendert, Formularfelder sehen anders aus, Sticky-Elemente reagieren in Grenzfällen unterschiedlich, und Safari pflegt seine historischen Eigenheiten. Unsere Checkliste nennt deshalb alle vier Browser ausdrücklich, und geprüft werden die Bausteine mit dem größten Fehlerrisiko: Navigation, Dropdowns, Slider, Video, Cookie-Banner, Formulare, Akkordeons, Tabs, modale Fenster, Sticky-Elemente, Animationen. Safari testen wir auf einem echten Apple-Gerät – eine Chromium-Simulation ersetzt die WebKit-Engine nicht. Typische Funde: eine Schrift, die nicht lädt und alle Umbrüche verschiebt; ein Video, das wegen Autoplay-Regeln stehen bleibt; ein Fokuszustand, der verschwindet. Wir versuchen dabei nicht, jede Browserversion der letzten zehn Jahre zu bedienen; vor Projektbeginn wird festgelegt, was relevant ist. Aber die aktuell verbreiteten Browser einfach nicht zu öffnen, ist keine technische Entscheidung. Es ist Hoffnung. ## Lange Überschriften und ­: der Fehler, der garantiert beim Kunden auftaucht Deutsche Komposita sind für schmale Bildschirme brutal. „Suchmaschinenoptimierungsstrategie“ oder „Barrierefreiheitsstärkungsgesetz“ sprengen ganze Layouts. Automatische Silbentrennung per CSS hilft, hängt aber von Browser, Sprache und Wörterbuch ab – sie ist nicht überall gleich zuverlässig. Deshalb setzen wir in kritische Überschriften von Hand weiche Trennstellen: das unsichtbare Zeichen ­. Solange Platz ist, sieht man nichts. Muss der Browser umbrechen, trennt er an der richtigen Stelle und zeigt einen Bindestrich. ![Fehlerhafte Darstellung langer Wörter auf dem Smartphone ohne gesetzte Soft Hyphens](https://4eck-media.de/wp-content/uploads/2026/07/exec-c87f6807-ca83-4308-bb28-8c5279f93b3f.avif) Warum der Aufwand? Weil dieser Fehler eine besondere Eigenschaft hat: Er taucht nie auf meinem Testgerät auf. Er wartet auf den einen Kunden mit der einen Displaybreite und der vergrößerten Systemschrift – und dann kommt der Screenshot mit der freundlichen Frage, wohin wir eigentlich geschaut haben. Bei langen deutschen Überschriften ist „wird schon umbrechen“ kein Testverfahren. ![Vorher-nachher-Grafik: langes Wort läuft ohne weiche Trennstelle aus dem Smartphone-Bildschirm, mit shy bricht es sauber um](https://4eck-media.de/wp-content/uploads/2026/07/soft-hyphen-long-headlines-mobile.avif) ## Impressum, Datenschutz, Erklärung zur Barrierefreiheit – und das Favicon Eine Website kann gestalterisch hervorragend sein und trotzdem im rechtlichen Blindflug starten. Vor dem Go-live müssen Impressum und Datenschutzerklärung angelegt, verlinkt und von jeder Seite erreichbar sein – und die Links dürfen nicht ausgerechnet vom Cookie-Banner verdeckt werden. Dazu gehört auch die Seite mit der Erklärung zur Barrierefreiheit, die wir für jedes Projekt anlegen: Sie dokumentiert, welchen Stand die Website erfüllt, und gehört wie Impressum und Datenschutz in den Footer. Wichtig ist dabei die Ehrlichkeit über Zuständigkeiten: Wir bauen die technische Grundlage, pflegen gelieferte Texte ein und prüfen die Verlinkung. Die juristische Freigabe der Rechtstexte ersetzen wir nicht. Und der Datenschutztext muss zur echten Website passen: Analytics, externe Videos, Karten, Newsletter, Captcha – was tatsächlich eingebunden ist, muss auch beschrieben sein. Ein Text über eine theoretische Standardwebsite hilft nicht, wenn die produktive Seite andere Datenflüsse hat. Und dann ist da noch das Favicon, der kleinste Punkt der Liste und der am zuverlässigsten vergessene. Fehlt es, zeigt der Tab ein generisches Symbol oder das Icon der Entwicklungsumgebung – kaputt ist dann nichts, aber unfertig sieht es trotzdem aus. Ich prüfe Tab, Lesezeichen und mobile Darstellung. Und das Motiv muss die Verkleinerung überleben: Ein feiner Schriftzug ist bei 16 mal 16 Pixeln nur noch ein Fleck. ## Barrierefreiheit: Designfreigabe allein reicht nicht Barrierefreiheit beginnt im Design – Kontraste, Schriftgrößen, Fokuszustände, logische Struktur – und endet dort nicht. Während Entwicklung und Inhaltspflege entstehen neue Probleme: Ein Redakteur lädt ein Bild ohne Alt-Text hoch, eine Überschrift überspringt Ebenen, ein Formular bekommt eine missverständliche Beschriftung. Deshalb prüfen wir vor dem Go-live noch einmal automatisiert – in unserer Liste stehen AccessibilityChecker und AccessScan – und ergänzen die Scanner um manuelle Stichproben. Denn ein Scanner kann messen, ob ein Alt-Text existiert. Ob er das Bild sinnvoll beschreibt, weiß er nicht. Ich navigiere deshalb selbst ohne Maus durch Navigation, Formulare und Dialoge, verfolge den sichtbaren Fokus, prüfe die Überschriftenhierarchie und provoziere Formularfehler: Erscheint die Meldung am Feld, und versteht man sie? Bleibt die Seite bei Zoom und größerer Schrift benutzbar? Seit dem Barrierefreiheitsstärkungsgesetz vom 28. Juni 2025 ist das für viele Angebote auch eine rechtliche Frage – welche Pflichten konkret gelten, hängt vom Unternehmen ab und ist im Zweifel juristisch zu klären. Meine praktische Haltung ist davon unabhängig: Zugänglichkeit gehört heute zur professionellen Webentwicklung wie HTTPS. Sie ist übrigens kein pauschaler Google-Rankingfaktor, aber vieles, was sie verlangt – saubere Struktur, mobile Bedienbarkeit, verständliche Inhalte – hilft Suchmaschinen und Conversion gleich mit. Wer das Thema ernsthaft angehen will, findet unsere Herangehensweise unter [barrierefreie Websites](https://4eck-media.de/kompetenzen/agentur-barrierefreiheit/). ![WCAG-2.2-Audit der Bolzakademie-Website mit 90 von 100 Punkten und null kritischen Fehlern](https://4eck-media.de/wp-content/uploads/2026/07/barrierefreiheit-wcag-audit-website-bolzakademie-rostock.avif) ## OG-Daten: der erste Eindruck entsteht oft in WhatsApp Bevor ein Besucher die Website sieht, sieht er häufig nur ihre Vorschau: als geteilter Link in WhatsApp, LinkedIn, Slack oder Teams. Diese Vorschau bauen die Open-Graph-Daten – og:title, og:description und vor allem og:image. Sind sie nicht gepflegt, zieht sich der Messenger irgendein Bild aus der Seite, schneidet den Titel ab oder zeigt schlicht gar nichts. Der erste Eindruck der neuen Website ist dann ein grauer Kasten. ![Vergleichsgrafik: Link-Vorschau im Messenger ohne OG-Daten als grauer Kasten, mit OG-Daten als Karte mit Bild, Titel und Beschreibung](https://4eck-media.de/wp-content/uploads/2026/07/og-data-link-preview-messenger.avif) Vor dem Go-live prüfe ich deshalb pro Template: Ist ein Vorschaubild gesetzt, hat es die richtige Größe (1200 mal 630 Pixel als Standard), zeigt es das Richtige, und stimmen Titel und Beschreibung? Nach einem Relaunch besonders wichtig: Die OG-URLs dürfen nicht mehr auf die Entwicklungsdomain zeigen. Der Test ist simpel – Link in einen Messenger oder ein Vorschau-Tool werfen und ansehen, was wirklich erscheint. Es dauert Minuten und entscheidet, wie jede geteilte Empfehlung der Website aussieht. ![OpenGraph-Prüfung der Bolzakademie-Website mit korrekt eingebundenem OG-Bild](https://4eck-media.de/wp-content/uploads/2026/07/og-image-seo-monitor-mockup-16x9-1-e1784893939736.avif) ## Structured Data: die Gebrauchsanweisung für Maschinen Mit strukturierten Daten beschreiben wir die Website so, dass Maschinen nicht nur Wörter sehen, sondern Zusammenhänge: „4eck Media“ ist dann keine Zeichenfolge, sondern eine Organisation mit Adresse, Leistungen, Personen und Bewertungen. Der verbreitete Minimalansatz – SEO-Plugin installieren, Logo hinterlegen, fertig – erzeugt ein Grundgerüst. Wir gehen deutlich weiter und modellieren die reale Website: Organisation, Gründer, Mitarbeiter, Leistungskataloge, Artikel mit Autor und Datum, Breadcrumbs, FAQ. Nicht mit erfundenen Angaben, sondern mit belegbaren. Gerade im Umfeld von KI-Suche zahlt sich das aus: Systeme wie ChatGPT, Gemini oder Perplexity müssen Unternehmen, Personen und Leistungen eindeutig zuordnen können. Strukturierte Daten garantieren keine Empfehlung – sie reduzieren Mehrdeutigkeit. Vor dem Go-live validiere ich mit dem Schema.org-Validator und, wo Google einen Typ unterstützt, mit dem Rich-Results-Test. Und dann kommt die Prüfung, die kein Validator übernimmt: der Abgleich mit der Realität. Wenn im Footer eine andere Telefonnummer steht als im Markup, ist der Code technisch valide und fachlich falsch. Markup ist außerdem kein einmaliger Dekorationscode: Ändern sich Adresse, Team oder Leistungen, muss die maschinenlesbare Ebene mitziehen – sonst produziert sie irgendwann besonders präzise veraltete Informationen. Markup: unser Mindestanspruch - Nicht nur WebSite und Organization, sondern alle relevanten realen Entitäten modellieren. - Unternehmen, Personen, Leistungen, Artikel, Navigation, Breadcrumbs und FAQ miteinander verbinden. - Nur sichtbare, korrekte und belegbare Angaben auszeichnen. - JSON-LD mit Schema.org Validator und gegebenenfalls Googles Rich Results Test prüfen. - Markup bei Änderungen genauso pflegen wie sichtbare Inhalte. ## PageSpeed: 90 ist die Untergrenze, nicht das Ziel PageSpeed ist der Punkt, bei dem ich ungern verhandle. Eine neue Website startet bei uns im grünen Bereich: mindestens 90 Punkte in Google PageSpeed Insights, angestrebt werden 94, 95 und mehr. Nicht, weil zwischen 93 und 95 eine andere Welt liegt – sondern weil wir Reserve brauchen. Nach der Übergabe lebt die Website weiter: Der Kunde lädt irgendwann ein 12-Megabyte-Foto hoch, bettet ein Video ein, ergänzt ein Marketing-Skript. Wer mit genau 90 startet, ist nach der ersten unvorsichtigen Änderung gelb. Wer mit 95 startet, verkraftet den Alltag. Mobile und Desktop messe ich getrennt, und Mobile ist der ehrlichere Test: schwächere CPU, schlechteres Netz, größere Bilder. Hinter dem Score schaue ich auf die Core Web Vitals – LCP (wann ist das größte Element sichtbar? Meistens ist es genau das Hero-Bild von vorhin), INP (wie schnell reagiert die Seite?) und CLS (springt das Layout beim Laden?). Ein Score von 100 mit kaputter Darstellung ist wertlos, aber der umgekehrte Satz „PageSpeed ist doch nur ein Tool“ gilt bei mir auch nicht: Das Tool zeigt echte Risiken. Die Klassiker sind fast immer dieselben – zu große Bilder, blockierendes JavaScript, spät geladene Schriften, Drittanbieter-Skripte. Wie wir das systematisch angehen, steht auf unserer Seite zur [PageSpeed-Optimierung](https://4eck-media.de/kompetenzen/pagespeed-optimierung-core-web-vitals/). ![Google PageSpeed Insights Bericht der Bolzakademie-Website mit Bewertung der Ladezeit](https://4eck-media.de/wp-content/uploads/2026/07/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif) ## Yoast und Seobility: Werkzeuge finden, was Augen übersehen Vor dem Go-live kontrollieren wir die Yoast-Grundeinstellungen und lassen die Website zusätzlich komplett crawlen – dafür nutzen wir Seobility. Der Crawler beantwortet eine Frage, die kein Mensch durch Draufschauen beantworten kann: Fällt irgendwo eine Seite aus der Reihe? Ein Beispiel aus einem unserer letzten Projekte: Der Bereich „Technik & Meta“ stand bei 98 Prozent. Klingt fertig. Die fehlenden zwei Prozent waren zwei problematische Meta-Descriptions, eine Überschriften-Auffälligkeit und drei fehlende Alt-Attribute – genau die Handvoll konkreter Fehler, für die diese Prüfung existiert. Ein hoher Gesamtwert ist kein Grund, die Restliste zu ignorieren. Er ist der Grund, warum die Restliste kurz ist. In Yoast prüfe ich außerdem die Vorlagen: Ein einzelner gepflegter Artikel beweist nichts, wenn ein kompletter Custom Post Type versehentlich auf noindex steht oder automatisch unbrauchbare Titel erzeugt. Und im Crawl achte ich auf Struktur: wichtige Seiten, die fünf Klicks tief vergraben sind; Linktexte wie „mehr“, die niemandem sagen, wohin sie führen; verwaiste Seiten. Ein Tool misst Pfade – ob die Pfade sinnvoll sind, entscheidet ein Mensch. Wer tiefer einsteigen will: Für den großen Rundumblick gibt es das [SEO-Audit](https://4eck-media.de/kompetenzen/seo-audit-analyse-und-optimierung/), vor dem Go-live geht es um die offensichtlichen Fehler, die sich jetzt noch billig beheben lassen. ![Seobility-Analyse der Bolzakademie-Website mit 96 Prozent On-Page-Score](https://4eck-media.de/wp-content/uploads/2026/07/seo-onpage-optimierung-analyse-website-bolzakademie.avif) ## Formulare und E-Mails: Absenden ist noch keine Zustellung Das Kontaktformular ist die Stelle, an der ein scheinbar bestandener Test am gefährlichsten ist. Der Entwickler füllt es aus, sieht die grüne Erfolgsmeldung, Haken dran. Bewiesen ist damit genau eines: Das Frontend hat die Anfrage angenommen. Ob eine E-Mail beim richtigen Postfach angekommen ist, ob die Bestätigung an den Absender rausging, ob die Daten gespeichert wurden – all das ist offen. Wir hatten den Fall in der Praxis: Formular grün, Postfach leer. Der Kunde merkt so etwas erst, wenn er sich wundert, warum seit zwei Wochen niemand anfragt. Deshalb teste ich den kompletten Weg: Pflichtfelder müssen greifen, ungültige Eingaben verständlich abgefangen werden, die Nachricht muss im vorgesehenen Postfach landen – nicht im Spam – und Absendername, Betreff, Reply-To und alle Felder müssen sinnvoll formatiert sein. Für zuverlässige Zustellung richten wir einen SMTP- oder Transaktionsmail-Weg ein; SPF, DKIM und DMARC liegen teils außerhalb von WordPress, entscheiden aber mit, ob die Nachricht als vertrauenswürdig gilt. Geschäftskritische Formulare teste ich mit mehreren Adressen und auf dem Telefon. Und der Spam-Schutz wird vorbereitet, darf aber echte Menschen nicht blockieren – die Feinjustierung folgt nach dem Launch. ## Redirect Map: vor dem Relaunch planen, nicht danach improvisieren Bei einer neuen Domain ohne Vorgänger ist dieser Punkt klein. Bei einem Relaunch ist die Redirect Map eines der wichtigsten Dokumente des Projekts: Jede relevante alte URL bekommt ein sinnvolles neues Ziel – nicht pauschal die Startseite, sondern den inhaltlich nächsten Ersatz. Ich sammle die alten URLs aus Sitemap, Analytics, Search Console und Crawl, wir ordnen Ziele zu und markieren, was bewusst entfällt. Gefährlich sind Ketten und Schleifen: Wenn A auf B zeigt und B später auf C, entstehen unnötige Umwege – besser A direkt auf C. Eine Schleife macht das Ziel komplett unerreichbar. Vorbereitet wird die Map vor dem Go-live; endgültig getestet wird sie auf der produktiven Domain. So treffen wir die Entscheidungen in Ruhe und nicht in dem Moment, in dem die alte Website schon abgeschaltet ist. ![Diagramm: Redirect-Kette A über B nach C, direkte Weiterleitung A nach C und Redirect-Schleife zwischen A und B](https://4eck-media.de/wp-content/uploads/2026/07/redirect-chains-loops-diagram.avif) ## Updates, Aufräumen, Login-Pfad und Beweisfotos Vor dem Go-live bringen wir WordPress, Theme und Plugins auf einen abgestimmten, aktuellen Stand – aber nicht fünf Minuten vor Feierabend und nie ohne Wiederherstellungspunkt. Updates verändern Code; sie schließen Lücken und können genauso gut neue Konflikte einführen. Also: Backup, Update in der Entwicklungsumgebung, kritische Tests wiederholen. Genauso wichtig ist das Aufräumen: Testplugins, Demo-Importe und ungenutzte Themes fliegen raus. Die beste Pluginzahl ist nicht null – es ist die kleinste Zahl, die die vereinbarten Aufgaben zuverlässig erfüllt. In unserer Liste steht außerdem, den Login-Pfad von /wp-login auf einen projektspezifischen Pfad zu ändern. Das hält automatisiertes Grundrauschen fern – und ist ausdrücklich kein Sicherheitskonzept. Ein versteckter Login mit dem Passwort „admin123“ ist nicht sicher. Starke Passwörter, Zwei-Faktor-Authentifizierung, begrenzte Loginversuche und minimale Rechte bleiben die eigentliche Absicherung; Testkonten werden vor dem Launch entfernt. Und bei jedem Relaunch machen wir Screenshots der alten Website: Startseite, wichtige Unterseiten, Navigation, Formulare. Das klingt nach Nostalgie und ist praktische Absicherung – nach der Umschaltung ist der alte Zustand weg, und dann beginnt sonst die Diskussion aus dem Gedächtnis: War dieser Text vorher schon so? Gab es diesen Hinweis? Ein Vorher-nachher-Vergleich beantwortet solche Fragen in Sekunden. ## Übersetzungen: jede Sprache ist eine eigene Website Bei einer mehrsprachigen Website reicht es nicht, die deutsche Version zu prüfen und dem Übersetzungsplugin zu vertrauen. Texte sind unterschiedlich lang: Ein knapper deutscher Button wird auf Französisch breit, eine englische Überschrift passt in eine Zeile, die polnische braucht drei. Menüs, Formulare, SEO-Felder und Alt-Texte können pro Sprache eigene Lücken haben. Ich behandle deshalb jede Sprache wie eine eigene Website: Navigation, Sprachumschalter, zentrale Seiten, Formulare, Meta-Daten, Hreflang. Ein einziger deutscher Button in einer englischen Anfrage-Strecke reicht, damit der Besucher weiß: Hier wurde nicht fertig gearbeitet. Und die wichtigste Lektion aus unserer eigenen Praxis: Der Status „vollständig“ im Übersetzungstool ist kein Beweis – wir haben Felder gesehen, die als übersetzt markiert und trotzdem leer waren. Wie wir große Websites heute per XLIFF und KI übersetzen und uns dabei selbst kontrollieren, steht im [vollständigen Leitfaden zur WordPress-Übersetzung mit KI](https://4eck-media.de/blog/wordpress-mit-ki-uebersetzen-schnell-guenstig-und-ohne-wpml-frust-unser-kompletter-workflow/). ## Wie wir prüfen: Namen, Prioritäten, Beweise Die beste Checkliste hilft nichts, wenn sie als anonyme Tabelle neben dem Projekt liegt. Bei uns hat jeder Punkt einen Namen: Wer prüft Formulare, wer die Übersetzungen, wer die Geräte. Und ein Punkt kennt vier Zustände – geprüft, Fehler gefunden, korrigiert, erneut geprüft. Ein Bug ist nicht erledigt, weil jemand schreibt, dass er ihn behoben hat; die Korrektur kann woanders etwas Neues kaputt machen. Erst der Nachtest schließt den Punkt. Fehler werden priorisiert, sonst poliert jemand drei Stunden einen Zwei-Pixel-Abstand, während das Formular keine Mails sendet: Kritisch ist, was einen zentralen Nutzerweg blockiert. Schwer ist, was eine wichtige Geräteklasse oder rechtliche Pflichten trifft. Der Rest wird dokumentiert und geplant. Und jeder Fund braucht einen brauchbaren Beleg: „Mobile kaputt“ ist keine Information. „Auf 390 mal 844 Pixeln in Safari liegt der Cookie-Button über dem Absende-Button“ lässt sich reproduzieren und beheben. Zwei Regeln noch, die uns oft gerettet haben. Erstens: Wer eine Funktion gebaut hat, nimmt sie nicht allein ab – der Erbauer weiß, wo man klicken muss, und genau deshalb übersieht er die Hürden. Für zentrale Wege gilt das Vier-Augen-Prinzip. Zweitens: Die Freigabe des Kunden ersetzt unsere Prüfung nicht. Der Kunde gibt Design und Inhalte frei; er ist nicht unsere unbezahlte Qualitätssicherung. Wenn er seine Reviewzeit mit Browserbugs verbringt, die wir selbst hätten finden müssen, haben wir seine Aufmerksamkeit verschwendet. Mein Maßstab vor dem Go-live - Kein Gerät wird mit dem Satz „wird schon passen“ abgehakt. - Kein Tool-Score ersetzt die sichtbare und funktionale Kontrolle. - PageSpeed startet grün und mit Reserve für die spätere Pflege. - Markup, Accessibility und SEO sind Bestandteile der Entwicklung, keine Dekoration danach. - Die Website geht erst live, wenn ich das Ergebnis auch auf dem Gerät des Kunden erklären kann. ## Die komplette Before-Live-Checkliste auf einen Blick Die Übersicht ist die verdichtete Version unserer internen Arbeitsliste. Im Projekt wird sie um spezifische Funktionen ergänzt: Eine Unternehmenswebsite braucht keinen Checkout-Test, ein Shop braucht deutlich mehr davon. Kopieren ist ausdrücklich erwünscht – und vergeben Sie für jeden Punkt einen Namen. Ein Häkchen ohne Verantwortlichen ist nur eine leere Zelle. | Prüfpunkt | Was konkret bestätigt werden muss | Typische Folge ohne Prüfung | | --- | --- | --- | | Desktop-Design | Abstände, Container, Textbreiten, Seitenrhythmus und alle Templates | Die Startseite wirkt gut, Unterseiten sehen unfertig aus | | Notebook-Design | Erster sichtbarer Bereich, Hero-Höhe, Sticky Header und Buttons | Wichtiger Inhalt liegt vollständig unterhalb des Folds | | Tablet klein und groß | Hoch- und Querformat, Spalten, Navigation, Tabellen, Slider | Gequetschte Zwischenlayouts und abgeschnittene Motive | | Mobile | Touchflächen, Reihenfolge, Popups, Formulare und horizontales Scrolling | Besucher können zentrale Funktionen nicht bedienen | | Hero-Bilder | Auflösung, responsive Varianten, Zuschnitt, Fokus und Kontrast | Matschige Bilder, Artefakte oder verschwundene Hauptmotive | | Impressum und Datenschutz | Inhalte geliefert, global verlinkt, technische Dienste berücksichtigt | Rechtliche und vertrauensbezogene Risiken | | Barrierefreiheit | Scanner plus Tastatur-, Fokus-, Struktur- und Zoomtest | Ausschluss von Nutzern, Korrekturkosten und mögliche Rechtsrisiken | | Favicon | Browser-Tab, mobile Darstellung und passende Reduktion | Der Auftritt wirkt sichtbar unfertig | | Structured Data | Reale Entitäten vollständig, valide und widerspruchsfrei modelliert | Suchmaschinen und KI erhalten unklare oder falsche Signale | | PageSpeed Mobile | Mindestens 90, Ziel 94-95+, Ursachen und Core Web Vitals geprüft | Langsame Nutzung und kein Spielraum für spätere Inhalte | | PageSpeed Desktop | Eigener Lauf, Ressourcen, Layout Shifts und Skripte kontrolliert | Probleme werden vom schnellen Entwicklungsrechner verdeckt | | Yoast | Indexierung, Canonical, Templates, Title und Description | Ganze Inhaltstypen werden falsch indexiert | | Seobility | Technik, Struktur und Inhalt gecrawlt; Auffälligkeiten bewertet | Serienfehler und vergessene Seiten bleiben unentdeckt | | Formulare und E-Mails | Validierung, Zustellung, Reply-To, Bestätigung und Mobile | Anfragen verschwinden trotz grüner Erfolgsmeldung | | Redirect Map | Alte URLs gesammelt und jeweils einem sinnvollen Ziel zugeordnet | 404-Fehler, Rankingverluste und frustrierte Bestandsnutzer | | WordPress und Plugins | Kontrolliert aktualisiert, getestet und unnötige Komponenten entfernt | Sicherheitslücken und Konflikte direkt nach dem Launch | | Browser | Chrome, Firefox, Safari und Edge mit kritischen Funktionen | Der Fehler trifft genau die Nutzer außerhalb des Entwicklungsbrowsers | | Login und Benutzer | Pfad, 2FA, Passwörter, Rechte und Testkonten | Unnötige Angriffsfläche und zu breite Zugriffsrechte | | Screenshots alt | Wichtige Seiten und Funktionen vor der Umschaltung dokumentiert | Vorher-nachher-Fragen lassen sich nicht mehr beantworten | | Übersetzungen | Jede Sprache sichtbar, funktional und in den SEO-Feldern geprüft | Sprachmix, kaputte Umbrüche und unvollständige Nutzerwege | | ­ in Überschriften | Lange deutsche Wörter mit sinnvollen Trennstellen versehen | Irgendein Smartphone findet garantiert den peinlichen Umbruch | ## Was Qualität von technischem Pfusch unterscheidet Technischer Pfusch ist selten spektakulär. Meistens ist er ein Hero, das auf dem iPad den Kopf abschneidet. Eine Anfrage, die nie zugestellt wurde. Ein H1, das wegen eines langen Wortes aus dem Bildschirm läuft. Jeder einzelne Fehler lässt sich kleinreden – zusammen entscheiden sie, ob ein Besucher der Website vertraut. Qualität heißt für mich nicht Fehlerfreiheit für alle Ewigkeit. Qualität heißt: bekannte Risiken systematisch prüfen, Entscheidungen dokumentieren und mit einem Stand live gehen, den man guten Gewissens vertreten kann. Man kann diese Arbeit selbst erledigen – genau deshalb steht die Liste hier vollständig. Man braucht Geduld, echte Geräte und die Bereitschaft, eine vermeintlich fertige Seite noch einmal kritisch anzusehen. Wer das lieber abgibt, kann eine [professionelle Website entwickeln lassen](https://4eck-media.de/kompetenzen/ui-ux-design-webentwicklung/) oder uns über die [Kontaktseite von 4eck Media](https://4eck-media.de/kontakt/) für eine technische Prüfung ansprechen. Und wenn die Website dann online ist? Dann beginnt die zweite Hälfte der Arbeit: Indexierung freigeben, Security Header, Backups mit Restore-Test, Tracking und Consent, Redirects unter echten Bedingungen. All das steht im zweiten Teil: der [Launch-Checkliste für die Zeit nach dem Go-live](https://4eck-media.de/blog/website-launch-checkliste-nach-go-live/). ## Häufige Fragen zur Website-Checkliste vor dem Go-live Was muss man vor dem Go-live einer Website prüfen? Mindestens die Darstellung auf Desktop, Notebook, Tablet und Mobile, die wichtigsten Browser, Formulare und E-Mail-Zustellung, PageSpeed, Barrierefreiheit, SEO-Grundlagen, Structured Data, rechtliche Seiten, Plugins, Weiterleitungen und – bei mehrsprachigen Websites – jede Sprachversion. Projektspezifische Funktionen kommen zusätzlich dazu. Wie lange dauert ein professioneller Website-Check vor dem Launch? Das hängt von Umfang und Funktionen ab. Eine kleine Website kann in einigen Stunden geprüft werden; ein Shop, Portal oder mehrsprachiger Relaunch benötigt deutlich länger. Allein ein schwieriges Full-Width-Hero kann durch Zuschnitt, responsive Varianten und Gerätetests etwa eine halbe Stunde zusätzliche Arbeit verursachen. Reicht es, die Website in Chrome zu testen? Nein. Chrome, Firefox, Safari und Edge unterscheiden sich weiterhin bei Rendering, Formularen und einzelnen CSS- oder JavaScript-Funktionen. Kritische Komponenten müssen in den vereinbarten Zielbrowsern ausgeführt werden. Safari sollte auf einem echten Apple-Gerät geprüft werden. Welcher PageSpeed-Wert ist vor dem Go-live gut? Unser Mindestwert ist 90, unser Ziel liegt bei 94 bis 95 oder höher. Der zusätzliche Abstand schafft Reserve, wenn später größere Bilder, Videos oder Marketing-Skripte hinzukommen. Entscheidend sind neben dem Score die Ursachen und die Core Web Vitals LCP, INP und CLS. Ist Barrierefreiheit ein direkter Google-Rankingfaktor? Google bezeichnet Accessibility nicht pauschal als einen einzelnen direkten Rankingfaktor. Core Web Vitals werden jedoch in den Ranking-Systemen verwendet, und viele Eigenschaften einer zugänglichen Website – mobile Nutzbarkeit, klare Struktur, Semantik und verständliche Inhalte – verbessern zugleich Nutzbarkeit und technische Verarbeitbarkeit. Warum ist Structured Data vor dem Launch so wichtig? Structured Data beschreibt Unternehmen, Personen, Leistungen, Artikel und ihre Beziehungen maschinenlesbar. Das reduziert Mehrdeutigkeit für Suchmaschinen und KI-Systeme. Markup garantiert kein Ranking, sollte aber vollständig, korrekt, valide und mit den sichtbaren Angaben der Website konsistent sein. Was ist bei einer Website Relaunch Checkliste zusätzlich zu beachten? Bei einem Relaunch kommen insbesondere der Export alter URLs, eine Redirect Map, der Abgleich von Analytics und Search Console, Screenshots der alten Website sowie die Prüfung von Canonical, Sitemap, Indexierung und bestehenden Rankings hinzu. Die visuelle und funktionale Before-Live-Prüfung bleibt trotzdem vollständig bestehen.