Website Launch Checklist 2026: SEO, Datenschutz, Barrierefreiheit, Security und Performance vor dem Go-live prüfen

Ein Website-Launch fühlt sich oft wie der Abschluss eines Projekts an. Für Nutzerinnen und Nutzer, Suchmaschinen, Browser, Datenschutzbehörden, Security-Scanner und KI-Systeme ist er aber der Anfang.

Genau deshalb ist der Go-live ein Risikomoment. Eine Website kann visuell fertig wirken und trotzdem zentrale Probleme haben: noindex ist noch aktiv, wichtige Seiten liefern 404, Formulare übertragen Daten an falsche Tools, Cookie-Banner blockieren nichts, Core Web Vitals sind schlecht, strukturierte Daten widersprechen dem sichtbaren Inhalt, die Datenschutzerklärung ist veraltet oder das neue CMS nutzt unsichere Komponenten.

Eine gute Website Launch Checklist prüft deshalb nicht nur Design, Text und Browserdarstellung. Sie prüft, ob die neue Website auffindbar, nutzbar, messbar, sicher, rechtskonform, performant und nachweisbar ist.

Kurzfassung

Vor dem Go-live sollten Teams mindestens diese Bereiche prüfen:

1. Crawlability und Indexierbarkeit
   Kann Google die relevanten Seiten abrufen? Sind robots.txt, noindex, Canonicals, Statuscodes und Sitemaps korrekt?

2. SEO-Basics und Content-Struktur
   Sind Title, Meta Descriptions, H1/H2-Struktur, interne Links, Bilder, Alt-Texte und strukturierte Daten sauber umgesetzt?

3. Tracking, Datenschutz und Consent
   Welche Tools laden vor Einwilligung? Welche Daten werden verarbeitet? Ist Analytics privacy-first konfiguriert? Sind Datenschutzhinweise vollständig?

4. Barrierefreiheit
   Sind Kontraste, Tastaturbedienung, Labels, Fokuszustände, Alternativtexte und Fehlermeldungen ausreichend? Gibt es EAA-/BFSG-relevante Risiken?

5. Security und technische Basis
   Sind HTTPS, HSTS, Security Headers, Mixed Content, Cookie Flags, CMS-/Plugin-Versionen und Frontend-Libraries geprüft?

6. Performance und Core Web Vitals
   Sind LCP, INP und CLS für reale Nutzerinnen und Nutzer akzeptabel? Welche Templates, Geräte oder Länder sind kritisch?

7. Content-Integrität
   Funktionieren interne Links, externe Links, Bilder, Downloads, Formulare, Checkout, Login und eingebundene Assets?

8. Nachhaltigkeit und Page Weight
   Wie groß sind Seiten, Bilder, Skripte und Fonts? Läuft die Website auf verifiziert grünem Hosting? Welche Assets treiben den CO₂-Fußabdruck?

Der wichtigste Punkt: Ein Launch-Check ist kein einzelner Screenshot. Er sollte als Baseline dokumentiert werden, damit Teams nach dem Go-live nachweisen können, was geprüft wurde, was offen war und wie sich die Website danach entwickelt.

Warum klassische Launch-Checklisten nicht mehr reichen

Viele Launch-Checklisten stammen aus einer Zeit, in der Webprojekte vor allem aus Design, CMS-Setup, Content-Pflege und Browser-Tests bestanden. Das reicht 2026 nicht mehr.

Heute berührt ein Website-Launch gleichzeitig mehrere Risikobereiche:

