Checklist de entrega web al cliente: lo que se olvida siempre

Respuesta corta: antes de entregar una web al cliente, comprueba que Google puede indexarla (sin noindex ni la casilla «Disuadir»), que va por HTTPS con redirección desde http, que el correo del dominio tiene SPF, DKIM y DMARC, que no carga cookies de analítica antes del consentimiento, que el debug.log no es público, que el sitemap está enviado, que la analítica mide, que hay copias que se pueden restaurar y que no quedan usuarios administradores de más. Abajo tienes la checklist de entrega web completa, con cómo comprobar cada punto.

Esta es la checklist de entrega web que usamos nosotros. Está ordenada por el daño que hace olvidar cada cosa, no por el orden en que se suelen hacer. Cada bloque enlaza a la guía donde lo explicamos a fondo.

Por qué se olvidan siempre las mismas cosas

Una web se entrega con prisa. El cliente quiere verla publicada, el diseño está aprobado, y lo que queda son detalles técnicos que nadie ve: un ajuste de WordPress, un registro DNS, un fichero de log. Además, mucha de esta configuración se hace en staging y se rompe al pasar a producción, o al revés: se arregla en producción y el staging la vuelve a pisar en la siguiente sincronización.

El problema es que esos detalles invisibles son los que generan las llamadas de los meses siguientes: «no salgo en Google», «mis correos llegan a spam», «me ha llegado una carta por las cookies», «la web me pone que no es segura».

Cómo saber si tu checklist de entrega web tiene huecos

Coge las tres últimas webs que entregaste y repasa con esta lista. Si encuentras más de dos fallos en alguna, no es mala suerte: es que el proceso no tiene una lista de comprobación, o la tiene pero no se aplica tras la publicación. La mayoría de los puntos de abajo se comprueban en menos de un minuto desde fuera, sin entrar al WordPress.

1. Indexación: que Google pueda ver la web

Es lo primero porque es lo que más dinero cuesta si falla: una web que no se indexa no existe para el cliente.

• Ajustes → Lectura: la casilla «Disuadir a los motores de búsqueda» está desmarcada. Lo explicamos en Disuadir a los motores de búsqueda.
• La portada y las páginas principales no llevan meta robots noindex ni cabecera X-Robots-Tag: noindex.
• El robots.txt no tiene Disallow: / ni bloquea CSS o JavaScript.
• Rank Math o Yoast: los tipos de contenido que deben salir en Google están en «Index».
• El canonical de cada página apunta a sí misma, con https:// y el dominio definitivo (no el de staging).

wp option get blog_public
curl -sI https://dominio.com/ | grep -i x-robots-tag
curl -s https://dominio.com/robots.txt

blog_public debe devolver 1, la segunda línea no debe devolver nada y el robots.txt no debe bloquear la raíz. Todas las causas, en Mi web no aparece en Google.

2. SSL y redirección a HTTPS

