Zum Hauptinhalt springen
Login
SEO16 Min. Lesezeit

Der 15-minütige Pre-Launch-Website-QA-Check, der unseren Produktlaunch gerettet hat

Die Staging-Site sah perfekt aus. Dann liefen wir Site Audit 48 Stunden vor dem Launch. 7 kritische Probleme hätten die Conversion-Rate ruiniert.

TLDR

Unsere neu gestaltete Marketing-Site sah zwei Tage vor dem Launch im QA perfekt aus. Site Audit fand sieben kritische Probleme, die die Standard-QA übersehen hatte: defekte Social-Sharing-Tags, fehlendes Schema-Markup, Mobile-Viewport-Bugs, Sitemap-Fehler, Barrierefreiheitsmängel, fehlende Security-Header und schlechte Performance unter Last. Wir haben alles vor dem Launch behoben und Day-One-Desaster vermieden. Standard-QA prüft, ob Seiten laden. Site Audit prüft, ob sie konvertieren, ranken und Ergebnisse liefern. Prüfen Sie Staging-Sites immer mit produktionsreifen Tools, bevor Sie launchen.

In diesem Artikel

Das Szenario: Redesign der neuen Marketing-Site, Launch in 48 Stunden

Unser interner QA-Prozess: Design freigegeben, Texte finalisiert, Seiten rendern korrekt, Formulare werden abgeschickt

Wir fühlten uns bereit zu launchen.

Dann führten wir Site Audit auf der Staging-Site aus.

Ergebnis: 7 kritische Probleme, die unsere Conversion-Rate, unser SEO-Ranking und unsere Glaubwürdigkeit am ersten Tag zerstört hätten.

Hier ist, was wir 48 Stunden vor dem Launch gefunden haben. Und warum Pre-Launch-Audits nicht verhandelbar sind.

Das Pre-Launch-Problem der falschen Sicherheit

Standard-Pre-Launch-QA-Checkliste:

  • Lädt die Site?
  • Sehen die Seiten auf Desktop und Mobile korrekt aus?
  • Werden Formulare erfolgreich abgeschickt?
  • Gibt es offensichtlich defekte Links?

Was diese Checkliste übersieht:

  • Social-Sharing-Vorschauen (Open-Graph-Tags)
  • Schema.org strukturierte Daten für SEO
  • Mobile-Viewport-Randfälle
  • Barrierefreiheit für Screenreader
  • Sitemap-Genauigkeit
  • Performance unter Last
  • Security-Header

Das Ergebnis: Sites, die im QA perfekt aussehen, aber in der Produktion versagen, sobald echte Nutzer über Google, Twitter und LinkedIn ankommen.

KERNAUSSAGE: Standard-QA prüft, ob Seiten laden. Pre-Launch-Audits prüfen, ob sie konvertieren. Die Lücke zwischen „Site funktioniert“ und „Site treibt Conversions“ umfasst Social-Vorschauen, Schema-Markup, Mobile-Randfälle, Barrierefreiheit und Performance unter Last. All das ist für Standard-QA unsichtbar, aber entscheidend für einen erfolgreichen Launch.

Unser Pre-Launch-Audit: Was Site Audit fand

Kontext: Redesign der Marketing-Site für einen neuen Produktlaunch

  • Ziel: Signups über den Product-Hunt-Launch generieren (erwartet: 5.000+ Besucher am ersten Tag)
  • Zeitplan: 48 Stunden bis zum öffentlichen Launch
  • Interner QA-Status: Alles grün, Design- und Dev-Teams zuversichtlich

Site-Audit-Ergebnis: 7 kritische Probleme, 3 davon Showstopper

Problem 1: Defekte Social-Sharing-Vorschauen (SHOWSTOPPER)

Was wir intern getestet haben: Auf „Auf Twitter teilen“ geklickt, hat funktioniert

Was Site Audit fand: Das Open-Graph-Bild lieferte einen 404

Das Problem:

<!-- Unser Code -->
<meta property="og:image" content="https://staging.example.com/og-image.png" />

<!-- Die Realität -->
<!-- /og-image.png lieferte 404, weil wir vergessen hatten, es dem Build-Output hinzuzufügen -->

