Un directorio de empresas con una casa de apuestas como canónica
El 17 de septiembre de 2026 un usuario abrió un hilo en r/bigseo titulado «Pages get de-indexed by strange canonical content». Su web es un directorio de empresas y proveedores («Our pages are about companies and suppliers», escribe) y lleva tiempo viendo cómo Google le saca páginas del índice. Al investigarlo se encuentra con que la URL que Google considera canónica de las suyas es la home de www.747live.bet, una casa de apuestas y casino online orientada al mercado filipino.
Conviene fijar desde el principio de qué evidencia estamos hablando, porque el hilo es texto puro: no hay ni una sola captura de pantalla, ni de Search Console ni de la SERP. El afectado tampoco da cifras. Describe la pérdida como «a slightly but growing de-indexing» y en ningún momento dice cuántas URLs se le han caído. Ni siquiera reveló su propio dominio cuando se lo pidieron en el hilo.
Lo que sí comprobó, y es lo que descarta la explicación más obvia, es que no hay ninguna etiqueta canonical inyectada en su HTML: «If I fetch the page I don't see any canonical on our page». Sin canonical cruzada y sin redirección de por medio, la elección la está haciendo Google por su cuenta. Los primeros comentarios del hilo daban por hecho un hackeo.
La pantalla de error de Next.js que es idéntica en miles de dominios
La hipótesis central del caso no es del afectado, sino de otro usuario que dice haber pasado por lo mismo y haberlo visto resolverse solo. Su observación es concreta: al buscar en Google la URL del casino, el resultado aparecía indexado con este título, «Application error: a client-side exception has occurred (see the browser console for more information)». Es decir, Google tenía indexada la pantalla de error, no la web.
Esa cadena no es un texto cualquiera. Está escrita a fuego en el runtime de Next.js, y la documentación de Vercel la describe como lo que se muestra «in your production application» cuando una excepción de JavaScript en el cliente no la captura ningún error boundary de React. Al usuario solo le llega la frase genérica; el detalle real se queda en la consola del navegador. Como el texto es fijo, cualquier web en Next.js que rompa en cliente sirve el mismo contenido que cualquier otra.
He comprobado por mi cuenta la pieza que faltaba. Pedida con user-agent de Googlebot, la home de 747live.bet responde HTTP/2 200 y devuelve la cabecera x-powered-by: Next.js, además de servir los assets de /_next/static/. O sea que el dominio que Google eligió como canónica corre Next.js, que es justo lo que hacía falta para que la hipótesis se sostenga.
El otro ingrediente es el código de estado. La teoría del usuario es que las dos webs mostraron esa pantalla «but still sent a normal 200 OK status like the page loaded fine». Eso nadie lo ha medido en este caso, pero el patrón sí está documentado por Google: en su guía de problemas de JavaScript avisa de que las SPA que gestionan los errores en cliente «often report a 200 HTTP status code instead of the appropriate status code», y de que eso lleva a indexar páginas de error. Es inevitable en un sitio renderizado en cliente, porque el servidor ya ha respondido 200 cuando el error ocurre al hidratar. La diferencia entre hacer ese trabajo en el servidor o en el navegador la tienes desarrollada en SSR vs CSR.
Los tres escenarios de Mueller y el consejo de devolver un 503
Mueller intervino tres veces en el hilo, el 17 y el 18 de septiembre. La primera fue para validar la hipótesis sin comprometerse de más: «Yes, that's definitely an option». De ahí pasó al consejo, que es comprobar qué devuelven las páginas a Googlebot con la prueba en vivo de Search Console «to make sure you're not accidentally sending Google an error and users your content», y cerró con un «This will fix itself over time».
La segunda respuesta es la que ordena el problema. Mueller enumera tres desenlaces posibles y los tres acaban igual: que la página propia sea la canónica pero quede indexada con el mensaje de error, que se interprete como soft 404, o que la canónica sea la del otro dominio. En los tres casos, escribe, «your page is not showing in search for normal content». De ahí su arranque, «Ultimately I don't think this matters (though yes, it's confusing)». Hay un matiz que no conviene saltarse: al describir el escenario del soft 404 añade «imo this is what we should be doing», así que Google no lo está tratando así hoy y a él le parece que debería.
La tercera respuesta, del 18 de septiembre, es la más accionable de las tres. Mueller propone dos cosas. Una, mirar los logs del servidor y comparar la longitud de la respuesta por URL para localizar cuándo y dónde aparece el fallo, porque el HTML de error pesa muchísimo menos que el real. Y dos, encontrar en el código el punto donde se sirve ese error y hacer que devuelva un 503: «that way it won't be considered a normal HTML page, and won't be used for canonicalization & indexing».
El resto de su consejo va por el lado de no llegar a esa situación. Habla de correr una batería de tests automáticos antes de publicar y de montar monitorización propia o de terceros que pida las páginas críticas «hourly» para detectar el fallo antes de que se estabilice. La frase que resume su postura es que lo ideal es cazar este tipo de error «before you make the site live with the error».
Qué está confirmado y qué no en este caso
Puesto en orden, lo confirmado es poco. Mueller valida que el escenario es posible, no que sea lo que ocurrió. Nadie ha demostrado la causa, y el afectado no ha publicado más evidencia que su relato. El número de páginas desindexadas no existe como dato. Y la atribución a Next.js, aunque la cadena de texto y las cabeceras del dominio de casino la respaldan, no aparece en el hilo: allí se habla solo de «a generic JavaScript application error message».
Search Engine Journal, que lo cubrió el 18 de septiembre, ni siquiera compra la tesis. Roger Montti plantea dos alternativas («If that's what's happening, then it could be that the site was hacked. If that's not what's happening, then it's not a cross-domain canonical de-indexing») y cierra recordando que a veces las cosas solo parecen relacionadas por causa y efecto.
Hay un detalle del hilo que sí se sostiene sin depender de la hipótesis. El afectado reportó el 18 de septiembre que la inspección de URL de Search Console le renderizaba la página bien mientras el test de resultados enriquecidos, que es público, le devolvía la pantalla de error. Mueller lo atribuyó a que usan user-agents ligeramente distintos y lo calificó de «occasional hiccup». O sea que el fallo era intermitente y solo asomaba en una de las dos herramientas.
En cuanto a la doctrina, la documentación de canonicalización de Google dice que la preferencia que marcas es «a hint, not a rule» y que la compañía puede elegir otra página por distintos motivos, pero sus ejemplos son todos dentro del mismo sitio: protocolo, variantes regionales, dispositivo. No hay documentación que explique cuándo Google cruza de dominio sin canonical ni redirección. Para el único uso legítimo de canónicas entre sitios, la sindicación, Google lleva tiempo recomendando noindex en su lugar, y las diferencias entre etiquetas las tienes en Canonical vs Hreflang.
Mi lectura
Lo que me llevo de este caso es que un 200 no prueba nada. Puedes tener un crawl impecable, todas las URLs en verde y estar sirviéndole a Google una pantalla de error genérica que compartes con otros veinte mil dominios que no has visto en tu vida. Si trabajas con webs renderizadas en cliente, el código de estado y el HTML que sale renderizado son dos señales distintas y hay que vigilar las dos. Ojo también con el diagnóstico rápido, que en el hilo varias personas dijeron «te han hackeado» antes de que nadie mirase el renderizado.
De todo lo que suelta Mueller, lo del 503 es lo que yo me apuntaría. Es un cambio pequeño y saca la pantalla de error del juego de la canonicalización y la indexación, que es donde no pinta nada. Y si tienes acceso a logs, comparar la longitud de la respuesta por URL es un truco barato para cazar un fallo intermitente que a mano no vas a reproducir. Esto es de las cosas que hay que mirar a diario, así que móntalo automatizado, o mejor, tira de MCP y pídele a tu agente favorito que lo haga por ti.