• Search Visibility: Suchmaschinen müssen Seiten finden, rendern, verstehen und indexieren können. Google nennt als technische Mindestanforderungen unter anderem: Googlebot darf nicht blockiert sein, die Seite muss mit HTTP 200 funktionieren und indexierbaren Inhalt enthalten.[^google-technical]
• Privacy und Consent: Marketing- und Analytics-Tools verarbeiten häufig personenbezogene oder pseudonyme Daten. Datenschutz muss vor dem Launch technisch geprüft werden, nicht erst nach der ersten Beschwerde.
• Accessibility: Barrierefreiheit ist nicht nur UX, sondern für viele digitale Angebote in Europa inzwischen auch ein Compliance-Thema. Der European Accessibility Act gilt seit dem 28. Juni 2025 für bestimmte Produkte und Dienstleistungen, darunter auch E-Commerce-Angebote.[^eaa]
• Security: Neue Themes, neue Plugins, neue JavaScript-Libraries und neue Server-Konfigurationen erzeugen neue Angriffsflächen. OWASP führt „Vulnerable and Outdated Components“ als kritische Risikokategorie.[^owasp-a06]
• Performance: Google beschreibt Core Web Vitals als Metriken für reale Nutzererfahrung in den Bereichen Ladezeit, Interaktivität und visuelle Stabilität.[^google-cwv]
• AI Search und LLMs: Inhalte müssen maschinenlesbar, eindeutig, zitierfähig und semantisch gut strukturiert sein. Das betrifft nicht nur SEO, sondern auch GEO — Generative Engine Optimization.
• Sustainability: Page Weight, Asset-Mix und Hosting werden zunehmend Teil von Digital- und ESG-Gesprächen. Der Sustainable Web Design Model-Ansatz nutzt unter anderem Datentransfer als Input für Emissionsschätzungen.[^swdm]

Ein Launch ist deshalb nicht nur ein Projektende. Er ist der Moment, in dem Annahmen überprüfbar werden.

Die Website Launch Checklist 2026

1. Crawlability und Indexierbarkeit prüfen

Die erste Frage lautet: Können Suchmaschinen die richtigen Seiten überhaupt sehen?

Das klingt banal. In Relaunches ist es aber einer der häufigsten kritischen Fehler. Entwicklungsumgebungen nutzen oft noindex, Passwortschutz oder blockierende robots.txt-Regeln. Wenn diese Einstellungen in Produktion landen, kann die Website technisch live sein, aber organisch unsichtbar bleiben.

Prüfen Sie vor dem Go-live

• Ist die Produktionsdomain öffentlich erreichbar?
• Liefert jede wichtige URL HTTP 200?
• Sind robots.txt-Regeln korrekt?
• Gibt es versehentliche noindex-Tags?
• Sind Canonicals korrekt gesetzt?
• Gibt es eine aktuelle XML-Sitemap?
• Verweist die Sitemap auf indexierbare, kanonische URLs?
• Gibt es Redirect Chains oder Loops?
• Sind alte URLs sinnvoll auf neue URLs weitergeleitet?
• Sind Sprachversionen und hreflang-Verweise korrekt?

Typische Launch-Fehler

• Staging-robots.txt blockiert weiterhin alle Crawler.
• Blogartikel enthalten noindex, weil sie aus einem Testsystem kopiert wurden.
• Canonicals zeigen auf die alte Domain oder auf die Startseite.
• Produkt-, Kategorie- oder Leistungsseiten fehlen in der Sitemap.
• Weiterleitungen führen alle pauschal auf die Startseite.
• Alte URLs liefern 404, obwohl sie Backlinks oder Rankings hatten.

Verbindung zu +Analytics Pro

Der Basic SEO Checker von +Analytics Pro prüft zentrale Onpage- und technische SEO-Signale. In Kombination mit dem Broken Link Scanner und wiederkehrenden Checks kann ein Launch-Team nicht nur vor dem Go-live prüfen, sondern auch nach dem Launch erkennen, ob neue Fehler entstehen.

2. SEO-Basics und Content-Struktur prüfen

SEO vor dem Launch ist kein Keyword-Stuffing. Es geht darum, ob jede wichtige Seite klar sagt:

• Worum geht es?
• Für wen ist es relevant?
• Welche Suchintention erfüllt die Seite?
• Wie hängt die Seite mit anderen Seiten zusammen?
• Können Suchmaschinen und KI-Systeme die Information eindeutig interpretieren?