Warum das wichtig ist:

  • Wir planten, auf Product Hunt zu launchen
  • Product Hunt generiert Vorschau-Karten automatisch aus Open-Graph-Tags
  • Unsere Vorschaukarte hätte statt eines überzeugenden Bilds ein defektes Bildsymbol gezeigt
  • Twitter-Shares hätten keine Bildvorschau gehabt
  • LinkedIn-Shares hätten den Fallback verwendet (winziges Logo statt vollem Hero-Bild)

Auswirkung, wenn wir mit diesem Bug gelauncht hätten:

  • Das Product-Hunt-Listing wirkt unprofessionell (defektes Bild in der Vorschau)
  • Social Shares bekommen 50-70 % weniger Klicks ohne Bildvorschau (Branchen-Benchmark)
  • Erwartete 5.000 Besucher → wären wegen schlechter Social-CTR nur ~2.000 gewesen

Die Lösung (5 Minuten):

  1. og-image.png in den /public-Ordner gelegt
  2. Geprüft, dass das Bild unter https://staging.example.com/og-image.png lädt
  3. Mit dem Vorschau-Tool OpenGraph.xyz getestet

KERNAUSSAGE: Defekte Social-Vorschauen kosten 50-70 % weniger Klicks bei Shares. Bei einem Product-Hunt-Launch mit erwarteten 5.000 Besuchern hätten defekte Open-Graph-Tags das auf 2.000 reduziert — ein Verlust von 3.000 Besuchern durch eine einzige fehlende Bilddatei. Fünf Minuten Fix vor dem Launch statt Tausender verlorener Besucher danach.

Problem 2: Fehlendes Schema-Markup (HOHE PRIORITÄT)

Was wir intern getestet haben: Geprüft, dass Seiten im Browser korrekt rendern

Was Site Audit fand: Null strukturierte Daten auf jeder Seite

Das Problem: Kein Organization-, WebSite- oder Product-Schema.org-Markup

Warum das wichtig ist:

  • Schema-Markup hilft Google zu verstehen, worum es auf Ihrer Site geht
  • Wettbewerber mit Schema erhalten Rich Snippets (Sternebewertungen, Preise, FAQs) in den Suchergebnissen
  • Ohne strukturierte Daten würden wir in den Suchergebnissen schlechter ranken

Beispiel dafür, was uns fehlte:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Our Product Name",
  "applicationCategory": "BusinessApplication",
  "offers": {
    "@type": "Offer",
    "price": "99",
    "priceCurrency": "USD"
  }
}

Auswirkung, wenn wir ohne dies gelauncht hätten:

  • Keine Rich Snippets bei Google (Wettbewerber würden uns übertrumpfen)
  • Langsamere Indexierung durch Suchmaschinen (Schema hilft Crawlern, den Kontext zu verstehen)
  • Verpasste Chance auf Preis-/Bewertungsanzeige in den SERPs

Die Lösung (30 Minuten):

  1. Organization-Schema zur Homepage hinzugefügt
  2. SoftwareApplication-Schema zur Produktseite hinzugefügt
  3. FAQPage-Schema zum Hilfecenter hinzugefügt
  4. Mit dem Google Rich Results Test validiert

Problem 3: Mobile-Viewport-Bug in iOS Safari (SHOWSTOPPER)

Was wir intern getestet haben: Responsive Design im Chrome-DevTools-Mobile-Simulator geprüft

Was Site Audit fand: Hero-Bereich in iOS Safari abgeschnitten (Test auf echtem Gerät)

Das Problem:

/* Unser CSS */
.hero {
  height: 100vh; /* Funktioniert in Chrome, bricht in iOS Safari */
}

Warum das in iOS bricht:

  • Die untere Navigationsleiste von iOS Safari überlappt den Inhalt
  • 100vh berücksichtigt nicht Safaris dynamische UI (Adressleiste schrumpft/wächst beim Scrollen)
  • Der Hero-CTA-Button war unterhalb des sichtbaren Bereichs versteckt

