Website-Launch-Checkliste: 52 Punkte – 2026

Serdar D
Serdar D

Eine Website zu launchen ist vergleichbar mit der Eröffnung eines Geschäfts in einer belebten Einkaufsstraße. Wenn die Regale halb leer sind und das Kartenterminal nicht funktioniert, werden die ersten Besucher das Geschäft verlassen und wahrscheinlich nie wiederkommen. Im digitalen Raum passiert genau das Gleiche. Ein fehlendes SSL-Zertifikat, ein kaputter Navigationslink oder eine vergessene robots.txt-Datei können wochenlange Entwicklungsarbeit in Sekunden zunichtemachen. Genau deshalb ist es ein Risiko, den „Veröffentlichen“-Button ohne eine gründliche Website-Launch-Checkliste zu drücken, das sich die meisten Unternehmen nicht leisten können. Im Laufe der Jahre haben wir bei Dutzenden von Webprojekten für Unternehmen im DACH-Raum die häufigsten Fehler, die regelmäßig übersehenen Details und die „das hätten wir wirklich vorher bemerken müssen“-Momente in ein einziges Referenzdokument zusammengefasst. Zweiundfünfzig Punkte. Acht Kategorien. Jeder einzelne stammt aus realen Launches, realen Fehlschlägen und realen Korrekturen.

Sie müssen diese Liste nicht von oben bis unten in einem Zug durchlesen. Springen Sie zu der Kategorie, die zu Ihrem aktuellen Projektstand passt, und haken Sie die Punkte ab, sobald Sie sie erledigt haben. Ein Hinweis allerdings: Öffnen Sie diese Checkliste mindestens 48 Stunden vor dem geplanten Launch. Die Dinge, die bei Last-Minute-Reviews durchrutschen, sind immer diejenigen, die am meisten zählen.

Technische Infrastruktur (Punkte 1-8)

Hier wird das Fundament Ihrer Website gebaut. Hosting-Wahl, Domain-Konfiguration, Servereinstellungen. Das sind die unsichtbaren Entscheidungen, die alles über die Zukunft Ihrer Website bestimmen. Ob eine Seite schnell oder langsam wird, stabil oder absturzanfällig, skalierbar oder eingeschränkt, all das wird auf dieser Ebene entschieden.

1. Ist der Hosting-Plan bestätigt und der Serverstandort korrekt?

Wenn Ihre Zielgruppe in Deutschland, Österreich oder der Schweiz sitzt, sollte Ihr Server in Frankfurt, München oder zumindest in Westeuropa stehen. Einen Server auf einem anderen Kontinent zu wählen und davon auszugehen „wir nutzen einfach ein CDN“ ist eine häufige Falle. Ein CDN beschleunigt statische Dateien, aber Datenbankabfragen wandern trotzdem zurück zum Ursprungsserver. Starten Sie mit Shared Hosting, nutzen Sie einen VPS (Virtual Private Server) oder entscheiden Sie sich für Managed WordPress Hosting? Lassen Sie Ihre erwarteten Besucherzahlen diese Entscheidung leiten. Einen E-Commerce-Shop mit 50.000 monatlichen Besuchern auf Shared Hosting zu betreiben, ist wie einen Supermarkt mit einer einzigen Kasse zu eröffnen.

2. Sind Domain-Weiterleitungen und DNS-Einträge konfiguriert?

Wählen Sie eine kanonische Version Ihrer Domain, entweder www oder ohne www, und richten Sie eine 301-Weiterleitung von der anderen ein. DNS-Propagierung kann 24 bis 48 Stunden dauern, also lassen Sie das nicht bis zum Launch-Tag. Prüfen Sie Ihre MX-Einträge (für E-Mail), CNAME-Einträge und A-Einträge. Wenn Sie mit einer bestehenden Domain arbeiten, testen Sie jede aktuelle Weiterleitung einzeln, um sicherzustellen, dass nichts kaputt gegangen ist. Ein einziger falsch konfigurierter DNS-Eintrag kann Ihre E-Mail lahmlegen, und Sie bemerken es möglicherweise erst, wenn ein Kunde Ihnen mitteilt, dass seine Nachrichten zurückkommen.

3. Ist das SSL-Zertifikat aktiv und korrekt konfiguriert?

Im Jahr 2026 ist ein Launch ohne SSL praktisch unmöglich. Browser kennzeichnen unverschlüsselte Seiten mit einer „Nicht sicher“-Warnung, die Besucher sofort abschreckt. Aber nur ein Zertifikat zu installieren reicht nicht. Prüfen Sie auf Mixed-Content-Probleme, bei denen eine Seite über HTTPS geladen wird, aber ein einzelnes Bild oder Skript über HTTP einbindet. Diese eine HTTP-Ressource zerstört das Schloss-Symbol in der Browserleiste. Wählen Sie den richtigen Zertifikatstyp für Ihr Projekt: DV (Domain Validation) funktioniert gut für eine Standard-Unternehmenswebsite, während ein EV (Extended Validation)-Zertifikat eine zusätzliche Vertrauensebene für E-Commerce-Shops bietet, die Kartenzahlungen in EUR verarbeiten.

4. Sind Staging- und Produktionsumgebung getrennt?

Eine Live-Website zu bearbeiten ist das digitale Äquivalent dazu, ein Haus neu zu verkabeln, während Menschen darin wohnen. Eine Staging-Umgebung ermöglicht es Ihnen, Änderungen zu testen, bevor Sie sie in die Produktion übertragen. Wenn Ihr Hosting-Panel eine Ein-Klick-Staging-Funktion bietet, nutzen Sie sie. Falls nicht, richten Sie zumindest eine lokale Entwicklungsumgebung mit einem Tool wie LocalWP oder DDEV ein. Die wenigen Minuten, die das Erstellen einer Staging-Seite dauert, sparen Stunden panischen Debuggings, wenn etwas auf der Live-Seite um 2 Uhr morgens kaputtgeht.

5. Läuft Ihre serverseitige Sprache in einer aktuellen Version?