Google beschreibt strukturierte Daten als standardisiertes Format, mit dem Seiten explizite Hinweise über die Bedeutung ihres Inhalts geben können.[^google-structured-data] Das ersetzt keine guten Inhalte, kann aber helfen, Entitäten, Angebote, Produkte, Organisationen, FAQs oder Artikel klarer maschinenlesbar zu machen.

Prüfen Sie vor dem Go-live

• Hat jede wichtige Seite genau einen klaren H1?
• Sind Title Tags eindeutig, suchnah und nicht dupliziert?
• Sind Meta Descriptions verständlich und klickrelevant?
• Gibt es eine logische H2/H3-Struktur?
• Sind interne Links kontextuell sinnvoll gesetzt?
• Haben Bilder sprechende Dateinamen und sinnvolle Alt-Texte?
• Sind Open Graph und Social Preview korrekt?
• Gibt es passende strukturierte Daten?
• Stimmen strukturierte Daten mit sichtbarem Inhalt überein?
• Sind FAQ-, HowTo-, Product-, Organization- oder Article-Markups valide, falls verwendet?

Typische Launch-Fehler

• Alle Seiten nutzen denselben Title.
• Meta Descriptions fehlen oder stammen noch aus Platzhaltertexten.
• Die H1 ist ein Slogan statt einer klaren Themenbeschreibung.
• Bilder heißen final_final_header_2.webp.
• Interne Links zeigen auf alte Slugs.
• JSON-LD enthält Daten, die auf der Seite nicht sichtbar sind.
• FAQ-Markup wird eingebaut, obwohl keine echten FAQ-Inhalte vorhanden sind.

Verbindung zu +Analytics Pro

+Analytics Pro verbindet SEO-Checks mit GEO-Checks. Das ist für 2026 relevant, weil klassische Suchmaschinenoptimierung und AI-Search-Readiness zusammenwachsen: Eine Seite muss nicht nur ranken, sondern auch als Quelle verständlich, extrahierbar und konsistent sein.

3. Datenschutz, Tracking und Consent prüfen

Ein Website-Launch verändert fast immer die technische Datenverarbeitung. Neue Formulare, neue Analytics, neue Chat-Tools, neue CRM-Integrationen, neue Newsletter-Popups oder neue Payment-Flows können Datenschutzrisiken erzeugen.

Der entscheidende Fehler: Datenschutz wird oft als Dokumentationsaufgabe behandelt. Tatsächlich ist er eine technische Prüfung.

Prüfen Sie vor dem Go-live

• Welche externen Skripte laden beim ersten Seitenaufruf?
• Welche Cookies, Local-Storage- oder Session-Storage-Einträge werden gesetzt?
• Laden Marketing- oder Tracking-Tools vor Einwilligung?
• Ist der Consent-Banner technisch wirksam oder nur sichtbar?
• Sind Kategorien, Zwecke und Anbieter korrekt beschrieben?
• Ist die Datenschutzerklärung auf dem Stand der tatsächlichen Tool-Landschaft?
• Werden Formulardaten nur an vorgesehene Systeme übertragen?
• Ist Analytics datensparsam konfiguriert?
• Gibt es eine Rechtsgrundlage für jede relevante Verarbeitung?
• Gibt es ein Opt-out, falls erforderlich?

Die DSGVO verlangt nicht nur Maßnahmen, sondern auch Nachweisbarkeit. Art. 24 DSGVO verpflichtet Verantwortliche, geeignete technische und organisatorische Maßnahmen umzusetzen und deren Einhaltung nachweisen zu können; diese Maßnahmen sollen bei Bedarf überprüft und aktualisiert werden.[^gdpr-art24]

Typische Launch-Fehler

• Der Cookie-Banner erscheint, aber blockiert keine Skripte.
• Das Consent-Tool kennt nicht alle eingebundenen Drittanbieter.
• Alte Tracking-Pixel bleiben im Tag Manager aktiv.
• Formulare senden Daten an Test-Mailadressen oder falsche CRM-Felder.
• Die Datenschutzerklärung nennt Tools, die nicht mehr verwendet werden — oder verschweigt neue Tools.
• Analytics ist unnötig invasiv konfiguriert, obwohl einfache Webanalyse reichen würde.