Auswirkung, wenn wir mit diesem Bug gelauncht hätten:

  • 40 % der mobilen Besucher nutzen iOS Safari (unsere Analytics-Daten)
  • Product-Hunt-Traffic ist zu 60 % mobil (Branchen-Benchmark)
  • Erwartete 3.000 mobile Besucher → 1.200 hätten den kaputten Hero mit versteckter CTA gesehen
  • Geschätzter 30-50 % Conversion-Verlust beim iOS-Traffic

Die Lösung (10 Minuten):

/* Korrigiertes CSS */
.hero {
  min-height: 100vh;
  min-height: -webkit-fill-available; /* iOS-Safari-Fix */
}

Problem 4: 404-Fehler in der Sitemap (MITTLERE PRIORITÄT)

Was wir intern getestet haben: Geprüft, dass sitemap.xml korrekt generiert wurde

Was Site Audit fand: 3 URLs in der Sitemap lieferten 404

Das Problem: Wir hatten Seiten beim Redesign umbenannt, aber vergessen, die Sitemap zu aktualisieren

Warum das wichtig ist:

  • Google crawlt URLs aus Ihrer Sitemap
  • 404s verschwenden Crawl-Budget und signalisieren schlechte Site-Qualität
  • Google könnte das Crawlen zurückstufen, wenn die Sitemap ungenau ist

Auswirkung, wenn wir damit gelauncht hätten:

  • Google hätte am Launch-Tag 3 defekte Seiten gecrawlt
  • Glaubwürdigkeitsverlust (Search Console hätte Sitemap-Fehler angezeigt)
  • Langsamere Indexierung neuer Seiten (verschwendetes Crawl-Budget)

Die Lösung (5 Minuten):

  1. Alte URLs aus der Sitemap entfernt
  2. Geprüft, dass alle Sitemap-URLs Status 200 lieferten
  3. Mit dem XML Sitemap Validator getestet

Problem 5: Barrierefreiheitsmängel (HOHE PRIORITÄT)

Was wir intern getestet haben: Durch die Seiten geklickt, alles funktionierte

Was Site Audit fand (via pa11y): 11 WCAG-2.1-AA-Verstöße

Die Verstöße:

  1. Formularlabels nicht mit Eingabefeldern verknüpft (WCAG 1.3.1)

    <!-- Fehlerhaft -->
<label>Email</label>
<input type="email" />

<!-- Korrigiert -->
<label for="email">Email</label>
<input id="email" type="email" />

  2. Unzureichender Farbkontrast beim CTA-Button (WCAG 1.4.3)

    • Buttontext: #6C63FF auf weißem Hintergrund
    • Kontrastverhältnis: 3,2:1 (Minimum: 4,5:1)
    • Korrigiert: geändert zu #4C3FFF (Verhältnis 4,6:1)

  3. Fehlender Alt-Text beim Hero-Bild (WCAG 1.1.1)

    • Screenreader kündigten „Bild“ ohne Beschreibung an
    • Korrigiert: beschreibenden Alt-Text hinzugefügt

  4. Tastaturnavigation im benutzerdefinierten Dropdown defekt (WCAG 2.1.1)

    • Die Tab-Taste übersprang das Dropdown-Menü (verwendete div statt button)
    • Korrigiert: geändert zu einem semantischen <button>-Element mit korrektem ARIA

Warum das wichtig ist:

  • 15-20 % der Webnutzer haben Bedürfnisse im Bereich Barrierefreiheit (Screenreader, reine Tastaturnavigation, Farbenblindheit)
  • Unzugängliche Formulare = verlorene Conversions
  • Barrierefreiheitsklagen sind real (besonders für B2B-SaaS, das an Unternehmen verkauft)

Auswirkung, wenn wir mit diesen Bugs gelauncht hätten:

  • Screenreader-Nutzer hätten das Signup-Formular nicht abschließen können (Label-/Input-Mismatch)
  • Nutzer mit reiner Tastaturnavigation hätten das Dropdown-Menü nicht bedienen können
  • Farbenblinde Nutzer hätten den CTA-Buttontext nicht lesen können
  • Geschätzter 5-10 % Conversion-Verlust durch Barrierefreiheitsprobleme