Wenn Sie WordPress nutzen, benötigen Sie PHP 8.2 oder höher. Ältere PHP-Versionen schaffen Sicherheitslücken und bremsen die Performance. Ein Upgrade von PHP 7.4 auf 8.2 allein kann die Seitenladezeiten um 15 bis 20 Prozent verkürzen. Prüfen Sie vor dem Upgrade die Plugin-Kompatibilität. Einige ältere Plugins kollidieren mit neueren PHP-Versionen und werfen fatale Fehler, die die gesamte Seite lahmlegen. Dasselbe Prinzip gilt für Node.js, Python oder welchen Stack auch immer Ihre Seite nutzt: veraltete Laufzeitumgebungen sind sowohl langsamer als auch weniger sicher.

6. Wurde die Datenbank optimiert?

Während der Entwicklung sammeln Datenbanken Datenmüll an: unnötige Post-Revisionen, Spam-Kommentare, abgelaufene Transient-Daten, verwaiste Metadaten. All das bläht die Datenbank auf und verlangsamt Abfragen. Räumen Sie vor dem Go-Live auf. In WordPress erledigen Tools wie WP-Optimize das mit wenigen Klicks. Achten Sie besonders auf die wp_options-Tabelle. Wenn sie mit automatisch geladenen Einträgen von deaktivierten Plugins belastet ist, wird Ihre Seitenladezeit spürbar leiden. Eine gesunde wp_options-Tabelle sollte in den meisten Fällen weniger als 500 automatisch geladene Zeilen haben.

7. Sind Cron-Jobs und geplante Aufgaben konfiguriert?

Muss Ihre Seite Aufgaben automatisch ausführen? Backups, Transaktions-E-Mails, Bestandsaktualisierungen, Cache-Bereinigung. All das basiert auf geplanten Jobs. WordPress hat sein eigenes wp-cron-System, aber es feuert nur, wenn jemand die Seite besucht, was es für zeitkritische Aufgaben unzuverlässig macht. Richten Sie stattdessen einen echten serverseitigen Cron-Job ein. Bei den meisten Hosting-Panels dauert das weniger als fünf Minuten.

8. Sind Fehlerseiten und Server-Antwortcodes korrekt?

Wenn jemand eine Seite besucht, die nicht existiert, gibt der Server dann einen 404-Statuscode zurück, oder liefert er die Seite mit einem 200er? Ein Soft-404, bei dem der Server „alles in Ordnung“ sagt, während er eine „Seite nicht gefunden“-Nachricht anzeigt, verwirrt Suchmaschinen und verschwendet Ihr Crawl-Budget. Prüfen Sie ebenfalls, dass 301- und 302-Weiterleitungen sich wie beabsichtigt verhalten. Nutzen Sie ein Tool wie Screaming Frog, um die Seite zu crawlen und unerwartete Antwortcodes vor dem Launch zu erkennen.

Website-Launch-Checkliste mit 52 Punkten in acht Kategorien

Design und Nutzererfahrung (Punkte 9-17)

Sobald das technische Fundament solide steht, verlagert sich der Fokus auf die Ebene, die Besucher tatsächlich sehen und nutzen. Design ist nicht nur eine Frage des Aussehens. Es geht um Benutzerfreundlichkeit. Wenn ein Besucher nicht innerhalb von drei Sekunden findet, was er sucht, hat das Design versagt, egal wie elegant die Farbpalette aussieht.

9. Wurde die mobile Responsivität auf jeder Seite getestet?

Im DACH-Raum kommen etwa 60 Prozent des Web-Traffics von Mobilgeräten. Mobile Kompatibilität ist keine Option, sie ist die Grundlinie. Nur die Startseite zu testen reicht nicht. Prüfen Sie Unterseiten, Blogbeiträge, Formularseiten, die 404-Seite, die Datenschutzerklärung, alles. Chrome DevTools Geräteemulation ist ein guter Anfang, aber testen Sie immer auch auf einem echten Telefon. Der Emulator bildet keine Touch-Interaktionen, Scroll-Dynamik oder die Art und Weise nach, wie Safari auf iOS fixierte Elemente anders behandelt als Chrome auf Android.

10. Ist das Navigationsmenü klar und funktional?

Funktioniert jeder Link im Hauptmenü? Öffnen sich Dropdown-Menüs auf Mobilgeräten korrekt, ohne Inhalte zu überlagern? Halten Sie die oberste Menüebene auf sieben Einträge oder weniger. Ein Besucher sollte von überall auf der Seite in maximal zwei Klicks die Startseite oder jede wichtige Unterseite erreichen können. Testen Sie das Hamburger-Menü auf Mobilgeräten gründlich. Es ist eine der häufigsten Quellen für Benutzerfreundlichkeitsbeschwerden, oft weil der Schließen-Button zu nah an anderen tippbaren Elementen liegt.

11. Funktionieren Formulare und validieren sie Eingaben korrekt?

Kontaktformulare, Registrierungsformulare, Newsletter-Anmeldungen, Angebotsanfragen. Testen Sie alle mit echten Daten. Kommt die E-Mail tatsächlich an? Sind Fehlermeldungen klar und spezifisch, oder sagen sie nur „ungültige Eingabe“, ohne zu erklären, was falsch gelaufen ist? Was sieht der Benutzer nach einer erfolgreichen Übermittlung: eine Dankesseite, eine Bestätigungsnachricht, gar nichts? Diese Details scheinen nebensächlich, aber sie beeinflussen direkt Ihre Conversion Rate. Ein Formular, das funktioniert, sich aber kaputt anfühlt, wird Sie Leads kosten.

12. Wurde die 404-Seite angepasst?

Die Standard-404-Seite ist der schnellste Weg, einen Besucher zu verlieren. Eine individuelle 404-Seite sollte Links zur Startseite und zu Ihren beliebtesten Seiten, ein Suchfeld und eine freundliche Nachricht enthalten, die den Fehler anerkennt, ohne herablassend zu sein. Gute 404-Seiten bieten dem Benutzer auch eine Möglichkeit, den defekten Link zu melden. Die Kosten für die Gestaltung einer ordentlichen 404-Seite liegen praktisch bei null. Die Kosten für den Verlust jedes Besuchers, der auf einen toten Link trifft, sind erheblich höher.

