Publicar · Criterio KATA
Verificación posterior al despliegue
El momento con más riesgo de un proyecto no es el despliegue: son las horas siguientes, cuando todo el mundo asume que ya está.
Cómo se ha elaborado esta guía
Qué estás leyendo
Es la lista de comprobación de KATA tras publicar, con sus tres cortes de tiempo. Criterio propio formado en proyectos reales, no un estándar del sector.
Qué es criterio propio y qué es estándar externo
- Criterio propio: La secuencia, el orden y los umbrales que se describen son decisiones metodológicas de KATA.
- Experiencia observada: Lo aprendido en los proyectos de KATA. No se presenta como dato estadístico ni se cuantifica.
- Estándar externo: Cuando se cita un hecho de un tercero se identifica su fuente oficial, con entidad y fecha.
La metodología completa está en el Método KATA.
Respuesta directa
Se verifica en tres momentos, no en uno: a los 60 minutos, entre 24 y 72 horas, y a los 7 días. Cada corte detecta una familia de fallos distinta.
Concentrar toda la verificación en el minuto uno es el error más común, porque los fallos que más daño hacen no se manifiestan hasta que llega tráfico real.
Qué se comprueba en cada corte
| Corte | Qué se comprueba | Qué fallo detecta |
|---|---|---|
| 60 minutos | Respuestas HTTP, certificado, host canónico, redirecciones, enlaces, formularios, cabeceras y que noindex NO viajó a producción. | Errores de despliegue y de configuración. |
| 24–72 horas | Indexación iniciada, sitemap leído, registros del servidor, errores en el panel del buscador y primeros datos reales. | Errores que solo aparecen con tráfico y con rastreo real. |
| 7 días | Estabilidad, rendimiento con usuarios, conversiones registradas y ausencia de regresiones. | Degradaciones lentas y efectos secundarios. |
La comprobación que más veces salva un proyecto
Que la etiqueta noindex del entorno de pruebas no haya viajado a producción.
Es un error silencioso: el sitio funciona, se ve bien y nadie lo nota. Simplemente no aparece en ningún buscador, y cuando alguien lo descubre semanas después, se ha perdido tiempo que no se recupera. Por eso está en el minuto uno de nuestra lista y no más abajo.
Qué NO se hace en esta fase
- No se sacan conclusiones de tráfico: no hay datos suficientes y las primeras horas no son representativas.
- No se cambian cosas «ya que estamos»: cada cambio nuevo confunde el diagnóstico de lo que se acaba de publicar.
- No se declara el proyecto terminado. Se declara publicado, que es distinto.
Dónde este criterio NO aplica
- Sistemas con despliegue continuo y verificación automatizada: los cortes se sustituyen por alertas.
- Publicaciones de contenido menor sobre un sistema estable, donde el corte de 7 días no aporta.
- Entornos con guardia y observabilidad propia, donde esta lista se integra en la existente en lugar de sustituirla.
Preguntas frecuentes
¿Quién debe hacer estas comprobaciones?
Alguien que no haya hecho el despliegue, si es posible. Quien acaba de publicar tiende a comprobar lo que sabe que ha tocado, y el fallo suele estar en lo que dio por hecho.
¿Por qué siete días y no uno?
Porque una semana cubre un ciclo completo de comportamiento —laborables y fin de semana— y da tiempo a que los buscadores hayan pasado. Un solo día muestra una foto que puede no repetirse.
Siguiente decisión
Continúa con una pregunta concreta
Qué cambios obligan a volver atrás
Una lectura relacionada dentro del mismo método.
Qué cambios obligan a volver atrás →
Webs corporativas y transaccionales
Qué podemos abordar contigo y cómo delimitamos el trabajo.
Webs corporativas y transaccionales →
Ilustraciones conceptuales; no son fotografías de clientes.