Die Lösung (45 Minuten):

  • Formularlabel-Verknüpfungen korrigiert
  • Farbkontrast des Buttons angepasst
  • Alt-Text zu Bildern hinzugefügt
  • Dropdowns per Tastatur zugänglich gemacht

Problem 6: Fehlendes Favicon (NIEDRIGE PRIORITÄT, HOHE WIRKUNG)

Was wir intern getestet haben: Favicon nicht geprüft (angenommen, es funktioniert wie bei der alten Site)

Was Site Audit fand: Favicon lieferte 404, Browser zeigte generisches Symbol

Warum das wichtig ist:

  • Das Favicon erscheint in Browser-Tabs, Lesezeichen und Suchergebnissen
  • Signal für professionellen Feinschliff (fehlendes Favicon wirkt amateurhaft)
  • Markenwiedererkennung (Nutzer mit 20+ offenen Tabs erkennen Sie am Favicon)

Auswirkung, wenn wir ohne dies gelauncht hätten:

  • Generisches Browsersymbol in den Tabs (wirkt unfertig)
  • Geringere wahrgenommene Glaubwürdigkeit auf Product Hunt (Details zählen)
  • Verpasste Branding-Chance in Lesezeichen

Die Lösung (5 Minuten):

  1. Favicon aus dem Logo mit RealFaviconGenerator generiert
  2. Zum /public-Ordner hinzugefügt
  3. Im Browser geprüft

Problem 7: Performance-Regression (MITTLERE PRIORITÄT)

Was wir intern getestet haben: Die Site fühlte sich auf unseren Dev-Rechnern schnell an (MacBook Pros, schnelles Internet)

Was Site Audit fand: Lighthouse-Performance-Score 62/100 (gegenüber 95/100 bei der alten Site)

Das Problem: Unoptimierte Bilder vom Design-Team

Warum das wichtig ist:

  • Google nutzt Core Web Vitals als Ranking-Faktor
  • Langsame Sites haben höhere Absprungraten (53 % der mobilen Nutzer verlassen die Site, wenn sie länger als 3 Sekunden lädt)
  • Product-Hunt-Traffic ist ungeduldig (die Nutzer schauen sich 50+ Produkte an)

Auswirkung, wenn wir damit gelauncht hätten:

  • Höhere Absprungrate (besonders auf Mobilgeräten)
  • Niedrigeres SEO-Ranking durch schlechte Core Web Vitals
  • Schlechter erster Eindruck (langsame Site = Wahrnehmung eines minderwertigen Produkts)

Die Lösung (20 Minuten):

  1. Hero-Bild von PNG (2,4 MB) → WebP (240 KB) konvertiert = 10-mal kleiner
  2. loading="lazy" für Bilder unterhalb des sichtbaren Bereichs hinzugefügt
  3. gzip-Kompression beim Hosting aktiviert
  4. Ergebnis: Lighthouse-Score 62 → 94

Das vermiedene Desaster: Was passiert wäre

Wenn wir ohne den Pre-Launch-Site-Audit gelauncht hätten:

Tag 1: Product-Hunt-Launch

Erwartet: 5.000 Besucher, 150 Signups (3 % Conversion-Rate)

Realität (ohne Fixes):

  • Social Sharing defekt → 40 % weniger Klicks von Twitter/LinkedIn → 3.000 statt 5.000 Besucher
  • iOS-Safari-Bug → 40 % der mobilen Besucher sehen den kaputten Hero → 30 % Conversion-Verlust bei Mobile → 90 statt 150 Signups
  • Barrierefreiheitsmängel → 5-10 % Conversion-Verlust → 81 statt 90 Signups
  • Performance-Regression → 10 % höhere Absprungrate → 73 statt 81 Signups

Tatsächliches Ergebnis ohne Fixes: 73 Signups (statt erwarteter 150)

Verpasste Chance: 77 Signups × 99 $/Monat LTV (12 Monate) = 91.476 $ verlorener ARR

Woche 1: SEO-Auswirkung

Ohne Schema-Markup:

  • Wettbewerber ranken höher mit Rich Snippets
  • Unsere organische CTR: 2,1 % (gegenüber 3,5 % mit Schema)
  • Verlorener organischer Traffic: 40 % weniger Klicks von Google

