Pre-launch review.
A targeted security review of a WordPress site about to go live.
Nimmt Anfragen an
Warum das eine eigene Leistung ist
Pre-launch checks.
A pre-launch site has a different threat profile than a mature one. The development team has been moving fast. Staging credentials are everywhere. The "I'll clean up after launch" list is long. Admin accounts that should have been removed weeks ago are still there.
Wir haben viele Seiten im ersten Monat kompromittiert gesehen — nicht durch ausgefeilte Angreifer, sondern durch übriggebliebene Artefakte des Build-Prozesses. Diese Prüfung ist darauf ausgelegt, sie zu finden, bevor die Seite öffentlich indexiert wird.
Wer das bucht
- Agenturen, die ein Projekt an einen Kunden übergeben und vorher ein zweites Augenpaar wollen.
- Inhouse-Teams kurz vor der Migration von Staging auf Produktion.
- Kunden, die eine fertige Seite übernehmen und prüfen wollen, was sie erben.
- Alle, die von Squarespace, Wix oder einem anderen CMS auf WordPress wechseln.
Die Launch-Checkliste
Was wir erheben
Dev / agency / contractor accounts that shouldn't ship to production. The classic "admin / password123" still set up for testing.
Altes staging.example.com oder example.com.staging.host noch öffentlich, indexiert und mit einer ungepatchten Kopie derselben Seite.
WP_DEBUG ist an. /wp-admin/install.php erreichbar. /debug.php oder ähnliche Einmal-Skripte versehentlich committed.
.env, .git, README.md, Deploy-Logs oder Backup-Dateien (sql, zip) über eine URL erreichbar.
Sample posts, Hello World, the default "admin" user, Akismet placeholder, sample plugin pages still public.
Kontaktformulare ohne Anti-Spam, Login-Seiten ohne Brute-Force-Schutz, Kommentar-Formulare ohne CAPTCHA oder Hashcash.
Plugins installiert-aber-deaktiviert (noch auf der Platte, weiter angreifbar). Trial-Versionen, Beta-Kanäle, Plugins aus dubiosen Quellen.
File-Edit-Lock, XML-RPC, REST-API-User-Enumeration, Salts, sichere Cookie-Flags, HSTS, Security-Header — alles gegen aktuellen Best Practice geprüft.
"Discourage search engines" left on, or off when it shouldn't be. robots.txt, sitemap.xml, canonical URLs all sanity-checked.
Timing
Wann buchen.
Optimal
Zwei Wochen vor dem Launch
Reichlich Zeit, um Befunde ohne Launch-Verzögerung zu beheben. Wir können vor dem Go-Live einen Nachtest machen.
Gut
Eine Woche vorher
Noch genug Raum für Fixes. Nachtest hängt von der Größe der Befunde ab.
Knapp
Innerhalb 48 Stunden
Express-Slot — möglich, aber anders bepreist. Lohnt sich trotzdem: Ein einziger kritischer Befund spart einen weit schlimmeren Vorfall eine Woche später.
Häufig gefragt
Häufige Fragen.
Ist das ein vollständiges Sicherheitsaudit?
No — it's focused. A full audit covers more ground, including process and configuration depth. The pre-launch review targets the specific failure modes of a new-site launch.
Macht ihr auch die Fixes?
Befunde sind so geschrieben, dass dein Entwickler oder deine Agentur sie umsetzen kann. Für Agentur-Kunden können wir kleine Fixes auf Wunsch auch selbst einspielen — separat zum Review angeboten.
Was, wenn ihr nichts Ernstes findet?
Great. The report still documents what I checked, with a "ready to launch" verdict. Useful for client handover and for the agency's own records.
Können wir das jährlich machen?
Eher nicht — sobald die Seite live ist, ändert sich das Bedrohungsprofil. Nach dem Launch ist die richtige Taktung ein Sicherheitsaudit pro Jahr plus ein Pentest nach jeder größeren Änderung.
E-Mail [email protected] or use the contact form.