Arreglar una URL canónica que apunta a staging

Qué aspecto tiene el síntoma

Cada página del sitio en vivo sirve una canónica que nombra un host distinto:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
<link rel="canonical" href="https://staging.example.com/pricing">

Search Console lo muestra como "Duplicada, Google eligió una canónica distinta a la del usuario", o como páginas que se caen con una canónica declarada por el usuario en un host que nunca verificaste. Como el host de staging normalmente es inaccesible, está protegido con contraseña o lleva noindex, no hay ningún destino donde pueda aterrizar la consolidación, así que las páginas en vivo simplemente dejan de posicionar, un nuevo rastreo tras otro. Nada devuelve 500 y ninguna comprobación de uptime se entera, lo que es lo que lo hace caro.

De dónde viene la URL base equivocada

• Una base de datos restaurada desde staging. En WordPress, las filas de opciones siteurl y home llevan el nombre de host de staging a producción, y cada URL generada las sigue.
• Una variable de entorno en la compilación desplegada. Una URL de sitio incrustada en tiempo de compilación, así que la salida compilada lleva el valor de staging sin importar lo que diga el entorno de ejecución.
• Un host por defecto del framework configurado por entorno, donde la configuración de producción nunca se actualizó después de la de staging.
• Una URL absoluta codificada a mano en una plantilla compartida o un ajuste de plugin de SEO, escrita durante una migración y nunca revisada.
• Una página en caché construida sobre el host equivocado. Una CDN o una caché de página completa poblada por una compilación de staging sirve HTML obsoleto con la canónica de staging mucho después de haberse corregido la configuración.

Arregla el valor, y luego elimina la clase de fallo

1. Corrige la URL base guardada para producción, en el sitio de arriba que corresponda. En WordPress eso son las dos filas de opciones más cualquier URL absoluta escrita en el contenido de las entradas por la copia de staging.
2. Recompila y vuelve a desplegar si el valor está compilado dentro. Cambiar una variable de entorno sin recompilar deja el valor antiguo en el paquete publicado.
3. Purga todas las cachés en la ruta, tanto la de la aplicación como la de la CDN y el borde. Un origen corregido detrás de una caché llena de HTML de staging sigue pareciendo sin arreglar mientras viva esa caché.
4. Prefiere derivar la canónica del host de la petición en lugar de leer una constante guardada. Una canónica construida a partir del host que sirvió la petición no puede estar mal en el entorno desde el que se sirvió, lo que elimina toda la clase de fallo en lugar de solo este caso.
5. Mantén staging fuera del índice por otros medios. La autenticación HTTP o una lista de IP permitidas en el host de staging es lo que debería protegerlo, no una canónica, y no un noindex que puede viajar con un archivo de configuración.

Verifica la corrección en producción

Lee la respuesta, no la plantilla, porque los plugins, los workers de borde y las cachés inyectan todos canónicas que no aparecen en tu repositorio:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
curl -sI https://example.com/pricing | grep -i '^link:'

Luego comprueba más de una página. La canónica la genera una plantilla, así que acertar en la página de inicio no demuestra nada sobre las páginas de producto, los listados paginados o cualquier cosa renderizada por una plantilla distinta. En Search Console, la Inspección de URLs muestra la canónica declarada por el usuario junto a la que seleccionó Google, y que las dos coincidan tras un nuevo rastreo es la confirmación que importa. Ese nuevo rastreo tarda días, así que una canónica corregida no devuelve el tráfico esa misma tarde.

Evita que vuelva a pasar

Dos salvaguardas cuestan casi nada. La primera es una aserción en el momento del despliegue: tras una publicación, obtén un puñado de URLs de producción y haz fallar el despliegue si alguna canónica nombra un host distinto del de producción. La segunda es seguir vigilando después, porque el fallo tiene tantas probabilidades de llegar con una restauración de base de datos o un ajuste de plugin como con un despliegue de código. Las comprobaciones HTTP de HostTracker pueden hacer aserciones sobre el cuerpo y las cabeceras de la respuesta, así que se puede hacer que una comprobación programada falle cuando la etiqueta canónica de una página no es la que esperas, y ese fallo avisa como cualquier otro.

Revisa cada plantilla, no una página

Empieza con una URL afectada en la comprobación gratuita de canónica: resuelve la canónica y marca la que apunta a otro host, que es exactamente el aspecto de una canónica de staging. Después comprueba si el problema es de una página o de una plantilla entera mirándolas todas a la vez. La herramienta gratuita de rastreo de sitio recorre el sitio e informa del estado de la canónica por URL, junto con las marcas de noindex y los cuerpos duplicados que suelen acompañar a un despliegue defectuoso. Para detectar el próximo el mismo día en que se publique, activa la opción Indexability en un monitor HTTP para tus páginas clave: lee la canónica en cada comprobación y envía un aviso cuando cambia. La monitorización SEO explica cómo funciona.