Verbindung zu +Analytics Pro

+Analytics Pro setzt auf privacy-first Analytics und bietet zusätzlich Privacy-/GDPR-Checks. Für Launches ist das besonders wichtig: Teams können prüfen, ob die Website messbar ist, ohne unnötig neue Consent- und Tracking-Komplexität einzuführen.

4. Barrierefreiheit vor dem Launch prüfen

Barrierefreiheit wird oft erst dann geprüft, wenn eine Website bereits live ist. Das ist teuer, weil Accessibility-Probleme tief in Designsystem, Komponenten, Templates, Formularen und Content-Prozessen stecken können.

Die WCAG 2.2 decken Empfehlungen ab, um Webinhalte für Menschen mit unterschiedlichen Behinderungen besser zugänglich zu machen; die Richtlinien betreffen unter anderem visuelle, auditive, motorische, sprachliche, kognitive und neurologische Einschränkungen.[^wcag22]

Prüfen Sie vor dem Go-live

• Sind Farbkontraste ausreichend?
• Ist die Website vollständig per Tastatur bedienbar?
• Sind Fokuszustände sichtbar?
• Haben Formularfelder verständliche Labels?
• Sind Fehlermeldungen klar und mit den betroffenen Feldern verbunden?
• Haben relevante Bilder sinnvolle Alternativtexte?
• Sind dekorative Bilder korrekt leer ausgezeichnet?
• Ist die Überschriftenstruktur logisch?
• Funktionieren Navigation, Menüs, Modal-Fenster und Accordions mit Screenreadern?
• Sind Touch-Ziele ausreichend groß?
• Gibt es keine Inhalte, die nur durch Farbe verständlich sind?

Typische Launch-Fehler

• Designerisch schöne Buttons haben zu wenig Kontrast.
• Cookie-Banner oder Popups blockieren Tastaturnavigation.
• Formularfehler werden nur rot markiert, aber nicht textlich erklärt.
• Icons ohne Textlabel sind für Screenreader unverständlich.
• Mega-Menüs funktionieren nur mit Maus.
• Carousel- oder Slider-Komponenten sind nicht zugänglich.

Verbindung zu +Analytics Pro

+Analytics Pro bietet Accessibility-Checks wie WAVE Accessibility und PHPAlly Accessibility. Der Wert liegt nicht nur im Finden einzelner Fehler, sondern in der systematischen Bewertung: Wo steht die Seite vor dem Launch, welche Barrieren sind kritisch und wie entwickelt sich die Barrierefreiheit nach Updates?

5. Security und technische Risiken prüfen

Security ist beim Website-Launch oft unsichtbar. Solange die Seite lädt, sehen Nicht-Security-Teams kein Problem. Aber genau hier entstehen Risiken: neue Server-Konfigurationen, neue CMS-Versionen, neue Plugins, neue Formulare, neue JavaScript-Pakete, neue CDN-Regeln.

Prüfen Sie vor dem Go-live

• Ist HTTPS überall erzwungen?
• Gibt es Mixed Content?
• Ist HSTS korrekt gesetzt?
• Sind Security Headers vorhanden, etwa CSP, X-Frame-Options bzw. frame-ancestors, X-Content-Type-Options und Referrer-Policy?
• Sind Cookies mit sinnvollen Flags gesetzt, etwa Secure, HttpOnly und SameSite?
• Werden Server-Versionen oder technische Details unnötig offengelegt?
• Sind CMS, Plugins, Themes und Libraries aktuell?
• Gibt es bekannte CVEs für verwendete Komponenten?
• Sind Admin-, Login- oder Backend-Bereiche unnötig öffentlich erkennbar?
• Funktionieren Formulare mit Spam- und Abuse-Schutz?

Typische Launch-Fehler

• HTTPS ist aktiv, aber HTTP-URLs werden nicht sauber weitergeleitet.
• HSTS fehlt.
• Alte JavaScript-Libraries werden aus dem vorherigen Theme übernommen.
• WordPress- oder TYPO3-Versionen sind öffentlich erkennbar.
• Login-Pfade sind nicht abgesichert.
• Cookies werden ohne Secure gesetzt.
• Externe Skripte können mehr als nötig.

