Snippet nur in Staging ausliefern – die drei üblichen Wege
Der einfachste Weg ist ein Environment-Flag im Build: In React, Next.js, Nuxt oder Astro rendert das Snippet nur, wenn die Umgebungsvariable auf „staging“ oder „preview“ steht. In klassischen CMS setzt du stattdessen eine Bedingung auf den Hostnamen (`staging.example.com`) oder trägst das Snippet ausschliesslich in der Staging-Instanz ein, die ohnehin eine eigene Konfiguration hat. Bei Vercel- oder Netlify-Previews genügt die Auswertung der jeweiligen Kontext-Variable, dann bekommt jede Deploy-Preview automatisch das Snippet und Produktion nicht.
Basic Auth: was Kunden bekommen und was nicht
Weil das Snippet in der geschützten Umgebung selbst ausgeliefert wird, gelten die bestehenden Zugangsbeschränkungen unverändert. Für Basic Auth heisst das: Der Kunde braucht Benutzername und Passwort der Staging-Seite, sonst sieht er gar nichts. Gib diese Daten deshalb einmal projektbezogen heraus – und nicht deine CMS-Zugänge. Wichtig: Basic Auth verhindert nicht, dass Suchmaschinen den Hostnamen kennen; ergänze zusätzlich `X-Robots-Tag: noindex` auf der Staging-Domain.
VPN, IP-Sperren und externe Kunden
IP-Allowlists und VPN funktionieren für interne Teams gut, blockieren aber genau die Personen, deren Freigabe du brauchst. Praktikabler ist eine passwortgeschützte Preview-Domain, die von aussen erreichbar ist. Wenn der Kunde zwingend über VPN muss, plane den Abnahmetermin als begleiteten Durchlauf – sonst verschiebt sich die Freigabe an der Netzwerkhürde statt an inhaltlichen Punkten.
Staging vom Index fernhalten
Feedback-Umgebungen dürfen nicht ranken. Setze auf der Staging-Domain `noindex` per HTTP-Header, halte `robots.txt` restriktiv und verzichte auf Canonicals, die auf Staging zeigen. Achte auch darauf, dass Sitemaps der Staging-Instanz nicht öffentlich erreichbar sind – doppelt ausgelieferte Inhalte auf zwei Hosts sind eine der häufigsten selbstverschuldeten SEO-Baustellen bei Relaunches.
Sauber getrennte Umgebungen
Lege pro Umgebung ein eigenes Projekt an (Staging, Live). So bleiben Abnahmefeedback und Live-Meldungen getrennt und die Status-Listen bleiben aussagekräftig. Beim Go-live schliesst du das Staging-Projekt ab, statt beide Datenbestände zu mischen – die Historie der Abnahme bleibt damit als Nachweis erhalten.
Notizen über Deploys hinweg
Notizen hängen an URL und Element. Bleiben Pfad und Markup stabil, findest du sie nach einem Deploy an derselben Stelle wieder. Ändert sich die Struktur grundlegend – neues Template, andere Klassennamen –, bleibt die Notiz mit Screenshot-Ausschnitt und URL erhalten, die Verankerung am Element kann aber verloren gehen. Für grössere Umbauten lohnt es, offene Punkte vorher abzuarbeiten.
Vor dem Go-live: Feedback in Aufgaben übergeben
Kurz vor dem Launch zählt die Priorisierung: offene Punkte pro Seite, getrennt nach „blockiert Launch“ und „nach Launch“. Jede Notiz lässt sich als Aufgabe nach Trello, Asana, Jira oder GitHub übergeben – mit URL, Element und Screenshot, damit im Sprint niemand rätselt, was gemeint war.
