En esta página
Un sitio WordPress de negocio puede verse terminado en staging y aun así fallar el día uno. Los formularios no llegan a ningún lado, los certificados caducan a mitad de campaña, los backups nunca tienen una prueba de restauración y nadie sabe quién es dueño del login de hosting cuando algo se rompe a las 9pm.
El lanzamiento es una puerta de operaciones. El diseño y el copy importan, pero el go-live trata de evidencia de que el sitio puede mantenerse en línea, recibir leads y mantenerse sin conjeturas heroicas. Esta guía recorre una checklist de lanzamiento de WordPress para sitios de negocio. Cubre ownership previa al vuelo, hosting, seguridad, plugins, backups, rendimiento, setup ligero de SEO y medición, traspaso y las primeras dos semanas después de que el DNS cambia.
Owners previos al vuelo, acceso y la decisión de go-live
Antes de tocar el DNS, anota quién es dueño de cada capa. Los lanzamientos de negocio se estancan cuando el acceso vive en el inbox de un freelancer y la facturación está en una tarjeta personal que nadie encuentra tras cerrar el proyecto.
Nombra owners para registrador de dominio, DNS, panel de hosting, admin de WordPress, email (si el correo vive en el mismo dominio), analytics, Search Console y cuentas de pago o CRM. Prefiere emails de la empresa y bóvedas compartidas de contraseñas frente a reenvíos de Gmail personal. Si una agencia construyó el sitio, decide por escrito si mantienen acceso admin tras el lanzamiento, y a qué nivel de permiso.
Decide qué significa «done» antes de dar el switch. Una barra workable de go-live para un negocio de servicios suele incluir HTTPS funcionando en el hostname en vivo, homepage y páginas clave de dinero cargando sin fatales de PHP, formulario de contacto entregando a un inbox o CRM monitoreado, backups habilitados con al menos un drill exitoso de restauración, y ninguna URL de staging ni plugin de «coming soon» activos en producción.
Notas adhesivas para owners de dominio, DNS, hosting, admin de WordPress y analytics antes del cutover de DNS.
Tip: Pon la decisión de go-live en una nota corta compartida. Si marketing quiere anunciar el martes y ops aún no tiene prueba de restauración, el martes es el día equivocado.
Hosting y preparación del entorno
El hosting es donde empiezan muchas historias de «WordPress es lento / WordPress fue hackeado». Para un sitio de negocio, elige un plan que coincida con el tráfico y los hábitos de actualización. La caja shared más barata que instala WordPress en un clic rara vez es ese plan.
Confirma que las versiones de PHP y MySQL estén dentro de lo que soportan los requisitos actuales de WordPress. Activa actualizaciones automáticas de seguridad del core de WordPress si tu host o flujo de gestión las soporta con seguridad, y mantén una ruta para revertir si una actualización rompe un tema custom. Fuerza HTTPS en la capa del host o reverse-proxy para que las advertencias de mixed-content no aparezcan solo después de compartir la URL en Slack.
Verifica que el sitio de producción use el dominio en vivo en WordPress Settings → General (WordPress Address y Site Address). Las URLs de staging hardcodeadas en la base de datos son una sorpresa clásica post-migración. Haz search-replace con cuidado si migraste; un find-replace ciego puede romper opciones serializadas del tema.
Disco, inodes y envío de email importan más que las claims de brochure de «unlimited». Los formularios que dependen de PHP mail() a menudo caen en spam o fallan en silencio. Prefiere SMTP autenticado vía un proveedor transaccional o tu suite de workspace, y envía una prueba real desde el dominio en vivo.
| Check | Pass se ve así | Fail se ve así |
|---|---|---|
| PHP / DB | Versiones soportadas según docs de WordPress | PHP end-of-life «porque el tema funciona» |
| HTTPS | Cert válido en el hostname en vivo | Advertencias del navegador o HTTP aún canónico |
| URLs | Site Address coincide con producción | Subdominio de staging aún en settings |
| Prueba SMTP llega al inbox | El form «envía» pero no llega nada | |
| Recursos | Margen para media y picos | Disco lleno tras una semana de uploads |
Preparación de hosting como HTTPS, PHP soportado, salud de la base de datos y mail que realmente entrega.
Si estás reconstruyendo en lugar de lanzar una property nueva, trata la migración como su propio proyecto con redirecciones y una ventana de freeze. Un engagement limpio de setup de WordPress suele cerrar las elecciones de entorno antes del pulido de diseño para que la semana de lanzamiento no se gaste discutiendo hosts.
Baseline de seguridad antes de que la URL pública esté en vivo
No necesitas una fortaleza el día uno. Sí necesitas defaults que detengan los ataques aburridos que golpean cada wp-login.php expuesto.
Usa contraseñas admin únicas y fuertes y deja de compartir una sola cuenta «admin» en todo el equipo. Crea usuarios con roles apropiados (administrator, editor, author) y elimina cuentas no usadas de freelancers. Prefiere un username de admin custom y mantén la cuenta default admin eliminada si alguna vez existió.
Mantén WordPress core, temas y plugins actualizados antes del lanzamiento. Esperar hasta «después de la campaña» es cómo los CVEs conocidos encuentran un homepage público. Elimina temas y plugins no usados en lugar de dejarlos desactivados; el código desactivado sigue en disco. Limita intentos de login o pon el login detrás de protección a nivel de host si tu proveedor la ofrece. Confirma que los permisos de archivos sean sensatos para el modelo de tu host, y que wp-config.php no sea world-readable.
Activa un Web Application Firewall solo si entiendes qué bloquea. Las protecciones antibot mal configuradas pueden bloquear crawlers legítimos y tu propio monitoring. La autenticación de dos factores para cuentas administrator vale la fricción en cualquier sitio que reciba leads o pagos.
Advertencia: No dejes
WP_DEBUGhabilitado en producción. La salida de debug puede filtrar paths e internos de plugins al HTML o logs que los visitantes nunca deberían ver.
Seguridad del día uno como cuentas fuertes, actualizaciones, fricción de login y archivos cerrados.
Revisa la guía de hardening de WordPress para tu stack, luego aplica solo lo que puedas mantener. Una «suite de seguridad» a medias con reglas de firewall conflictivas es peor que una checklist corta y con dueño.
Disciplina de plugins en el lanzamiento
Los plugins son cómo WordPress se vuelve una herramienta de negocio. También son cómo los sitios acumulan conflicto, peso y código abandonado.
Inventaría cada plugin activo y escribe una frase de por qué existe. Fusiona duplicados (dos plugins SEO, dos de formularios, dos capas de caché). Prefiere plugins bien mantenidos con un cadence claro de actualización frente a clones «free forever» sin ruta de soporte. Los page builders pueden estar bien para flexibilidad editorial; se vuelven un pasivo cuando cada landing page es un snowflake único sin plantillas compartidas.
Desactiva o elimina importers de demo content, helpers de migración y herramientas de «coming soon» de producción. Cualquier cosa que pueda reescribir URLs o hacer flush de rewrites debe usarse a propósito y luego quitarse o cerrarse.
| Clase de plugin | Regla de lanzamiento |
|---|---|
| Forms | Un stack primario de formularios; prueba cada destino |
| SEO | Un plugin o framework SEO; sin sitemaps que compitan |
| Cache / optimize | Un enfoque de caché alineado con el host |
| Security | Un stack coherente; evita firewalls solapados |
| Backup | Independiente del tema; restauración testeada |
| Builder | Plantillas compartidas; sin páginas demo abandonadas |
Plugins activos ordenados en keep, merge y remove antes del go-live.
Error frecuente: Instalar un plugin de «performance» que minifica CSS mientras el host ya minifica y un CDN ya optimiza imágenes. Elige un dueño para la caché y documentalo.
Backups que realmente puedas restaurar
Un backup que nunca has restaurado es un archivo de esperanza. Los sitios de negocio necesitan un schedule, una copia offsite y un drill de restauración antes de que el spend de marketing golpee la URL.
Decide qué respaldas (archivos, base de datos o ambos), con qué frecuencia y dónde viven las copias. Los snapshots del hosting son útiles; no deberían ser la única copia si una disputa de billing o un compromiso de cuenta puede borrar el panel. Mantén al menos un backup reciente fuera del host primario.
Ejecuta una restauración en un entorno de staging descartable antes del lanzamiento. Cronométrala. Anota qué credenciales y trucos de DNS necesitaste. Si la restauración toma medio día y SSH no documentado, corrige ese proceso mientras el sitio aún está en calma.
Tras el lanzamiento, confirma que los backups sigan corriendo en el hostname en vivo y que el cron o el scheduler del host no hayan quedado apuntando a staging. Documenta quién recibe el email de fallo cuando un job de backup muere.
Archivos y base de datos fluyendo a almacenamiento offsite, con un paso explícito de prueba de restauración.
Buena práctica: Agenda el drill de restauración en el calendario la misma semana del cutover de DNS. Trata un drill fallido como un bloqueador de lanzamiento.
Rendimiento antes de comprar tráfico
Las primeras cargas lentas queman ads pagados y demos de ventas. No necesitas un score perfecto de Lighthouse para lanzar un sitio brochure, pero sí debes saber cómo se sienten las plantillas de dinero en un teléfono mid-range en wifi ordinario.
Mide el homepage, una página clave de servicio o producto y la ruta de contacto o checkout. Comprime y redimensiona imágenes hero antes del upload; no dependas de un plugin para arreglar un PNG de 4MB. Diferí scripts no críticos donde tu tema lo permita. Evita apilar tres tags de analytics, un widget de chat, una herramienta de heatmap y un popup el día uno a menos que cada uno tenga un owner y un trabajo de medición.
Si usas un CDN, confirma que el dominio en vivo esté correctamente adjunto y que alguien del equipo pueda ejecutar un cache purge. Haz purge tras el deploy para que los editores no persigan «lo actualicé pero el sitio aún muestra el logo viejo» toda una tarde.
Los plugins de caché y la page cache a nivel de host no deben pelearse. Documenta la ruta única para «necesito ver una página fresca ahora».
Rendimiento de lanzamiento como peso de imagen, una ruta de caché y un smoke test en tamaño de teléfono.
Los Core Web Vitals y problemas más profundos de crawl pueden esperar un pase enfocado después de que el sitio esté estable. Si la búsqueda orgánica ya es un canal de crecimiento, agenda una revisión técnica por separado en lugar de meter una auditoría completa en la noche de lanzamiento.
Básicos de SEO que pertenecen al go-live
El SEO de lanzamiento trata de no dispararte en el pie. No es un sustituto del trabajo continuo de contenido y técnico.
Confirma que el sitio sea indexable en producción (Settings → Reading no está desalentando a los motores de búsqueda). Quita password protection y basic-auth del hostname público. Envía un XML sitemap limpio en Google Search Console una vez verificado el dominio en vivo. Define una forma preferida de URL (www o non-www, política de barra final) y haz las redirecciones consistentes.
Cada página de dinero necesita un title y meta description únicos que un humano haría clic. El H1 del homepage debe nombrar la oferta del negocio. Deja «Welcome» para la intranet. Añade schema de Organization o LocalBusiness solo si los datos son precisos y se mantienen; un NAP incorrecto en JSON-LD crea trabajo de limpieza después.
Si migraste de un sitio viejo, envía un mapa de redirecciones para URLs de alto tráfico y alta conversión antes de anunciar. Soft-launching sin redirecciones es cómo mueren rankings y bookmarks la misma semana.
Producción indexable, envío de sitemap, titles y redirecciones como el piso de SEO de lanzamiento.
Mantén esta sección delgada a propósito. El trabajo profundo de crawl, canonical y Core Web Vitals merece su propio pase una vez que la checklist de ops esté en verde.
Formularios, analytics y plomería de conversión
Un sitio de negocio que no puede tomar un lead sigue siendo un borrador. Prueba cada formulario público en el dominio en vivo con un envío real. Confirma el estado de thank-you, el email de notificación, el destino de CRM o spreadsheet y el filtrado de spam que no descarte clientes en silencio.
Revisa las expectativas de privacy de tu región. Los cookie banners y herramientas de consentimiento deben coincidir con cómo cargas realmente analytics y píxeles de ads. Una UX de consentimiento rota que bloquea el formulario es un defecto de lanzamiento.
Instala analytics con un property ID documentado y una lista de acceso. Marca la fecha de lanzamiento en tus notas para que el reporting posterior tenga un before/after limpio. Si usas Google Analytics o una alternativa privacy-first, verifica hits en tiempo real desde una sesión de incógnito en producción. La verificación de Search Console también pertenece aquí, para que los problemas de cobertura aparezcan temprano.
Los widgets de chat, schedulers y botones de pago reciben el mismo tratamiento que los formularios. Un embed de Calendly fallido en la página «Book a call» costará más que una semana de tweaks de copy.
Ruta de leads del formulario al inbox o CRM, con analytics y Search Console adjuntos.
Idea clave: La plomería de conversión es parte del QA de lanzamiento. La revisión de diseño no reemplaza un lead de prueba registrado con timestamp.
Traspaso limpio tras el go-live
El traspaso es donde los proyectos freelance y de agencia fallan en silencio. El sitio está en vivo, las facturas pagadas y el conocimiento institucional se va con quien lo construyó.
Entrega un paquete corto de operaciones. Incluye ubicaciones de login de hosting y DNS (no contraseñas por email), URL del admin de WordPress, cómo crear una página nueva desde la plantilla estándar, cómo hacer purge de caché, schedule de backup y contacto de restauración, lista de plugins con notas de propósito, y a quién llamar para emergencias en los primeros 30 días.
Entrena al editor en el workflow real que usará semanalmente. Un Loom de 40 minutos que muestre «añadir una página de servicio» y «actualizar el hero del homepage» supera un curso genérico de WordPress. Elimina cuentas admin temporales cuando termine el training.
Alinea expectativas comerciales. Actualizaciones continuas, monitoreo de seguridad y ediciones pequeñas de contenido son mantenimiento. Nuevas plantillas, rediseños de checkout y migraciones son proyectos. Si necesitas cuidado retenido tras el lanzamiento, dilo explícitamente en lugar de esperar que «una mirada rápida» cubra la semana de ransomware.
Paquete de operaciones, walkthrough del editor y una ventana de soporte definida tras el cutover.
Escenario trabajado para una firma de servicios regionales
Imagina un sitio de 12 páginas para una firma regional de servicios profesionales. Staging se veía pulido. La semana de lanzamiento aún necesitaba una checklist con dientes.
El lunes llenó la hoja de ownership. Dominio y DNS quedaron con el contratista de IT de la firma. Hosting y admin de WordPress con el partner web. Analytics usó una cuenta Google de la empresa en lugar del login personal del diseñador.
El martes confirmó hosting en PHP actual, emitió el certificado HTTPS para apex y www, y conectó SMTP al workspace de la firma. Un search-replace corrigió tres enlaces internos que aún apuntaban al subdominio de staging.
El pase de seguridad del miércoles eliminó dos plugins demo no usados del builder, rotó la contraseña admin compartida a cuentas individuales de editor y habilitó 2FA para administrators. El plugin de backup escribió a almacenamiento offsite, y una restauración en un subdominio descartable tuvo éxito en menos de una hora.
El jueves manejó el pase de imágenes del hero del homepage y fotos del equipo, documentó una ruta de caché y probó formularios tanto al inbox del office manager como al CRM. Una regla de notificación había quedado en la dirección de staging y habría fallado en silencio.
El viernes por la mañana verificó Search Console, envió el sitemap y desmarcó «discourage search engines». Se enviaron redirecciones para cinco URLs viejas de servicio del sitio brochure anterior. Soft launch solo para el staff.
El viernes por la tarde pagó el drop anterior de TTL de DNS. Cutover, purge de CDN, retest de formularios en el hostname público. La nota de traspaso salió con el Loom del editor y una ventana de hypercare de dos semanas para fixes de break/fix.
Esa secuencia es ordinaria. Lo que la hizo segura fue evidencia en cada puerta. Un tema más fancy no habría sustituido esos checks.
Una semana de lanzamiento de cinco días con puertas de ownership, hosting, seguridad, QA y cutover.
Primeras dos semanas tras el lanzamiento
El post-lanzamiento es cuando usuarios reales y bots estresan las asunciones. Mira gráficos de recursos de hosting, logs de error y fallos de notificación de formularios a diario la primera semana. Confirma que los backups sigan teniendo éxito en el sitio en vivo. Vuelve a chequear Search Console por mensajes de cobertura o seguridad una vez que fluyan los datos.
Espera ediciones de contenido. Los editores pegarán desde Docs, subirán imágenes sobredimensionadas e instalarán «solo un plugin» si los permisos lo permiten. Mantén un change log corto para la ventana de hypercare para poder correlacionar «instalamos X» con «los formularios se rompieron el martes».
Si las campañas pagadas empiezan de inmediato, alinea convenciones UTM y el comportamiento de caché de landing pages antes de que escale el spend. Una página de thank-you cacheada que aún muestra el formulario confundirá tanto a usuarios como a la atribución.
Loop de hypercare vigilando logs, backups, formularios y Search Console tras el go-live.
Planifica el siguiente hito de ops mientras el lanzamiento está fresco. Actualizaciones mensuales, un drill trimestral de restauración y un pase más profundo de SEO o conversión una vez que los patrones de tráfico sean reales pertenecen al calendario. La completitud del lanzamiento y el crecimiento a largo plazo son trabajos distintos.
Preguntas frecuentes
¿Cuándo debemos cambiar el DNS relativo a freezes de contenido?
Congela cambios estructurales y de plugins 24-48 horas antes del cutover cuando puedas. Tweaks de copy en páginas existentes suelen estar bien. Cambios grandes de tema o builder a mitad del cutover hacen difícil distinguir lag de DNS de una regresión real.
¿Necesitamos un sitio de staging para siempre?
Mantén staging si actualizas plugins mensualmente o envías cambios no triviales de tema. Sitios brochure pequeños que rara vez cambian a veces pueden vivir con staging a demanda a nivel de host. La regla es simple. Si no puedes permitirte un homepage roto por un día, mantén un lugar para probar actualizaciones.
¿Está bien un page builder para un lanzamiento de negocio?
Sí cuando el equipo editará de verdad dentro de plantillas compartidas y alguien es dueño de las actualizaciones. Se vuelve caro cuando cada página es un one-off y el builder, el tema y los plugins «helper» necesitan actualizaciones coordinadas. Decide el modelo de edición antes del lanzamiento. Esperar hasta el primer homepage roto cuesta una semana de soporte.
¿Cuál es la política mínima de backup para un sitio de lead-gen?
Backups diarios de base de datos, backups regulares full-site, una copia offsite y una prueba de restauración antes del go-live. Aumenta la frecuencia si publicas o tomas órdenes todo el día. Los snapshots del hosting solos son un single point of failure cuando el panel es el incidente.
¿Deben los plugins de seguridad reemplazar los firewalls del hosting?
Resuelven capas distintas. Los controles de host y red detienen mucho ruido antes de que corra PHP. Los plugins a nivel de aplicación ayudan con abuso de login e integridad de archivos. Productos solapados que ambos reescriben .htaccess o ambos desafían a cada visitante crearán tickets de soporte. Elige un stack y documentalo.
¿Qué tan técnico debe ser el traspaso al cliente?
Lo bastante técnico para que el cliente pueda recuperar acceso y hacer ediciones rutinarias sin ti. No tan denso que se vuelva un PDF sin leer. Mapa de logins, workflow de edición, contactos de backup y ruta de escalación superan un manual de 40 páginas.
¿Podemos lanzar sin Search Console?
Puedes, pero volarás a ciegas en indexación y avisos de seguridad. La verificación es barata frente a una semana de «por qué no aparecemos». Hazlo durante la semana de lanzamiento si la búsqueda de Google importa al negocio en absoluto.
¿Qué pertenece a hypercare frente a un proyecto nuevo?
Hypercare cubre defectos del build y la configuración de lanzamiento. Nuevas plantillas de página, nuevas integraciones y rediseños son scope nuevo. Escribe ese límite para que la buena voluntad no se convierta en trabajo de producto no pagado.
Cierra la puerta, luego mantén las luces encendidas
Una checklist de lanzamiento de WordPress para un sitio de negocio es realmente una checklist de evidencia. Owners nombrados, hosting adecuado al propósito, defaults de seguridad en su lugar, plugins justificados, backups restaurados una vez, rendimiento suficiente para teléfonos reales, SEO sin autosabotaje, formularios probados y un traspaso que la gente usará.
Cuando esas puertas están en verde, marketing puede gastar y los editores pueden publicar sin inventar ops bajo presión. Cuando están en amarillo, retrasa el anuncio. La URL esperará; un fallo público no.
Si quieres ayuda para convertir esto en un plan concreto de go-live o un build limpio antes de que el DNS cambie, contacta vía el formulario.