Verbindung zu +Analytics Pro

Der Basic Web Security Checker von +Analytics Pro prüft unter anderem HTTPS/HSTS, Security Headers, Mixed Content, Server Disclosure, Cookie Flags und verwundbare Frontend-Libraries. Für CMS-basierte Websites ergänzen WordPress- und TYPO3-Security-Checks die Prüfung.

6. Performance und Core Web Vitals prüfen

Performance ist beim Launch besonders kritisch, weil neue Websites häufig schwerer sind als alte. Mehr Animation, mehr Bilder, mehr JavaScript, mehr Tracking, mehr Fonts, mehr Consent-Logik — und plötzlich sieht die Website modern aus, fühlt sich aber langsam an.

Google empfiehlt für gute Nutzererfahrung unter anderem LCP innerhalb von 2,5 Sekunden, INP unter 200 Millisekunden und stabile Layouts ohne störende Verschiebungen.[^google-cwv]

Prüfen Sie vor dem Go-live

• Wie gut sind LCP, INP und CLS auf den wichtigsten Seitentypen?
• Unterscheiden sich Desktop und Mobile stark?
• Sind Hero-Bilder optimiert?
• Werden Bilder in modernen Formaten ausgeliefert?
• Werden unnötige JavaScript-Bundles geladen?
• Blockieren Fonts oder Third-Party-Skripte den Seitenaufbau?
• Werden kritische CSS- und JS-Ressourcen sinnvoll priorisiert?
• Gibt es Lazy Loading für nicht-kritische Medien?
• Funktionieren Seiten auch bei langsameren Verbindungen?

Typische Launch-Fehler

• Riesige Hero-Videos laufen auf mobilen Geräten automatisch.
• Ein Cookie-Banner lädt viele Skripte, bevor die Seite nutzbar ist.
• Webfonts blockieren Textdarstellung.
• Sliders, Animationen und Tracking-Skripte verschlechtern INP.
• Bilder werden zwar optisch verkleinert, aber in voller Originalgröße geladen.

Verbindung zu +Analytics Pro

+Analytics Pro misst Core Web Vitals aus realer Nutzung und kann Performance-Probleme nach Seite, Gerät oder Land sichtbar machen. Für Launches ist das wichtig, weil Lab-Tests allein nicht zeigen, wie echte Nutzerinnen und Nutzer die neue Website erleben.

7. Content-Integrität und kritische Nutzerpfade prüfen

Eine Website ist nicht live, wenn sie veröffentlicht ist. Sie ist live, wenn die wichtigsten Nutzerpfade funktionieren.

Prüfen Sie vor dem Go-live

• Funktionieren alle Hauptnavigationselemente?
• Funktionieren Footer-Links?
• Funktionieren Kontakt-, Demo-, Newsletter- und Downloadformulare?
• Funktionieren Login, Checkout, Warenkorb oder Terminbuchung?
• Funktionieren interne Links in Blogartikeln, Produktseiten und Landingpages?
• Laden Bilder, Videos, CSS, JavaScript und PDFs korrekt?
• Sind externe Links erreichbar?
• Sind 404-Seiten hilfreich gestaltet?
• Werden alte URLs sinnvoll weitergeleitet?
• Funktionieren mehrsprachige Umschalter?

Typische Launch-Fehler

• Kontaktformular funktioniert, aber Benachrichtigungen gehen an eine Testadresse.
• Downloads sind intern verlinkt, aber nicht öffentlich erreichbar.
• Alte Kampagnenlinks liefern 404.
• Bilder fehlen nur in bestimmten Sprachversionen.
• Externe Quellen in Fachartikeln sind nicht mehr erreichbar.
• Call-to-Action-Buttons zeigen auf Staging-URLs.

Verbindung zu +Analytics Pro

Der Broken Link Scanner prüft interne und externe Links, Bilder, CSS, JavaScript und andere Assets. Das ist besonders wertvoll vor und nach Relaunches, weil viele Fehler erst durch neue URL-Strukturen, CMS-Migrationen oder Sprachversionen entstehen.