Monat 1: Reputationsschaden

Ohne Barrierefreiheits-Fixes:

  • Negative Product-Hunt-Kommentare: „Ich kann das Signup-Formular nicht einmal mit meinem Screenreader nutzen“
  • Twitter-Beschwerden über den iOS-Bug: „Hero-Bereich auf dem iPhone abgeschnitten, CTA nicht sichtbar“
  • Verlorene Glaubwürdigkeit während des kritischen Launch-Fensters

Der ROI des Pre-Launch-Audits

Kosten von Site Audit: 50 $

Zeit zum Prüfen und Beheben der Probleme: 2 Stunden (verteilt über das Team)

Vermiedene Verluste:

  • 91.000 $ verlorener ARR durch Conversion-Probleme
  • 40 % organischer CTR-Verlust durch fehlendes Schema
  • Reputationsschaden während des Launch-Fensters

ROI: 50 $ → 91.000 $ Verlust verhindert = 1.820-facher Return

Bonus: Seelenfrieden. Wir haben zuversichtlich gelauncht, statt nach dem Launch hektisch Bugs zu fixen.

KERNAUSSAGE: Ein Pre-Launch-Audit für 50 $ hat 91.000 $ an entgangenem Umsatz durch Conversion-Killer verhindert. Die 7 gefundenen Probleme (defektes Social Sharing, iOS-Viewport-Bug, Barrierefreiheitsmängel, fehlendes Schema, Performance-Regression, Sitemap-Fehler, fehlendes Favicon) waren für Standard-QA unsichtbar, hätten aber unseren Product-Hunt-Launch zerstört. Der ROI ist nicht nur finanziell. Es ist der Unterschied zwischen einem selbstbewussten Launch und einem Day-One-Chaos.

Die Pre-Launch-Audit-Checkliste (So machen Sie es selbst)

Wann Sie das Pre-Launch-Audit durchführen sollten: 24-48 Stunden vor dem Launch (genug Zeit, um Probleme zu beheben, aber nicht so früh, dass Sie danach noch breaking Changes vornehmen)

Was Sie testen sollten:

1. Social Sharing (5 Minuten)

  • Open-Graph-Tags vorhanden und korrekt
  • og:image lädt tatsächlich (URL in den Browser einfügen)
  • Twitter-Card-Tags vorhanden
  • Vorschau mit OpenGraph.xyz testen

Tools: OpenGraph.xyz, Twitter Card Validator, LinkedIn Post Inspector

2. Schema-Markup (5 Minuten)

  • Organization-Schema auf der Homepage
  • Product-/Service-Schema auf Produktseiten
  • Breadcrumb-Schema auf tiefen Seiten
  • FAQPage-Schema auf Hilfe-/FAQ-Seiten

Tools: Google Rich Results Test, Schema.org Validator

3. Mobile-Tests (10 Minuten)

  • Test auf echtem iPhone (iOS Safari)
  • Test auf echtem Android (Chrome)
  • Viewport-Höhen-Probleme prüfen (100vh-Bugs)
  • Prüfen, dass Formulare mit mobilen Tastaturen funktionieren
  • Horizontales Scrollen testen (sollte nicht existieren)

Tools: Echte Geräte (nicht nur der Chrome-DevTools-Simulator), BrowserStack

4. Barrierefreiheit (10 Minuten)

  • Alle Bilder haben Alt-Text
  • Formularlabels sind mit Eingabefeldern verknüpft (for-Attribut)
  • Farbkontrast erfüllt WCAG AA (Minimum 4,5:1)
  • Tastaturnavigation funktioniert (per Tab durch die gesamte Seite)
  • Screenreader-Test (VoiceOver auf dem Mac aktivieren)

Tools: pa11y, axe DevTools, WAVE-Browser-Erweiterung

5. Technisches SEO (10 Minuten)

  • Sitemap.xml generiert und alle URLs liefern Status 200
  • Robots.txt erlaubt Crawling (blockiert nicht versehentlich die Produktion)
  • Meta-Beschreibungen sind einzigartig und unter 160 Zeichen
  • Title-Tags sind einzigartig und unter 60 Zeichen
  • Canonical-Tags verweisen auf die korrekten URLs