• El certificado es válido para el dominio y para www (o el que no uses redirige al que sí).
• El certificado se renueva solo (Let’s Encrypt o el del hosting), y la renovación funciona.
• http:// redirige con un 301 a https://, en un solo salto.
• Ajustes → Generales: la dirección de WordPress y la del sitio empiezan por https://.
• No hay contenido mixto (imágenes o scripts cargados por http://): el candado no debe mostrar avisos.

curl -sI http://dominio.com/ | grep -iE "^(HTTP|location)"
curl -sI http://www.dominio.com/ | grep -iE "^(HTTP|location)"
echo | openssl s_client -connect dominio.com:443 -servername dominio.com 2>/dev/null | openssl x509 -noout -dates -subject

Las dos primeras deben dar un 301 con location: https://.... La tercera te dice hasta cuándo es válido el certificado y para qué nombre. Los errores típicos y cómo resolverlos están en Errores de certificado SSL.

3. Correo del dominio: SPF, DKIM y DMARC

El formulario de contacto envía correos. El cliente envía presupuestos desde su dominio. Si el DNS del correo está mal, todo eso acaba en spam, y el cliente no lo relaciona con la web nueva hasta que pasan semanas.

• Hay un único registro SPF (v=spf1) que incluye todos los servicios que envían por el dominio (correo, web, newsletter) y termina en ~all o -all.
• El SPF no pasa de 10 consultas DNS.
• DKIM está activado en el proveedor de correo y publicado en el DNS.
• Existe un registro DMARC en _dmarc.dominio.com.
• La web envía los correos por SMTP autenticado (un plugin SMTP con el servidor de correo del cliente o un servicio transaccional), no con la función mail() del servidor.
• Has enviado un formulario de prueba y ha llegado a la bandeja de entrada, no a spam.

dig +short TXT dominio.com | grep -i spf
dig +short TXT _dmarc.dominio.com
dig +short TXT selector._domainkey.dominio.com

El selector de DKIM depende del proveedor (google en Google Workspace, selector1 y selector2 en Microsoft 365, default en muchos hostings). Todo el proceso está en Por qué tus correos llegan a spam: SPF, DKIM y DMARC.

4. Cookies: nada de analítica antes del consentimiento

Es el punto que más se rompe sin que nadie se entere, porque el banner se ve bien y parece que funciona.

• Hay un banner de consentimiento con botones de aceptar y rechazar igual de visibles.
• Antes de aceptar, la web no crea cookies de analítica ni publicidad (_ga, _gid, _fbp, _gcl_au, _hjSession, _clck…).
• Antes de aceptar, no salen peticiones a Google Analytics, Meta, Hotjar o Clarity (o salen en modo «denegado» si usas Consent Mode).
• La política de cookies lista las cookies reales que usa la web.

Cómo comprobarlo: abre la web en una ventana de incógnito, no toques el banner, abre DevTools (F12) → Aplicación → Cookies y mira qué hay. Después, pestaña Red y filtra por collect, analytics o facebook. Si ves cookies o peticiones de medición antes de aceptar, el banner no está bloqueando. Los criterios de la AEPD y cómo configurarlo, en Cookies y RGPD en tu web: lo que pide la AEPD.

5. Seguridad básica y restos del desarrollo

• WP_DEBUG está en false en producción, o al menos WP_DEBUG_DISPLAY en false.
• El fichero /wp-content/debug.log no existe o no es accesible desde fuera (debe dar 403 o 404).
• No quedan ficheros de instalación, copias de la base de datos (.sql), ficheros .zip del tema ni phpinfo.php en la raíz.
• Core, tema y plugins actualizados. Sin plugins desactivados que no se vayan a usar: bórralos.
• Ningún plugin con vulnerabilidades conocidas sin corregir.
• El staging está protegido con contraseña y con noindex.

curl -s -o /dev/null -w "%{http_code}
" https://dominio.com/wp-content/debug.log
wp plugin list --update=available
wp plugin list --status=inactive

El debug.log público es más grave de lo que parece: puede mostrar rutas del servidor, nombres de usuario y errores que dan pistas a un atacante. Si la web ya ha tenido un problema de seguridad, empieza por WordPress hackeado: qué hacer.

6. Usuarios y accesos

• Solo hay los administradores que tienen que estar. Fuera las cuentas de prueba, del maquetador externo y de la agencia anterior.
• Ningún usuario se llama admin.
• El cliente tiene su propio usuario, con el rol que necesita (a menudo Editor es suficiente).
• Contraseñas largas y únicas, y doble factor en las cuentas de administrador.
• Los accesos (hosting, DNS, dominio, WordPress) están documentados y se han entregado al cliente por un canal seguro, no por correo en texto plano.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

7. Sitemap y Search Console

• Existe un sitemap (/sitemap_index.xml con Rank Math o Yoast, o /wp-sitemap.xml) y solo incluye URLs con 200, sin redirección y sin noindex.
• El sitemap está declarado en el robots.txt.
• La propiedad de Search Console está verificada (mejor de tipo dominio, por DNS) y el sitemap está enviado.
• El cliente tiene acceso a Search Console como propietario. La propiedad es suya, no de la agencia.

8. Analítica y medición

• La etiqueta de Google Analytics 4 (o la herramienta que se use) está instalada una sola vez. Es habitual encontrar GA4 cargado por el tema y por Tag Manager a la vez, con lo que cada visita cuenta doble.
• Las conversiones importantes (formulario, llamada, compra) están configuradas y probadas.
• La medición respeta el consentimiento (punto 4).
• La cuenta de Analytics y la de Tag Manager son del cliente, con la agencia como usuario.

9. Copias de seguridad

• Hay copias automáticas de archivos y base de datos, guardadas fuera del servidor de la web.
• Se ha probado a restaurar una copia al menos una vez. Una copia que nunca se ha restaurado no es una copia: es una esperanza.
• Está claro quién es responsable de las copias (hosting, agencia o cliente) y cuántos días se guardan.

10. Funcionamiento y rendimiento

• Los formularios envían y llegan (punto 3). Si hay tienda, se ha hecho una compra de prueba completa.
• No hay enlaces rotos internos ni páginas de prueba publicadas («Hello world!», «Página de ejemplo», textos de relleno).
• La web se ve bien en móvil.
• PageSpeed Insights no muestra problemas graves en las páginas principales.
• La página 404 existe y lleva a algún sitio útil.
• Si hay errores de PHP, pantallas blancas o avisos de «error crítico», se han resuelto antes de entregar. Tienes los más frecuentes en la guía de errores de WordPress.

Errores habituales al entregar

• Hacer la checklist en staging y no en producción. Se pasa en el entorno de pruebas y, al migrar, se cuelan la casilla «Disuadir», el robots.txt de pruebas o los usuarios de desarrollo.
• Comprobar una vez y dar por hecho que se queda así. El certificado se deja de renovar, el cliente instala un plugin de cookies nuevo, alguien activa el modo depuración para revisar un error y no lo desactiva. La entrega es un punto de partida.
• Dejar los activos del cliente a nombre de la agencia. Dominio, hosting, Search Console, Analytics: si el cliente se va, hay un problema. Si se queda, también, porque nadie sabe quién tiene qué.
• No documentar nada. Una hoja con accesos, proveedor de DNS, quién renueva el dominio y dónde están las copias ahorra horas el día que algo falla.

Para agencias: que la checklist no caduque al día siguiente

La lista sirve el día de la entrega. El problema es el día 40, cuando algo cambia y nadie lo mira.

Jeffrey vigila después de la entrega buena parte de esta lista, en todas las webs a la vez. Cada día comprueba que la portada es indexable y, con el plugin de Jeffrey instalado, que nadie ha marcado «Disuadir a los motores de búsqueda». Revisa el certificado cada seis horas y avisa si deja de ser válido o caduca en 14 días o menos, y avisa si la web solo responde por http. Comprueba el SPF, el DKIM y el DMARC del dominio y las listas negras de spam, y revisa a diario con un navegador real si la web carga cookies o rastreadores de analítica antes de que el visitante acepte. También detecta si el debug.log de WordPress es público.

Con el plugin de Jeffrey instalado, además, avisa en el momento si aparece un administrador nuevo, vigila los plugins con vulnerabilidades conocidas y comprueba que las copias gestionadas están al día y pasan la prueba de restauración. Los avisos llegan a la agencia y a NexaTech a la vez, con nuestra marca o con la de la agencia, y la primera respuesta llega en menos de 4 horas.

Si quieres ver cómo montamos la vigilancia de una cartera entera, lo contamos en Cómo vigilar 40 webs de clientes sin revisarlas a mano. Y para contarle al cliente lo que haces cada mes, en Qué incluir en el informe mensual de mantenimiento web.

Preguntas frecuentes