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.

Bereit für den nächsten Schritt?

Scout recherchiert Ihre Marke in ~15 Minuten.

DEMO TESTENAlle 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 →