13. Wurden Typografie und Schriftart-Laden optimiert?

Wenn Sie Google Fonts verwenden, laden Sie nur die Schriftstärken, die Sie tatsächlich benötigen. Regelmäßig sehen wir Seiten, die Roboto in Light, Regular, Medium, Bold und Black laden, während das Design nur Regular und Bold verwendet. Jede zusätzliche Schriftdatei verlängert die Seitenladezeit. Fügen Sie die font-display: swap-Deklaration hinzu, um FOIT (Flash of Invisible Text) zu verhindern, das Problem, bei dem Text unsichtbar bleibt, bis die benutzerdefinierte Schrift fertig geladen ist.

14. Haben Bilder korrekten Alt-Text und passende Abmessungen?

Jedes Bild sollte ein aussagekräftiges alt-Attribut haben. „IMG_2847.jpg“ oder „bild1“ sind sowohl für die Barrierefreiheit als auch für SEO verschenkt. Bildabmessungen zählen ebenfalls: Ein 4000×3000 Pixel großes Foto direkt von der Kamera hochzuladen, wird Ihre Seitengeschwindigkeit zerstören. Ändern Sie die Bildgröße auf die Anzeigemaße, komprimieren Sie sie und liefern Sie sie im WebP-Format aus.

15. Sind CTA-Buttons prominent und tippbar?

Was ist der Zweck Ihrer Seite? Welche Aktion sollen Besucher ausführen? Die Antwort sollte sich in Ihren Call-to-Action-Buttons widerspiegeln. Buttons sollten sich durch Farb- und Größenkontrast vom Rest der Seite abheben. Auf Mobilgeräten halten Sie ein Mindest-Tippziel von 44×44 Pixeln ein, das ist Apples Richtlinie und Googles Empfehlung. Ersetzen Sie generische Bezeichnungen wie „Mehr erfahren“ durch spezifische Handlungsphrasen, die dem Besucher genau sagen, was passiert, wenn er klickt.

16. Wurden Barrierefreiheitsstandards eingehalten?

WCAG (Web Content Accessibility Guidelines) 2.2 Level AA sollte Ihr Mindestziel sein. Ist das Farbkontrastverhältnis ausreichend? Kann ein Benutzer die gesamte Seite nur mit der Tastatur navigieren? Interpretiert ein Screenreader die Seitenstruktur korrekt? In Deutschland stellt das Barrierefreiheitsstärkungsgesetz (BFSG) Anforderungen an die digitale Barrierefreiheit, die ab Juni 2025 für viele Unternehmen verpflichtend sind. In Österreich und der Schweiz gelten vergleichbare Regelungen. Barrierefreie Seiten schneiden auch in Suchrankings besser ab, weil Suchmaschinenoptimierung und Barrierefreiheit viele der gleichen Prinzipien teilen.

17. Sind Favicon und Browser-Tab-Details konfiguriert?

Kleines Detail, großer Eindruck. Eine Seite ohne Favicon zeigt das generische leere Seitensymbol im Browser-Tab. Das signalisiert „unfertig“ für jeden, der es bemerkt, und mehr Menschen bemerken es, als Sie vielleicht denken. Erstellen Sie ein 32×32 Pixel Favicon zusammen mit einem Apple Touch Icon (180×180) und einer manifest.json-Datei für Android. Wenn jemand zwanzig Tabs offen hat, ist Ihr Favicon der Weg, wie er Ihre Seite findet.

Ihre Website mit einem Team launchen, das jeden Punkt kennt

Mit einem Team zusammenzuarbeiten, das alle 52 Punkte dieser Liste kennt und anwendet, eliminiert Überraschungen nach dem Launch und schützt Ihre Investition.

Kontaktieren Sie uns →

Inhalte (Punkte 18-25)

Inhalte sind das Herzstück jeder Website. Die technische Infrastruktur kann kugelsicher sein und das Design umwerfend aussehen, aber am Ende des Tages liest ein Besucher Text, schaut sich Bilder an und sieht Videos. Wenn die Inhalte unvollständig, veraltet oder voller Fehler sind, fühlt sich die Seite halbfertig an, egal wie gut alles andere funktioniert.

18. Sind alle Seitentexte finalisiert?

„Lorem ipsum“ oder „Text kommt hier hin“-Platzhalter sollten niemals auf einer Live-Seite erscheinen. Das klingt offensichtlich, aber unter Zeitdruck passiert es weit häufiger, als jemand zugeben möchte. Öffnen Sie jede einzelne Seite, lesen Sie jeden Absatz, und vergessen Sie nicht das Kleingedruckte im Footer. Prüfen Sie das Copyright-Jahr. Prüfen Sie den Firmennamen. Prüfen Sie, dass die Telefonnummer im Header mit der auf der Kontaktseite übereinstimmt.

19. Wurden Rechtschreib- und Grammatikfehler korrigiert?

Rechtschreibfehler auf einer professionellen Website untergraben sofort die Glaubwürdigkeit. Tools wie LanguageTool, der Duden-Mentor oder die eingebaute Rechtschreibprüfung in Google Docs fangen die offensichtlichen Fehler ab, aber kein automatisches Tool ersetzt ein zweites Paar menschlicher Augen. Lassen Sie jemand anderen als den ursprünglichen Autor alle Texte Korrektur lesen.

20. Sind die rechtlichen Seiten bereit?

Datenschutzerklärung, Cookie-Richtlinie, Impressum, AGB. Im DACH-Raum verlangt die DSGVO eine Datenschutzerklärung, die erklärt, wie Sie personenbezogene Daten erheben, speichern und verwenden. In Deutschland ist zudem ein Impressum nach Telemediengesetz (TMG) und Digitale-Dienste-Gesetz verpflichtend. E-Commerce-Seiten benötigen zusätzlich Widerrufsbelehrung, Versandinformationen und Allgemeine Geschäftsbedingungen. Lassen Sie diese Seiten von einem Rechtsanwalt prüfen. Vorlagen aus dem Internet decken selten die Besonderheiten Ihres Unternehmens ab. Rechnen Sie mit 300 bis 800 Euro für eine professionelle rechtliche Prüfung. Das ist ein Bruchteil dessen, was ein DSGVO-Bußgeld kosten würde.