Tools: Screaming Frog (kostenlos für <500 URLs), Site Audit

6. Performance (5 Minuten)

  • Bilder optimiert (WebP nutzen, JPGs komprimieren)
  • Lighthouse-Score >90 auf Mobile
  • Keine renderblockierenden Ressourcen
  • Lazy Loading für Bilder unterhalb des sichtbaren Bereichs

Tools: Lighthouse, WebPageTest, Site Audit

7. Formulare & Conversions (5 Minuten)

  • Alle Formulare werden erfolgreich abgeschickt
  • E-Mail-Validierung funktioniert korrekt
  • Danke-Seite lädt nach dem Absenden
  • Formularübermittlungen werden in Analytics erfasst
  • Fehlermeldungen werden korrekt angezeigt

Manueller Test: Jedes Formular auf der Staging-Site ausfüllen

Wie Site Audit das vereinfacht (Die 50-Dollar-Abkürzung)

DIY-Pre-Launch-Audit: 50 Minuten über 7 Kategorien, mehrere Tools

Site-Audit-Pre-Launch-Audit: 5 Minuten, ein Bericht

Was Site Audit automatisch prüft:

  • Social-Sharing-Tags (Open Graph, Twitter Cards)
  • Schema-Markup (validiert Vorhandensein und Korrektheit)
  • Mobile-Viewport-Probleme (Tests auf echtem iOS/Android)
  • Barrierefreiheit (pa11y-Integration, 150+ WCAG-Checks)
  • Technisches SEO (Sitemap, robots.txt, Meta-Tags, Canonicals)
  • Performance (Lighthouse-Audit, Core Web Vitals)
  • Defekte Links und 404s

Das Ergebnis: Priorisierte Checkliste der vor dem Launch zu behebenden Probleme

Unser Pre-Launch-Audit:

  • Site-Audit-Bericht generiert: 5 Minuten
  • Prüfung und Priorisierung: 10 Minuten
  • Probleme beheben: 2 Stunden (verteilt über das Team)
  • Erneuter Test: 5 Minuten

Gesamtzeit: 2,5 Stunden vom Audit bis zur Launch-Bereitschaft

Im Vergleich zum Post-Launch-Chaos:

  • Probleme entdecken: 1-3 Tage (während Nutzer Bugs melden)
  • Notfall-Fixes: 8+ Stunden (hoher Stress, reaktiv)
  • Reputationsschaden: Bereits geschehen (ein missglückter Launch-Tag lässt sich nicht rückgängig machen)

Pre-Launch-Audit vs. Post-Launch-Feuerwehreinsatz

Pre-Launch-Audit-Ansatz

Zeitplan: Site Audit 48 Stunden vor dem Launch durchführen

Denkweise: Proaktiv, ruhig, „lasst uns Probleme finden, bevor Nutzer sie sehen“

Prozess:

  1. Site Audit auf der Staging-Site durchführen
  2. Probleme mit dem Team durchgehen (10 Minuten)
  3. Fixes priorisieren (SHOWSTOPPER → HOCH → MITTEL → NIEDRIG)
  4. Aufgaben zuweisen (aufgeteilt auf Dev-, Design- und Content-Teams)
  5. Probleme über 24-48 Stunden beheben
  6. Site Audit erneut ausführen, um die Fixes zu prüfen
  7. Zuversichtlich launchen

Kosten: 50 $ Site Audit + 2-3 Stunden Teamzeit

Ergebnis: Sauberer Launch, keine Überraschungen

Post-Launch-Feuerwehreinsatz-Ansatz

Zeitplan: Launch → Probleme entdecken → hektisch fixen

Denkweise: Reaktiv, gestresst, „warum haben wir das nicht gesehen?!“

Prozess:

  1. Die Site öffentlich launchen
  2. Nutzer melden erste Probleme:
    • „Eure Site ist auf dem iPhone kaputt“
    • „Ich kann das Signup-Formular mit meinem Screenreader nicht abschicken“
    • „Die Social-Share-Vorschau zeigt ein defektes Bild“
  3. Alles stehen und liegen lassen, um zu untersuchen
  4. Notfall-Fixes in der Produktion (hoher Stress, hohes Risiko)
  5. Hotfixes den ganzen Launch-Tag über deployen
  6. Reputationsschaden bereits geschehen (negative Product-Hunt-Kommentare, Beschwerden in sozialen Medien)