8. Nachhaltigkeit und Page Weight prüfen

Digitale Nachhaltigkeit ist nicht nur ein ESG-Thema. Sie ist oft auch ein Performance-, UX- und Kosten-Thema. Große Seiten laden langsamer, verbrauchen mehr Datenvolumen und erhöhen die technische Komplexität.

Prüfen Sie vor dem Go-live

• Wie groß sind die wichtigsten Seitentypen?
• Welche Assets treiben das Seitengewicht?
• Wie groß sind Bilder, JavaScript, CSS, Fonts und Videos?
• Gibt es unnötige Third-Party-Skripte?
• Wird grünes Hosting genutzt oder nachgewiesen?
• Sind Bildgrößen, Kompression und Formate optimiert?
• Können Videos optional statt automatisch geladen werden?
• Gibt es alte Skripte, die keinen messbaren Nutzen mehr haben?

Typische Launch-Fehler

• Neue Markenbilder werden unkomprimiert eingebunden.
• Mehrere Font-Familien und Schriftschnitte laden global.
• Third-Party-Skripte bleiben aktiv, obwohl sie nicht mehr genutzt werden.
• Landingpages enthalten große Animationen ohne geschäftlichen Nutzen.
• Green-Hosting-Aussagen sind nicht nachweisbar.

Verbindung zu +Analytics Pro

Die Carbon Checker von +Analytics Pro messen Page Size, Asset-Mix und Green-Hosting-Signale. Der Simple Carbon Checker kombiniert Transfergrößen mit Faktoren aus dem Sustainable Web Design Model und verifiziert Hosting-Signale über die Green Web Foundation.[^oneco-carbon]

Priorisierung: Was ist vor dem Launch ein Blocker?

Nicht jedes Issue muss den Launch stoppen. Aber jedes Issue braucht eine Priorität.

Launch-Blocker

Diese Probleme sollten vor dem Go-live behoben werden:

• Relevante Seiten sind durch robots.txt oder noindex blockiert.
• Wichtige Seiten liefern 404, 500 oder andere Fehlerstatuscodes.
• Formulare, Checkout, Login oder Buchung funktionieren nicht.
• Consent-Mechanismus ist technisch unwirksam.
• HTTPS ist fehlerhaft oder Mixed Content bricht zentrale Funktionen.
• Kritische Security-Lücken sind bekannt.
• Website ist für Tastaturnutzung oder Screenreader in zentralen Pfaden nicht nutzbar.
• Datenschutz- oder Impressumsinformationen fehlen.
• Alte URLs mit relevanten Rankings oder Backlinks werden nicht weitergeleitet.

Hohe Priorität

Diese Probleme sollten idealerweise vor Launch gelöst oder verbindlich terminiert werden:

• Schlechte Core Web Vitals auf wichtigen Templates.
• Fehlende oder fehlerhafte strukturierte Daten auf kommerziell wichtigen Seiten.
• Viele kaputte interne Links.
• Schwere Accessibility-Probleme außerhalb der Kernpfade.
• Unnötige Third-Party-Skripte.
• Fehlende HSTS- oder Security-Header-Konfiguration.
• Duplizierte Titles und unklare H1-Strukturen.

Mittlere Priorität

Diese Punkte können häufig nach Launch optimiert werden, sofern sie dokumentiert sind:

• Verbesserungen an Meta Descriptions.
• Optimierung einzelner Alt-Texte.
• Reduktion von Page Weight auf weniger wichtigen Seiten.
• Zusätzliche FAQ- oder HowTo-Strukturen.
• Verbesserte Social Previews.
• Content-Erweiterungen für Long-Tail-Suchintentionen.

Empfohlener Prüfplan für Launches

14 Tage vor Launch: Baseline erstellen

• Wichtige Seitentypen definieren.
• Crawling- und Indexierbarkeitscheck durchführen.
• SEO-, Accessibility-, Privacy-, Security- und Performance-Checks ausführen.
• Kritische Nutzerpfade testen.
• Issue-Liste mit Prioritäten erstellen.