21. Funktioniert das Cookie-Consent-Banner korrekt?

Die DSGVO und die ePrivacy-Richtlinie verlangen eine klare Cookie-Einwilligung. Das Banner darf nicht nur einen „Alle akzeptieren“-Button haben; es muss eine echte Möglichkeit bieten, abzulehnen oder Präferenzen zu verwalten. Google Analytics darf nicht feuern, bevor die Einwilligung erteilt wurde. Wenn Sie Google Consent Mode v2 implementiert haben, testen Sie, dass es die korrekten Einwilligungssignale sendet. Nutzen Sie ein Tool wie CookieYes, Cookiebot oder Borlabs Cookie, um die Compliance zu managen. Prüfen Sie, dass das Banner für Erstbesucher erscheint, die Auswahl wiederkehrender Besucher speichert und keine kritischen Seiteninhalte auf Mobilbildschirmen blockiert.

22. Sind Kontaktdaten korrekt und aktuell?

Telefonnummer, E-Mail-Adresse, Postadresse, Social-Media-Links. Wenn irgendetwas davon falsch oder veraltet ist, sinkt das Vertrauen der Besucher sofort. Löst ein Klick auf die Telefonnummer auf dem Handy einen Anruf aus? Öffnet der E-Mail-Link den Mail-Client des Benutzers? Zeigt die eingebettete Karte den korrekten Standort? Für Unternehmen mit einem Google-Unternehmensprofil muss die Adresse auf Ihrer Website mit der im Profil übereinstimmen. Inkonsistenzen zwischen Ihrer Seite und Verzeichniseinträgen verwirren Suchmaschinen und können Ihre lokalen SEO-Rankings beschädigen.

23. Laden alle Bilder und Mediendateien korrekt?

Werden Bilder auf jeder Seite korrekt angezeigt? Gibt es defekte Bildlinks? Spielen eingebettete Videos ab? Laufen Bilder auf Mobilgeräten über den Bildschirm hinaus? Testen Sie über verschiedene Geräte- und Browser-Kombinationen hinweg. Achten Sie besonders auf Bilder in Blogbeiträgen und Produktseiten, wo Content-Redakteure oft Bilder hochladen, ohne die Abmessungen zu prüfen.

24. Wurden Urheberrecht und Lizenzanforderungen überprüft?

Hat jedes Bild, jede Schrift und jede Softwarekomponente auf der Seite eine gültige Lizenz? Bestätigen Sie, dass Stockfotos Lizenzen für die kommerzielle Nutzung haben. Google Fonts sind kostenlos und quelloffen, aber Premium-Schriften erfordern gekaufte Lizenzen. Icon-Bibliotheken wie Font Awesome haben kostenlose Stufen, aber einige Icons sind hinter kostenpflichtigen Plänen. Urheberrechtsverletzungsansprüche nehmen in Europa zu. Eine Schriftlizenz, die 50 Euro kostet, ist deutlich günstiger als ein Abmahnschreiben über 5.000 Euro von einer Lizenzverwertungsgesellschaft.

25. Ist der Blog- oder Nachrichtenbereich eingerichtet?

Wenn Content Marketing Teil Ihrer Strategie ist, muss die Blog-Infrastruktur vor dem Launch bereit sein. Kategoriestruktur, Tag-System, Autorenprofile, verwandte Beiträge, Social-Sharing-Buttons. Veröffentlichen Sie mindestens drei bis fünf Blogbeiträge vor dem Go-Live. Ein leerer Blog sieht aus wie ein verlassenes Schaufenster. Diese ersten Beiträge geben Suchmaschinen auch etwas zum Indexieren vom ersten Tag an und liefern Inhalte für Ihre Launch-Ankündigung in den sozialen Medien.

SEO (Punkte 26-34)

Ist Ihre Seite bereit für Suchmaschinen? SEO-Probleme nach dem Launch zu beheben ist, als würde man ein Haus bauen und dann versuchen, das Fundament darunter zu gießen. Beheben Sie so viel wie möglich, bevor die Seite live geht, denn der erste Eindruck, den Ihre Seite bei Googles Crawlern hinterlässt, bestimmt das Indexierungsverhalten für Monate.

26. Hat jede Seite einen einzigartigen Title-Tag und eine Meta-Beschreibung?

Title-Tags sollten 50 bis 60 Zeichen lang sein. Meta-Beschreibungen sollten zwischen 120 und 155 Zeichen liegen. Beide müssen für jede Seite einzigartig sein. Platzieren Sie Ihr primäres Keyword nahe am Anfang des Titels. Die Meta-Beschreibung ist kein direkter Ranking-Faktor, aber sie beeinflusst direkt die Klickrate in den Suchergebnissen. Schreiben Sie sie wie Anzeigentext: spezifisch, nutzenorientiert und ehrlich darüber, was die Seite enthält.

27. Ist die URL-Struktur sauber und aussagekräftig?

URLs sollten kurz, beschreibend und menschenlesbar sein. „ihrefirma.de/leistungen/webdesign/“ ist eine gute URL. „ihrefirma.de/?p=1247“ ist eine schlechte. In WordPress stellen Sie die Permalink-Struktur auf „Beitragsname“. Vermeiden Sie unnötige Ordnertiefe; halten Sie URLs auf drei oder vier Segmente maximal.

28. Wurde eine XML-Sitemap erstellt und an Google übermittelt?

Eine XML-Sitemap teilt Suchmaschinen mit, welche Seiten auf Ihrer Website existieren und wie sie strukturiert sind. Plugins wie Yoast SEO und Rank Math generieren diese automatisch, aber prüfen Sie vor dem Launch, dass die Sitemap die korrekten Seiten auflistet. Entwurfsseiten, Archivseiten und dünn besiedelte Inhaltsseiten sollten ausgeschlossen werden. Übermitteln Sie die Sitemap an die Google Search Console und die Bing Webmaster Tools.