Kosten: 8+ Stunden Teamzeit + Opportunitätskosten + Reputationsschaden

Ergebnis: Stressiger Launch, verpasste Conversions, Glaubwürdigkeitsverlust

KERNAUSSAGE: Pre-Launch-Audits sind proaktiv, ruhig und verhindern Desaster. Post-Launch-Feuerwehreinsätze sind reaktiv, stressig und reparieren Schaden, nachdem er entstanden ist. Der Kostenunterschied: 50 $ + 2 Stunden vor dem Launch gegenüber 8+ Stunden Notfall-Fixes + verlorenen Conversions + Reputationsschaden danach. Technische Audits sollten stattfinden, bevor Nutzer ankommen, nicht danach.

Praxisbeispiele für Pre-Launch-Audits

Beispiel 1: SaaS-Startup-Redesign

48 Stunden vor dem Launch entdeckt:

  • Preisseite lieferte 404 (die wichtigste Conversion-Seite!)
  • Signup-Formular fehlte ein erforderliches CSRF-Token (Sicherheitslücke)
  • Blogbilder luden nicht (defekte CDN-Konfiguration)

Vermieden: Hektik am Launch-Tag, null Signups wegen kaputtem Formular, Sicherheitsrisiko

Beispiel 2: E-Commerce-Produktlaunch

24 Stunden vor dem Launch entdeckt:

  • Produktbilder nicht optimiert (je 4-5 MB)
  • Mobiler Checkout-Flow in iOS Safari defekt
  • Fehlendes Produkt-Schema-Markup (keine Rich Snippets)

Vermieden: Langsame Site → hohe Absprungrate, verlorene Mobile-Verkäufe, schlechte SEO-Sichtbarkeit

Beispiel 3: Content-Marketing-Site

72 Stunden vor dem Launch entdeckt:

  • Social-Vorschauen nutzten ein Platzhalterbild („Durch echtes Bild ersetzen“)
  • Blogbeitrags-URLs nicht in der Sitemap
  • Newsletter-Anmeldeformular nicht mit dem E-Mail-Anbieter verbunden

Vermieden: Peinliche Social Shares, schlechte Indexierung, null E-Mail-Erfassungen

Wann Pre-Launch-Audits sinnvoll sind

Idealer Zeitpunkt: 48 Stunden vor dem Launch

Warum 48 Stunden:

  • Genug Zeit, um Showstopper-Probleme zu beheben
  • Nicht so früh, dass Sie nach dem Audit noch breaking Changes vornehmen
  • Das Team hat noch Kontext zu den jüngsten Code-Änderungen
  • Stressarmer Zeitplan (keine Panik am selben Tag)

Führen Sie Audits auch durch für:

Größere Redesigns – Regressionen passieren bei visuellen Überarbeitungen

Plattformmigrationen – Beim Umzug von WordPress → Webflow → Custom geht etwas kaputt

Neue Funktionen – Checkout-Flow, Preisseite, Produktlaunch

Vor Marketingkampagnen – Führen Sie keinen bezahlten Traffic auf eine kaputte Site

Nach dem Deployment – Prüfen, ob Produktion und Staging übereinstimmen

Fazit

Unser internes QA: Site lädt, Seiten sehen korrekt aus, Formulare funktionieren

Site-Audit-Pre-Launch-Audit: 7 kritische Probleme, die unseren Launch ruiniert hätten

Die Lücke: Visuelles QA findet offensichtliche Bugs. Technische Audits finden unsichtbare Conversion-Killer.

Ein einziges Site Audit für 50 $ fand Probleme, die uns 91.000 $ verlorenen ARR gekostet und unserer Reputation während des Launches geschadet hätten.

Ihre Staging-Site sieht wahrscheinlich perfekt aus. Aber ist sie technisch bereit?

Was Sie als Nächstes tun sollten

Option 1: DIY-Pre-Launch-Checkliste (Kostenlos, 50+ Minuten)