7 Tage vor Launch: Blocker beheben

• Launch-Blocker schließen.
• Redirect-Map finalisieren.
• Datenschutz- und Consent-Konfiguration prüfen.
• Security- und Accessibility-Fixes validieren.
• Analytics und Conversion-Events testen.

1 Tag vor Launch: Freeze und Kontrolllauf

• Content-Freeze für kritische Seiten.
• Finalen Multi-Check ausführen.
• Staging- und Produktionskonfiguration vergleichen.
• DNS-, CDN-, Cache- und Redirect-Regeln prüfen.
• Rollback-Plan bestätigen.

Launch-Tag: Produktionsprüfung

• Startseite, Hauptseiten und Conversion-Pfade prüfen.
• Statuscodes, Redirects und Sitemap kontrollieren.
• Consent und Analytics in Produktion testen.
• Search Console, Serverlogs und Monitoring prüfen.
• Kritische Checks erneut ausführen.

24 Stunden nach Launch: Fehler aus echter Nutzung erkennen

• Analytics-Daten auf Ausreißer prüfen.
• 404s und fehlerhafte Pfade identifizieren.
• Formulare und Conversion Events validieren.
• Core Web Vitals und Performance-Signale beobachten.
• Nutzerfeedback und Supportanfragen auswerten.

7 bis 30 Tage nach Launch: Monitoring statt Projektabschluss

• Wiederkehrende Checks einrichten.
• Offene Issues priorisieren.
• Performance- und SEO-Daten mit Baseline vergleichen.
• Content- und GEO-Optimierungen ergänzen.
• Stakeholder-Report erstellen.

Copy-and-Paste: Kompakte Website Go-Live Checkliste

SEO und Indexierung

• [ ] Googlebot nicht blockiert
• [ ] Keine versehentlichen noindex-Tags
• [ ] Wichtige Seiten liefern HTTP 200
• [ ] XML-Sitemap aktuell
• [ ] Canonicals korrekt
• [ ] Redirects alter URLs eingerichtet
• [ ] Titles eindeutig
• [ ] Meta Descriptions gepflegt
• [ ] H1/H2-Struktur logisch
• [ ] Interne Links geprüft
• [ ] Strukturierte Daten valide

Datenschutz und Tracking

• [ ] Alle Cookies und Skripte identifiziert
• [ ] Consent-Banner technisch wirksam
• [ ] Datenschutzerklärung aktuell
• [ ] Formulardatenflüsse geprüft
• [ ] Analytics datensparsam konfiguriert
• [ ] Keine unnötigen Drittanbieter aktiv
• [ ] Opt-out oder Consent-Einstellungen geprüft

Barrierefreiheit

• [ ] Tastaturbedienung funktioniert
• [ ] Fokuszustände sichtbar
• [ ] Kontraste ausreichend
• [ ] Formulare korrekt gelabelt
• [ ] Fehlermeldungen verständlich
• [ ] Alt-Texte gepflegt
• [ ] Navigation und Popups zugänglich
• [ ] Keine Information nur über Farbe

Security

• [ ] HTTPS erzwungen
• [ ] Kein Mixed Content
• [ ] HSTS geprüft
• [ ] Security Headers gesetzt
• [ ] Cookie Flags sinnvoll konfiguriert
• [ ] CMS, Plugins und Libraries aktuell
• [ ] Keine unnötige Server Disclosure
• [ ] Admin-/Loginbereiche abgesichert

Performance

• [ ] LCP geprüft
• [ ] INP geprüft
• [ ] CLS geprüft
• [ ] Bilder optimiert
• [ ] Fonts reduziert
• [ ] JavaScript-Bundles geprüft
• [ ] Third-Party-Skripte minimiert
• [ ] Mobile Performance geprüft

Content-Integrität

• [ ] Interne Links funktionieren
• [ ] Externe Links funktionieren
• [ ] Bilder laden korrekt
• [ ] Downloads erreichbar
• [ ] Formulare getestet
• [ ] Login/Checkout/Buchung getestet
• [ ] Mehrsprachige Pfade geprüft
• [ ] 404-Seite hilfreich