29. Ist die robots.txt-Datei korrekt konfiguriert?

Dies ist einer der am häufigsten übersehenen Punkte beim Übergang von der Entwicklung zur Produktion. Während der Entwicklung ist es üblich, „Disallow: /“ zur robots.txt hinzuzufügen, um Suchmaschinen am Indexieren einer unfertigen Seite zu hindern. Wenn Sie vergessen, diese Zeile vor dem Launch zu entfernen, wird Google Ihre Seite nicht indexieren und Sie erscheinen in keinen Suchergebnissen. Das ist kein hypothetisches Szenario. Wir haben persönlich erlebt, wie ein E-Commerce-Shop drei Wochen lang aus Google verschwand, weil niemand die robots.txt vor dem Go-Live geprüft hat. Eine Textzeile, drei Wochen entgangener Umsatz.

30. Sind Canonical-Tags korrekt platziert?

Derselbe Inhalt kann manchmal über mehrere URLs erreichbar sein. URL-Parameter, Filter, Sortieroptionen und Paginierung können alle Dutzende doppelter Seiten erzeugen. Ein Canonical-Tag teilt Suchmaschinen mit: „Die definitive Version dieser Seite lebt unter dieser URL.“ Jede Seite sollte ein selbstreferenzierendes Canonical-Tag haben, oder eines, das auf die bevorzugte Version verweist.

31. Wird die Überschriftenhierarchie korrekt verwendet?

Jede Seite sollte eine H1 haben, gefolgt von H2s und H3s in einer logischen Reihenfolge. Von H1 direkt zu H4 zu springen bricht die Hierarchie und verwirrt sowohl Screenreader als auch Suchmaschinen-Crawler. Ein häufiger Fehler ist, das Website-Logo in einen H1-Tag auf jeder Seite zu packen. Jede Seite, einschließlich der Startseite, braucht ihre eigene einzigartige H1, die klar den Inhalt der Seite beschreibt.

32. Wurde Schema-Markup (strukturierte Daten) hinzugefügt?

Organization, LocalBusiness, BreadcrumbList, FAQPage und Product gehören zu den nützlichsten Schema-Markup-Typen. Strukturierte Daten helfen Ihren Seiten, als Rich Snippets in Suchergebnissen zu erscheinen, was Sichtbarkeit und Klickraten erhöht. Nutzen Sie Googles Rich Results Test, um zu überprüfen, dass Ihr Schema gültig ist. Fehlerhaftes Schema kann schlimmer sein als gar kein Schema, weil Google es als Spam-Signal interpretieren kann.

33. Wurde die interne Verlinkungsstruktur aufgebaut?

Seiten sollten sich auf sinnvolle Weise gegenseitig verlinken. Verwaiste Seiten, also Seiten, die keine internen Links von irgendwo auf der Website erhalten, werden von Suchmaschinen tendenziell als unwichtig behandelt. Stellen Sie sicher, dass Ihre wichtigsten Seiten über das Hauptmenü, den Footer oder die Seitenleiste erreichbar sind. Erstellen Sie natürliche Querverweise zwischen Blogbeiträgen und Serviceseiten. Interne Links leiten sowohl Benutzer als auch Crawler durch Ihre Website und verteilen Linkwert über Ihre Seiten.

34. Wurden Open Graph und Twitter Card Meta-Tags hinzugefügt?

Diese Tags steuern, wie Ihre Seiten aussehen, wenn jemand sie in sozialen Medien teilt. Wenn og:title, og:description und og:image nicht definiert sind, wird die Plattform herausziehen, was sie finden kann, und das Ergebnis sieht normalerweise kaputt oder unattraktiv aus. Bildabmessungen sollten 1200×630 Pixel für Facebook und LinkedIn und 1200×600 für X (vormals Twitter) betragen.

Eine SEO-optimierte Website aufbauen

Technisches SEO, Seitengeschwindigkeit und Nutzererfahrung müssen vom ersten Tag an zusammenarbeiten. Sprechen Sie mit unserem Team über Ihr Webentwicklungsprojekt.

Kontaktieren Sie uns →

Sicherheit (Punkte 35-40)

Eine Website zu hacken ist einfacher, als die meisten Seitenbetreiber annehmen. WordPress-Seiten gehören zu den weltweit am häufigsten angegriffenen Plattformen, weil ihre Popularität sie zu einem hochrentablen Ziel für automatisierte Angriffe macht. Sicherheitsinvestitionen müssen vor einem Vorfall getätigt werden, nicht danach.

35. Ist ein automatisiertes Backup-System vorhanden?

Automatische Backups sind nicht verhandelbar. Tägliche Datenbank-Backups und wöchentliche Vollsicherungen sollten der Mindeststandard sein. Backups dürfen nicht nur auf demselben Server wie die Seite gespeichert werden. Senden Sie Kopien an einen externen Speicherdienst wie Amazon S3, Google Cloud Storage oder einen dedizierten Cloud-Ordner. Führen Sie mindestens einmal vor dem Launch einen Wiederherstellungstest durch. Rechnen Sie mit etwa 5 bis 20 Euro pro Monat für zuverlässigen Backup-Speicher. Das ist eine der günstigsten Versicherungen, die Sie jemals abschließen werden.

36. Ist ein Sicherheits-Plugin oder eine WAF (Web Application Firewall) aktiv?

Für WordPress bieten Tools wie Wordfence, Sucuri oder Solid Security Schutz gegen Brute-Force-Angriffe, SQL-Injection und XSS (Cross-Site Scripting). Eine CDN- und Sicherheitsschicht wie Cloudflare fügt DDoS-Schutz (Distributed Denial of Service) als erste Verteidigungslinie hinzu. Konfigurieren Sie die Firewall-Regeln vor dem Launch, nicht nach dem ersten Angriff.

37. Wurde der Standard-Admin-Benutzername geändert?