Nutzen Sie die obige Checkliste, um manuell zu testen:

  • Social-Sharing-Tags
  • Schema-Markup
  • Mobilgeräte
  • Barrierefreiheit
  • Technisches SEO
  • Performance
  • Formulare

Zeit: 50+ Minuten über mehrere Tools

Kosten: Kostenlos (Ihre Zeit)

Option 2: Site Audit auf Ihrer Staging-Site ausführen (50 $, 5 Minuten)

Was Sie erhalten:

  • Automatisierte Checks über alle oben genannten 7 Kategorien
  • Tests auf echten Geräten (iOS Safari, Android Chrome)
  • Pa11y-Barrierefreiheits-Audit (150+ WCAG-Checks)
  • Lighthouse-Performance-Audit
  • Priorisierte Fix-Liste

So funktioniert es:

  1. Geben Sie die URL Ihrer Staging-Site ein
  2. Site Audit führt einen automatisierten Audit durch (~5 Minuten)
  3. Erhalten Sie einen umfassenden Bericht mit priorisierten Problemen
  4. Beheben Sie die Probleme vor dem Launch
  5. Erneut ausführen, um zu prüfen

Zeit: 5 Minuten für das Audit, 2-3 Stunden für die Fixes

Kosten: 50 $

Führen Sie ein Pre-Launch-Site-Audit durch

Zusammenfassung der Pre-Launch-Checkliste

48 Stunden vor dem Launch:

  • Site Audit auf der Staging-Site durchführen
  • Probleme mit dem Team durchgehen
  • Priorisieren: SHOWSTOPPER → HOCH → MITTEL → NIEDRIG
  • Fixes im Team zuweisen

24 Stunden vor dem Launch:

  • Prüfen, dass alle SHOWSTOPPER-Probleme behoben sind
  • Prüfen, dass alle Probleme mit HOHER Priorität behoben sind
  • Site Audit erneut ausführen, um die Fixes zu bestätigen

Am Launch-Tag:

  • Abschließender Smoke-Test auf der Produktion
  • Analytics auf unerwartete Probleme überwachen
  • Zuversichtlich launchen

Ihre Site sieht bereit aus. Aber haben Sie den technischen Audit durchgeführt?

Ein Site-Audit-Bericht für 50 $ könnte der Unterschied zwischen einem reibungslosen Launch und einem 91.000-Dollar-Desaster sein.

Weiterführende Lektüre

Bereit, Ihre Staging-Site zu prüfen? Führen Sie ein Site Audit durch (50 $) und finden Sie Probleme, bevor Ihre Nutzer es tun. Visuelles QA reicht nicht aus. Technische Audits retten Launches.

Bauen wir Ihre Website neu auf

Erhalten Sie einen kostenlosen Neuaufbau zur Freigabe, bevor Ihre Domain umzieht.

Wie zufrieden sind Sie mit Ihrer aktuellen Website?

Kostenlose Vorschau. Die meisten Neuaufbauten sind innerhalb von 24 Stunden fertig. Sie zahlen erst nach Ihrer Freigabe.

Alle Pläne ansehen

Weiterlesen

SEO

Crawl-Budget: Warum Google nicht alle Seiten indexiert

Erfahren Sie, was Crawl-Budget ist, warum es für große Websites wichtig ist und wie Sie es optimieren. Mit praktischen Tipps zur schnelleren Indexierung.

12. Juni 2026 · 9 Min. LesezeitSEO

Ihr Google Lighthouse Score lügt: 5 kritische Fehler, die er übersah

Perfekter 100er Lighthouse Score. Dann lief Site Audit. 5 kritische SEO-Probleme, die Lighthouse übersah, kosteten 30 % organischen Traffic.

15. Mai 2026 · 10 Min. LesezeitSEO

Was Sie nach Ihrem Site Audit zuerst beheben sollten

Ihr Site-Audit-Bericht enthält Scores, Tabellen und ein Glossar. So lesen Sie die Prioritätenliste und wählen die richtige Maßnahme für den Montagmorgen.

27. April 2026 · 4 Min. Lesezeit

Alle Beiträge ansehen →