Nachhaltigkeit

• [ ] Page Weight gemessen
• [ ] Asset-Mix analysiert
• [ ] Green-Hosting-Status geprüft
• [ ] Große Bilder und Videos reduziert
• [ ] Unnötige Third-Party-Skripte entfernt
• [ ] Carbon-Baseline dokumentiert

Wie +Analytics Pro beim Website-Launch hilft

+Analytics Pro ist für Launches besonders wertvoll, weil es nicht nur einzelne Metriken zeigt, sondern mehrere Website-Risiken in einem Prozess bündelt.

1. Vor dem Launch: objektive Baseline

Teams können wichtige Seiten prüfen, bevor sie live gehen: SEO, GEO, Accessibility, Privacy, Security, Carbon, Broken Links, CMS-Security und Performance. Das verhindert, dass Launch-Freigaben nur auf subjektivem Eindruck basieren.

2. Beim Launch: schnelle Validierung

Direkt nach dem Go-live können dieselben Checks erneut ausgeführt werden. So wird sichtbar, ob Produktionskonfiguration, Redirects, Consent, Security Headers oder öffentliche Assets anders funktionieren als im Staging.

3. Nach dem Launch: wiederkehrende Checks

Der wichtigste Unterschied liegt im Monitoring. Websites verändern sich durch Content-Pflege, Plugin-Updates, neue Kampagnen, neue Skripte und neue rechtliche Anforderungen. +Analytics Pro kann Checks wiederholen und neue Issues sichtbar machen, statt Website-Qualität als einmaligen Audit zu behandeln.

4. Für Stakeholder: teilbare Nachweise

Mit Transparency Mode, Stable Links, onEco Certified Badge, +Disclosure Profile und Evidence Chain kann Website-Qualität nachvollziehbar kommuniziert werden. Das ist hilfreich für Geschäftsführung, Kunden, Agenturen, Compliance, ESG und Procurement.

5. Für Marketing: privacy-first messen

Nach dem Launch geht es nicht nur um Fehlerfreiheit, sondern um Wirkung: Welche Seiten funktionieren, welche Kampagnen bringen Nachfrage, welche Funnels brechen ab, welche Quellen erzeugen Umsatz? +Analytics Pro verbindet privacy-first Analytics mit Checks, damit Teams nicht zwischen Sichtbarkeit, Datenschutz und operativer Website-Qualität wechseln müssen.

Fazit

Ein Website-Launch ist nicht der Moment, in dem alles fertig ist. Es ist der Moment, in dem die Website beweisen muss, dass sie funktioniert.

Die entscheidende Frage lautet nicht: „Sieht die Website gut aus?“
Die bessere Frage lautet: Ist sie auffindbar, nutzbar, sicher, rechtskonform, performant, messbar und nachweisbar?

Wer diese Fragen vor dem Go-live systematisch beantwortet, reduziert Launch-Risiken. Wer sie nach dem Go-live regelmäßig weiter prüft, verwandelt Website-Qualität von einem Projektstatus in einen operativen Vorteil.

+Analytics Pro unterstützt genau diesen Übergang: von einmaliger Launch-Abnahme zu kontinuierlicher Website-Verbesserung — mit privacy-first Analytics, wiederkehrenden Checks, Issue Flow und nachvollziehbaren Nachweisen.

Strukturierte Daten für die Veröffentlichung

Für diesen Artikel eignen sich:

• Article
• FAQPage für die FAQ-Sektion
• HowTo nur dann, wenn die Checkliste als klar sequenzierter Prozess ausgespielt wird
• BreadcrumbList
• Organization für onEco

Wichtig: Strukturierte Daten sollten nur Inhalte beschreiben, die für Nutzerinnen und Nutzer auch sichtbar sind. Google weist ausdrücklich darauf hin, keine strukturierten Daten zu Informationen hinzuzufügen, die nicht auf der Seite sichtbar sind.[^google-structured-data]