Pre-launch review.
A targeted security review of a WordPress site about to go live.
Aceptando encargos
Por qué es un servicio aparte
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.
Hemos visto muchos sitios comprometidos en su primer mes — no por atacantes sofisticados, sino por artefactos sobrantes del proceso de build. Esta revisión está diseñada para detectarlos antes de que el sitio sea indexado públicamente.
Quién contrata esto
- Agencias que entregan un proyecto a un cliente y quieren un segundo par de ojos antes.
- Equipos in-house a punto de migrar desde un entorno de staging a producción.
- Clientes que reciben un sitio terminado y quieren verificar qué están heredando.
- Cualquiera que esté replataformando desde Squarespace, Wix u otro CMS a WordPress.
La checklist de lanzamiento
Qué recogemos
Dev / agency / contractor accounts that shouldn't ship to production. The classic "admin / password123" still set up for testing.
Viejos staging.example.com o example.com.staging.host todavía públicos, indexados y sirviendo una copia sin parches del mismo sitio.
WP_DEBUG dejado encendido. /wp-admin/install.php accesible. /debug.php o similares one-offs comiteados por accidente.
.env, .git, README.md, logs de despliegue o archivos de backup (sql, zip) accesibles vía URL.
Sample posts, Hello World, the default "admin" user, Akismet placeholder, sample plugin pages still public.
Formularios de contacto sin anti-spam, páginas de login sin protección anti-fuerza-bruta, formularios de comentarios sin CAPTCHA ni hashcash.
Plugins instalados pero desactivados (todavía en disco, todavía atacables). Versiones trial, canales beta, plugins de fuentes turbias.
Bloqueo de edición de archivos, XML-RPC, enumeración de usuarios vía REST API, salts, flags seguros en cookies, HSTS, cabeceras de seguridad — todo verificado contra las buenas prácticas actuales.
"Discourage search engines" left on, or off when it shouldn't be. robots.txt, sitemap.xml, canonical URLs all sanity-checked.
Tiempos
Cuándo reservar.
Lo mejor
Dos semanas antes del lanzamiento
Tiempo de sobra para arreglar hallazgos sin retrasar el lanzamiento. Podemos hacer una ronda de re-test antes del go-live.
Bien
Una semana antes
Aún hay margen para arreglos. El re-test depende de cuán grandes sean los hallazgos.
Justo
Dentro de 48 horas
Slot urgente — posible pero con precio distinto. Vale la pena hacerlo igualmente: detectar un problema crítico evita un incidente mucho peor una semana después.
Preguntas frecuentes
Preguntas frecuentes.
¿Esto es una auditoría de seguridad completa?
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.
¿Podéis hacer también los arreglos?
Los hallazgos se redactan para que tu desarrollador o agencia pueda actuar sobre ellos. Para clientes de agencia, también podemos aplicar nosotros mismos pequeños arreglos si lo prefieres — cotizados aparte de la revisión.
¿Y si no encontráis nada serio?
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.
¿Podemos hacer esto como algo anual?
La verdad que no — una vez lanzado, el perfil de amenaza cambia. Tras el lanzamiento, la cadencia correcta es una auditoría de seguridad al año, más un pentest después de cualquier cambio importante.
Correo [email protected] or use the contact form.