Seiten, die „admin“ als Benutzernamen verwenden, sind die einfachsten Ziele für Brute-Force-Angriffe, weil der Angreifer bereits die Hälfte der Anmeldedaten kennt. Ändern Sie den Benutzernamen auf etwas Einzigartiges. Passwörter sollten mindestens 16 Zeichen lang sein und eine Mischung aus Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen enthalten. Zwei-Faktor-Authentifizierung (2FA) sollte für alle Admin-Konten verpflichtend sein.

38. Sind WordPress-Core, Plugins und Themes auf dem neuesten Stand?

Die große Mehrheit der WordPress-Sicherheitslücken stammt von veralteter Software. Aktualisieren Sie WordPress-Core, alle Plugins und das aktive Theme auf ihre neuesten Versionen vor dem Launch. Nicht verwendete Plugins nur zu deaktivieren reicht nicht. Löschen Sie sie vollständig. Ein deaktiviertes Plugin hat seine Dateien immer noch auf dem Server, und Schwachstellen in diesen Dateien können weiterhin ausgenutzt werden.

39. Sind Dateiberechtigungen korrekt gesetzt?

Auf Linux-Servern sollten Dateiberechtigungen auf 644 für Dateien und 755 für Verzeichnisse gesetzt werden. Die wp-config.php-Datei, die Ihre Datenbank-Zugangsdaten enthält, sollte auf 400 oder 440 gesetzt werden. Falsche Dateiberechtigungen sind einer der häufigsten Angriffsvektoren für WordPress-Exploits und einer der am einfachsten zu behebenden.

40. Ist die Login-Seite geschützt?

Die WordPress-Login-URL vom Standard /wp-admin/ auf einen benutzerdefinierten Pfad zu ändern, ist eine einfache, aber wirksame Maßnahme. Fügen Sie Login-Rate-Limiting hinzu, damit nach einer bestimmten Anzahl fehlgeschlagener Versuche die IP-Adresse gesperrt wird. Fügen Sie reCAPTCHA oder eine ähnliche Bot-Schutzschicht zum Login-Formular hinzu. Diese drei Schritte zusammen blockieren etwa 95 Prozent automatisierter Angriffsversuche.

Performance (Punkte 41-45)

Seitengeschwindigkeit ist ein direkter Ranking-Faktor in Googles Algorithmus. Aber das eigentliche Problem sind nicht die Rankings. Eine langsame Seite verliert Besucher, senkt Conversion Rates und verschwendet Werbebudget. Wenn Sie für Google Ads-Traffic bezahlen und diese Klicks auf eine Seite leiten, die fünf Sekunden zum Laden braucht, verbrennen Sie Geld.

41. Liegen die Core Web Vitals-Werte im Zielbereich?

Metrik Was sie misst Gut Verbesserungsbedarf Schlecht
LCP Ladezeit des größten sichtbaren Elements ≤ 2,5s 2,5-4s > 4s
INP Reaktionsfähigkeit bei Nutzerinteraktionen ≤ 200ms 200-500ms > 500ms
CLS Visuelle Stabilität (Layout-Verschiebungen) ≤ 0,1 0,1-0,25 > 0,25

Für LCP (Largest Contentful Paint) ist die Optimierung des Hero-Bildes normalerweise der größte Hebel. Für INP (Interaction to Next Paint) reduzieren Sie schwere JavaScript-Ausführung und verschieben Sie nicht-kritische Skripte. Für CLS (Cumulative Layout Shift) definieren Sie immer width- und height-Attribute bei Bildern und Einbettungen. Eine schnelle Ladegeschwindigkeit ist nicht nur eine technische Errungenschaft. Sie ist ein direktes Signal an Besucher, dass Sie ihre Zeit respektieren.

42. Wurde ein CDN konfiguriert?

Ein CDN verteilt Ihre statischen Dateien (Bilder, CSS, JavaScript) auf Server weltweit und liefert sie vom Standort aus, der jedem Besucher am nächsten liegt. Cloudflares kostenloser Plan allein macht bereits einen spürbaren Unterschied. Für DACH-Zielgruppen hat Cloudflare Points of Presence in Frankfurt, Düsseldorf, Wien und Zürich. Nach dem Einrichten des CDN konfigurieren Sie Caching-Regeln korrekt. Ein falsch konfiguriertes CDN kann die Performance tatsächlich verschlechtern.

43. Sind Browser-Caching-Header gesetzt?

Definieren Sie Cache-Control- und Expires-Header für statische Dateien. Setzen Sie CSS- und JavaScript-Dateien auf ein Jahr Caching und Bilder auf sechs Monate bis ein Jahr. Wenn sich Dateien ändern, nutzen Sie Cache-Busting durch Anhängen einer Versionsnummer an den Dateinamen (z.B. style.v2.css oder style.css?v=2). So laden wiederkehrende Besucher keine Dateien erneut herunter, die sich nicht geändert haben.

44. Wurden CSS- und JavaScript-Dateien minifiziert und zusammengefasst?

Minifizierung entfernt unnötige Leerzeichen, Kommentare und Zeilenumbrüche aus Code-Dateien. Allein dadurch reduzieren sich Dateigrößen typischerweise um 20 bis 30 Prozent. In WordPress erledigen Plugins wie WP Rocket oder Autoptimize das automatisch. Aber Vorsicht: Das Zusammenfassen von JavaScript-Dateien verursacht manchmal Konflikte und bricht Funktionalität. Testen Sie immer jede Seite nach dem Aktivieren von Minifizierung und Zusammenfassung.

45. Wurden nicht genutzte Plugins und Skripte entfernt?

Gibt es Plugins, die während der Entwicklung installiert wurden und es nie in die finale Seite geschafft haben? Jedes aktive Plugin lädt zusätzliche CSS- und JavaScript-Dateien, selbst auf Seiten, wo diese Dateien nicht benötigt werden. Der Unterschied zwischen einer WordPress-Seite mit 30 Plugins und einer mit 12 ist mit bloßem Auge sichtbar. Überprüfen Sie auch Ihren Google Tag Manager Container: Entfernen Sie nicht genutzte Marketing-Pixel, veraltete Analytics-Snippets und Test-Tags, die nie live gehen sollten.

