Build en verde, SEO roto: lo que un deploy puede romper sin que tus comprobaciones lo vean

El deploy salió el viernes. El build estaba en verde, los tests pasaron, la preview se veía bien y la web funciona para todo el que la abre. Tres semanas después, alguien se da cuenta de que los registros que llegan desde Google han caído un tercio.

La causa suele ser pequeña: una línea en un layout, un ajuste copiado del entorno de staging, una redirección añadida con prisa. Nada que un visitante note, y nada que compruebe un build o un test, porque ninguno mira la página como lo hace un buscador.

Este artículo enumera los cambios que vemos con más frecuencia, cómo reconocer cada uno y una rutina corta para después de cada deploy a producción.

Por qué los tests no lo detectan #

Los tests comprueban que la página funciona: el botón envía, el precio cuadra, la página responde 200. Los buscadores leen otras cosas, sobre todo en el <head> y en el HTML que envía el servidor antes de que se ejecute cualquier JavaScript. Una página puede funcionar perfectamente para las personas y aun así decirle a Google que no la indexe.

Y Google tarda en mostrártelo. Una página que sale del índice pierde su tráfico a lo largo de varios días, y Search Console lo informa unos días más tarde todavía. Para entonces, el cambio está enterrado bajo otros deploys.

Ocho cambios que rompen la búsqueda sin romper la web #

1. Un noindex que llegó desde staging #

La línea más cara del SEO:

<meta name="robots" content="noindex">

Suele llegar por un ajuste de staging que también se ejecuta en producción, por un componente que la añade cuando falta una variable de entorno o por una plantilla copiada de una página privada. La misma instrucción puede llegar también como cabecera HTTP, X-Robots-Tag: noindex, que ni siquiera verás en el código fuente de la página.

2. Un robots.txt que bloquea más de lo previsto #

Un Disallow: / pensado para staging, o una regla nueva que abarca más rutas de las planeadas. Dos detalles lo empeoran: una página bloqueada en robots.txt no se puede rastrear, así que Google nunca ve su contenido ni su noindex; y Google no admite noindex dentro de robots.txt, así que esa línea no hace nada.

3. Un canonical que apunta a otro sitio #

La etiqueta canonical le dice a Google cuál es la dirección principal. Después de un deploy puede empezar a apuntar a la página de inicio en todas las páginas, a una dirección de preview como my-project-git-main-team.vercel.app o a http:// en lugar de https://. Google trata el canonical como una señal fuerte, y uno equivocado puede llevar tu posicionamiento a una dirección que nadie visita.

4. Contenido que solo aparece después de ejecutar JavaScript #

Una refactorización lleva la lista de productos o el texto del artículo del servidor al navegador: la página se ve idéntica, pero el HTML que envía el servidor ahora está casi vacío. Google sí ejecuta JavaScript, pero más tarde y no siempre por completo. Tener el texto en el HTML del servidor es la opción segura para todo lo que quieras que se encuentre.

5. Redirecciones y códigos de estado #

Una página que antes respondía 200 ahora responde 404, o redirige a la página de inicio, o pasa por tres redirecciones antes de llegar. Un traslado permanente debe ser un único 301 o 308 directo a la dirección final. Los errores de tipo 5xx que duran días hacen que Google rastree menos y acabe retirando páginas.

6. Un sitemap que perdió páginas #

Una ruta nueva o un cambio en el CMS genera un sitemap sin algunas de las URL que traen tráfico, o con direcciones que ahora redirigen. El sitemap no es un factor de posicionamiento, pero es como Google descubre páginas rápido y como ves los problemas de indexación página a página en Search Console.

7. Títulos, descripciones y encabezados sustituidos por valores por defecto #

Un layout compartido empieza a sobrescribir los títulos de las páginas con el nombre del sitio, o todas las páginas reciben la misma descripción. En una página no es un desastre; es un daño real cuando les pasa a las 20 páginas que traen la mayoría de tus visitas.

8. Versiones de idioma que dejaron de apuntarse entre sí #

En una web en varios idiomas, los enlaces hreflang le dicen a Google qué versión mostrar a quién. Tienen que ser recíprocos: si la página en japonés apunta a la inglesa, la inglesa debe apuntar de vuelta. Un deploy que cambia las URL en un idioma rompe el par, y Google puede mostrar el idioma equivocado en los resultados de búsqueda.

Cómo revisar una página en dos minutos #

Para una comprobación puntual no necesitas ninguna herramienta. En un terminal:

# Status code, redirects and the X-Robots-Tag header
curl -sIL https://www.example.com/pricing | grep -iE "^HTTP|^location|x-robots-tag"

# robots meta tag and canonical in the server HTML
curl -sL https://www.example.com/pricing | grep -ioE '<meta[^>]+robots[^>]*>|<link[^>]+canonical[^>]*>'

# robots.txt as it is now
curl -s https://www.example.com/robots.txt

Para ver si el contenido principal está en el HTML del servidor, abre la página con Ver código fuente de la página (no con el inspector, que muestra la página después del JavaScript) y busca una frase del texto. En Search Console, la herramienta Inspección de URLs muestra la página tal como Google la obtuvo y la renderizó, y si se permite indexarla.

Una rutina para cada deploy a producción #

Revisar todas las páginas a mano no escala, así que revisa las que importan:

1. Haz la lista de tus páginas principales. En Search Console, abre Rendimiento, ordena las páginas por clics de los últimos tres meses y quédate con las 10 a 20 primeras. Esas páginas son la mayor parte de tu tráfico de búsqueda.
2. Después de cada deploy, pasa las comprobaciones de arriba en esas páginas: código de estado, noindex en la etiqueta y en la cabecera, canonical, título y una frase del texto en el HTML del servidor.
3. Mira el robots.txt y el sitemap siempre que cambien las rutas, el CMS o el framework.
4. Anota cómo es lo “normal” en cada página (estado 200, canonical a sí misma, título), para que un cambio salte a la vista.
5. Vigila Search Console durante la semana siguiente. El informe Páginas y los clics de tus páginas principales mostrarán los problemas que se colaron.

La mayor parte de esta lista también forma parte de un buen mantenimiento web mensual. La diferencia es el momento: una comprobación justo después del deploy encuentra el problema cuando todavía es un commit que revertir, no tres semanas de visitas perdidas.

Creamos Hawk Delta para hacer exactamente esto en las webs en Vercel que mantenemos: después de cada deploy a producción, compara las páginas importantes con la última versión buena y envía por correo qué se rompió, cuánto tráfico de búsqueda está en juego y cómo arreglarlo. Ahora está en una beta privada gratuita.