Analytics und Tracking (Punkte 46-49)

Was man nicht misst, kann man nicht steuern. Anstatt Ihre Seite zu launchen und eine Woche später zu fragen „wie viele Leute besuchen uns?“, richten Sie Tracking vom ersten Tag an ein, damit Sie Daten ab dem allerersten Besucher haben.

46. Wurde GA4 (Google Analytics 4) installiert und verifiziert?

GA4 einzurichten bedeutet nicht nur, einen Tracking-Code in den Header zu fügen. Sie müssen Events korrekt konfigurieren. Seitenaufrufe, Formularübermittlungen, Button-Klicks, Scroll-Tiefe, Dateidownloads – verifizieren Sie, dass jedes Event wie erwartet feuert. Nutzen Sie GA4s DebugView zum Echtzeittesten. Aktivieren Sie Enhanced Measurement, aber verstehen Sie, welche Events es automatisch erfasst, damit Sie keine Duplikate erstellen.

47. Ist Google Tag Manager korrekt konfiguriert?

Google Tag Manager (GTM) ermöglicht es Ihnen, alle Tracking-Codes von einem einzigen Dashboard aus zu verwalten. GA4, Google Ads-Conversion-Tags, Meta Pixel, LinkedIn Insight Tag und alle anderen Marketing-Skripte sollten über GTM bereitgestellt werden, anstatt sie direkt in den Seitencode einzubetten. Nutzen Sie den GTM-Vorschaumodus, um zu bestätigen, dass jeder Tag beim korrekten Trigger feuert.

48. Wurde die Seite zur Google Search Console hinzugefügt?

Die Search Console ist ein kostenloses Tool, das zeigt, wie Google Ihre Seite sieht. Verifizieren Sie Ihre Domain mittels DNS- oder HTML-Dateiverifizierung. Übermitteln Sie Ihre Sitemap. Überwachen Sie den Indexabdeckungsbericht ab der ersten Woche. Richten Sie E-Mail-Benachrichtigungen ein, damit Sie sofort informiert werden, wenn Google einen Anstieg von Crawl-Fehlern oder einen Rückgang indexierter Seiten erkennt.

49. Funktionieren Werbepixel und Conversion-Codes?

Wenn Sie planen, auf Google Ads, Meta (Facebook/Instagram), LinkedIn oder einer anderen Plattform zu werben, installieren Sie Conversion Tracking vor dem Launch. Nutzen Sie Browser-Erweiterungen wie Meta Pixel Helper und Google Tag Assistant, um zu überprüfen, dass Pixel korrekt feuern. Führen Sie Testkonversionen durch und bestätigen Sie, dass die Daten im Dashboard jeder Werbeplattform erscheinen.

Abschlussprüfungen (Punkte 50-52)

Alles sieht gut aus? Diese letzten drei Punkte binden die Arbeit zusammen, die Sie über die anderen 49 Punkte geleistet haben. Sie sind Ihr finales Qualitätstor, bevor Sie den Launch-Button drücken.

50. Wurde Cross-Browser-Testing durchgeführt?

Testen Sie in Chrome, Safari, Firefox und Edge. Chrome dominiert den Marktanteil im DACH-Raum, aber Safari hat dank iPhone- und Mac-Nutzern einen bedeutenden Anteil und macht oft 25 bis 30 Prozent des mobilen Traffics einer Seite aus. Jeder Browser rendert Schriften leicht unterschiedlich, unterstützt CSS-Eigenschaften mit unterschiedlicher Vollständigkeit und führt JavaScript mit verschiedenen Engines aus. Tools wie BrowserStack oder LambdaTest ermöglichen Tests über Dutzende von Browser- und Gerätekombinationen.

51. Sehen Social-Media-Sharing-Vorschauen korrekt aus?

Testen Sie Ihre Startseite und mehrere Unterseiten mit Facebooks Sharing Debugger und dem LinkedIn Post Inspector. Erscheinen das korrekte Bild, der Titel und die Beschreibung? Beim ersten Teilen sind Caching-Probleme häufig. Nutzen Sie den „Erneut scrapen“-Button in Facebooks Debugger, um den Cache zu leeren. Eine defekte oder fehlende Share-Vorschau sieht nicht nur unprofessionell aus. Sie reduziert aktiv die Wahrscheinlichkeit, dass Leute durchklicken.

52. Ist der Post-Launch-Aktionsplan bereit?

Eine Website zu launchen ist nicht die Ziellinie. Es ist der Startschuss. Bereiten Sie eine Aufgabenliste für die ersten 48 Stunden vor: Indexierungsanfragen in der Google Search Console stellen, den Launch in sozialen Medien ankündigen, überprüfen, dass Analytics-Daten fließen, und alle Formulare erneut mit echten Übermittlungen testen. Planen Sie ein Review-Meeting für eine Woche nach dem Launch, um Performance-Daten zu bewerten, eventuelle Probleme zu identifizieren und die nächste Runde von Verbesserungen zu planen.

Zusammenfassungstabelle

Für alle, die alle 52 Punkte auf einen Blick sehen möchten, hier die Aufschlüsselung nach Kategorie, Priorität und Zeitpunkt:

Kategorie Punkte Priorität Wann erledigen
Technische Infrastruktur 8 Kritisch Beginn der Entwicklung
Design und UX 9 Kritisch Design-Phase
Inhalte 8 Hoch 1 Woche vor Launch
SEO 9 Kritisch Über die gesamte Entwicklung
Sicherheit 6 Kritisch 3 Tage vor Launch
Performance 5 Hoch Finale Testphase
Analytics und Tracking 4 Hoch 2 Tage vor Launch
Abschlussprüfungen 3 Mittel Launch-Tag

Eine Website-Launch-Checkliste zu erstellen mag bürokratisch wirken. Aber ein einziger übersehener Punkt kann sich zu tagelanger Post-Launch-Feuerwehrarbeit auswachsen. Drei Wochen lang für Google unsichtbar sein, weil niemand die robots.txt geprüft hat. Chrome zeigt eine „Nicht sicher“-Warnung, weil das SSL-Zertifikat zwischen Staging und Produktion abgelaufen ist. Potenzielle Kunden verlieren, weil die Formularvalidierung nie mit echten Daten getestet wurde. Jedes einzelne dieser Szenarien ist real, und jedes einzelne ist vermeidbar.

Wir empfehlen, diese Liste in eine Google Sheets-Tabelle oder ein Notion-Board zu übertragen, jedem Punkt ein verantwortliches Teammitglied und ein Fälligkeitsdatum zuzuweisen und sie in Ihren Projektmanagement-Workflow zu integrieren. Wenn Sie im Team arbeiten, weisen Sie jede Kategorie einer anderen Person zu, um den Prozess zu beschleunigen. Für Agenturen, die mehrere Launches pro Quartal managen, verwandeln Sie das Ganze in eine wiederverwendbare Vorlage, die zu Beginn jedes Projekts hervorgeholt wird.

Ein letzter Punkt: Diese Website-Launch-Checkliste ist kein einmaliges Dokument. Sie sollte für jedes neue Seitenprojekt, jedes größere Update und jedes Redesign wieder geöffnet werden. Webtechnologien ändern sich, Googles Erwartungen entwickeln sich, Sicherheitsbedrohungen nehmen neue Formen an und Browserstandards verschieben sich. Überprüfen und aktualisieren Sie die Checkliste mindestens zweimal im Jahr und fügen Sie Erkenntnisse aus jedem abgeschlossenen Projekt als neue Punkte hinzu.

Bereit für einen Launch ohne Überraschungen

Von technischer Infrastruktur über SEO bis hin zu Sicherheit und Performance kümmert sich unser Team um jedes Detail, damit Ihr Launch vom ersten Tag an reibungslos verläuft.

Kontaktieren Sie uns →

Häufig gestellte Fragen

Warum brauche ich eine Website-Launch-Checkliste?

Technische Fehler, Sicherheitslücken und SEO-Versäumnisse, die während des Launch-Prozesses durchrutschen, können wochenlange Entwicklungsarbeit untergraben. Eine Checkliste stellt sicher, dass jedes Teammitglied nach demselben Standard arbeitet und vergessene Punkte auf ein Minimum reduziert werden. Launches ohne strukturierte Checkliste enden fast immer in einer Woche Post-Launch-Fehlerbehebung, die mehr an Entwicklerzeit und entgangenem Umsatz kostet, als die Checkliste gebraucht hätte.

Muss ich wirklich alle 52 Punkte abarbeiten?

Die Kategorien Technische Infrastruktur, Sicherheit und SEO sind kritisch. Punkte in diesen Bereichen zu überspringen, schafft ernsthafte Risiken. Andere Kategorien können je nach Projektumfang priorisiert werden. Eine einfache Einzelseite hat andere Anforderungen als ein komplexer E-Commerce-Shop. Mindestens SSL, robots.txt-Konfiguration, mobile Responsivität, Backups und Analytics-Einrichtung sollten jedoch für jedes Projekt abgeschlossen werden, unabhängig von Größe oder Budget.

Wie lange sollte der Website-Launch-Prozess dauern?

Das hängt von der Komplexität des Projekts ab. Für eine Unternehmenswebsite sollte der Test- und Review-Prozess nach der Entwicklung mindestens eine Woche dauern. Für E-Commerce-Seiten planen Sie zwei bis drei Wochen ein. Beginnen Sie mindestens 48 Stunden vor dem geplanten Launch mit der Checkliste, um Last-Minute-Überraschungen zu vermeiden. Vermeiden Sie es, Ihren Launch auf einen Freitag zu legen. Wenn etwas schiefgeht, ist es am Wochenende schwieriger und teurer, Unterstützung zu finden.

Gilt diese Checkliste auch, wenn ich nicht WordPress verwende?

Etwa 80 Prozent der Liste sind plattformunabhängig. SSL, DNS, SEO, Performance, Sicherheitsprinzipien und Analytics gelten für jede Website, unabhängig vom Technologie-Stack. WordPress-spezifische Punkte wie Plugin-Updates und wp-config.php-Berechtigungen sollten durch das Äquivalent für Ihre Plattform ersetzt werden. Ob Sie Shopify, Squarespace, Next.js oder eine maßgeschneiderte Anwendung nutzen, die gleiche zugrunde liegende Logik gilt.

Was ist der wichtigste Schritt unmittelbar nach dem Launch?

Innerhalb der ersten 24 Stunden: Übermitteln Sie Ihre Sitemap in der Google Search Console und fordern Sie die Indexierung Ihrer wichtigsten Seiten an. Überprüfen Sie, dass GA4-Daten korrekt fließen. Testen Sie alle Formulare noch einmal mit echten Daten. Am Ende der ersten Woche prüfen Sie Ihre Core Web Vitals-Werte, denn Labordaten von Testtools und Felddaten von echten Nutzern erzählen oft unterschiedliche Geschichten.

Wie oft sollte ich diese Checkliste aktualisieren?

Überprüfen Sie die Checkliste zu Beginn jedes neuen Projekts. Webtechnologien entwickeln sich schnell: Google aktualisiert Core Web Vitals-Metriken, neue Sicherheitslücken tauchen auf und Browser übernehmen neue Standards. Die Liste mindestens zweimal im Jahr zu aktualisieren, ist gute Praxis. Fügen Sie Erkenntnisse aus jedem abgeschlossenen Projekt als neue Checklistenpunkte hinzu. Die Liste wird mit jeder Nutzung besser, und im Laufe der Zeit wird sie zu einem der wertvollsten Assets in Ihrem Webentwicklungsprozess.

Quellen

  • Google Web Vitals Dokumentation
  • Google Search Central
  • WordPress Codex
  • Cloudflare Learning Centre
  • OWASP Web Security Testing Guide
  • Bundesdatenschutzbeauftragter (BfDI) Leitlinien
  • Web Content Accessibility Guidelines (WCAG) 2.2
  • Barrierefreiheitsstärkungsgesetz (BFSG)