La historia de una web de agencia traducida a siete idiomas es casi siempre la misma. En español funciona, en inglés a duras penas y en los cinco idiomas restantes prácticamente nada. El equipo culpa primero al contenido: se rehacen las traducciones, se publican unos cuantos artículos más, se contrata a un redactor. Las cifras no se mueven. Porque el problema no suele estar en el texto que escribiste, sino en cuántas direcciones distintas sirven ese texto, con qué código de estado y bajo qué etiqueta de idioma.
Este artículo convierte en guía los hallazgos de una auditoría técnica de extremo a extremo realizada sobre la web de un proveedor de software de viajes con siete idiomas. Todas las cifras proceden de esa auditoría o de estudios externos con la fuente indicada; ninguna es una estimación. La auditoría cubrió 1.088 páginas en producción, 1.469 direcciones del sitemap y los siete idiomas, y el retrato que salió fue este: el 85 % de las páginas no tenía etiqueta de dirección canónica, el sitio entero estaba duplicado en dos hosts distintos y las traducciones declaradas en seis idiomas devolvían en realidad un mensaje de "página no encontrada".
Cada sección de las que siguen te da una comprobación, un umbral o una regla de decisión que puedes aplicar en tu propia web con un navegador y curl, sin comprar ningún software. El orden también importa: sin limpieza técnica no funciona la profundidad de contenido, y sin profundidad de contenido no funciona la visibilidad en IA.
El orden de la auditoría: primero una única fuente de verdad (dirección canónica, hreflang recíproco, código de estado honesto), después el contenido y, en último lugar, la visibilidad en IA.
1. Cuenta primero: ¿desde cuántas direcciones se llega a la misma página?
No empieces la auditoría por el contenido, empiézala contando direcciones. Medir desde cuántas URL distintas se abre una página lleva diez minutos y suele destapar la mayor pérdida en la primera pasada.
En el sitio que medimos había dos fallos de base. El primero: el dominio devolvía 200 tanto con www como sin www, así que la web entera era accesible dos veces. El segundo: los nombres de ruta antiguos y nuevos se habían dejado abiertos a la vez, de modo que /es/portfolio y /es/referencias servían el mismo contenido; ese único patrón generaba alrededor de 1.713 direcciones fantasma.
Pide en tu propia web estas cinco variantes, una detrás de otra, y anota el código de estado que devuelve cada una:
| Variante | Ejemplo | Resultado esperado |
|---|---|---|
| Host sin www | ejemplo.com/es/blog |
301 → versión con www |
| Host con www | www.ejemplo.com/es/blog |
200 |
| Barra final | www.ejemplo.com/es/blog/ |
301 → versión sin barra |
| Parámetro de seguimiento | www.ejemplo.com/es/blog?utm=x |
200 + canonical sin parámetro |
| Nombre de ruta antiguo | www.ejemplo.com/es/articulos |
301 → ruta nueva |
En la línea de comandos basta con una sola línea:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -I <direccion>
Si dos o más de las cinco devuelven 200, el buscador no está viendo una página tuya, sino varias páginas casi idénticas. No es un asunto de penalización, es un asunto de señal repartida. Los enlaces entrantes, los datos de clic y el presupuesto de rastreo que deberían llegar a una sola dirección se dispersan entre varias.
Si las cinco variantes devuelven 200, la señal se parte en cinco. La solución tiene un orden: las rutas antiguas se unifican con 301 y el resto se agrupa con una etiqueta canonical autorreferencial.
Regla de decisión
Define exactamente una forma canónica por página y fija tres cosas sobre ella: el host (con o sin www, una de las dos), la política de barra final (siempre o nunca) y las mayúsculas y minúsculas. Mientras esas tres decisiones no estén escritas en algún sitio, cada plantilla de página nueva inventará su propia variante.
2. Canonical no es una orden, es una señal
Este fue el dato más llamativo de la auditoría: de las 1.088 páginas que devolvían 200, 921 (el 85 %) no tenían ninguna etiqueta canonical. De las 167 que sí la tenían, en 60 la etiqueta no era autorreferencial: la página se servía desde www.ejemplo.com/es mientras el canonical decía https://ejemplo.com/es/. Ni el host ni la barra final coincidían.
Aquí conviene tener claros dos hechos técnicos. La propia documentación de Google describe rel="canonical" no como una directiva, sino como "una señal fuerte de que la URL indicada debería ser la canónica"; la decisión final es del buscador. Esa misma documentación ordena los métodos de canonicalización de más fuerte a más débil: redirección > etiqueta canonical > presencia en el sitemap. El sitemap aparece explícitamente como señal débil.
La consecuencia práctica es esta: la etiqueta canonical, por sí sola, no es una herramienta de limpieza. Si quieres retirar una dirección antigua, usa una redirección; deja el canonical solo para las variantes que no se pueden redirigir (versiones con parámetros, combinaciones de filtros, URL con sesión).
Segundo hecho: Google recomienda que la página canónica lleve un canonical que se apunte a sí misma. Es decir, la suposición habitual de que "el canonical solo se escribe en las páginas duplicadas" es falsa; la página principal también debe apuntarse a sí misma.
Por qué un canonical escrito a mano acaba rompiéndose siempre
En el sitio auditado el canonical se había escrito a mano en diez plantillas de página distintas: en una con barra final, en otra sin www, en otra con un fragmento de ruta que ya no existía. En otras catorce plantillas no había ninguno. No es un descuido, es un resultado estructural: si cada persona que escribe una plantilla nueva tiene que recordar la regla por su cuenta, la regla acabará olvidándose.
La regla aplicable: canonical, hreflang y og:url no se generan en las plantillas de página, sino en un único lugar común, y se imprimen exactamente una vez por página. Si una página intenta escribir su propio canonical, el proceso de publicación debe impedirlo. En la estructura montada tras la auditoría esta regla quedó atada a una comprobación de compilación: garantizada por arquitectura, no por disciplina.
3. hreflang: el precio de declarar un idioma que no existe
Aquí es donde las webs multiidioma cometen su error más caro. En el sitio auditado, una entrada de blog en español declaraba una dirección como su equivalente en inglés. Esa dirección devolvía HTTP 200, pero en el cuerpo ponía "Blog Post Not Found". El mismo patrón se repetía en seis idiomas. Dicho de otro modo: la web estaba comunicando por su propia mano cientos de páginas vacías al buscador.
La documentación de Google sobre versiones localizadas es tajante: "Si la página X enlaza a la página Y, la página Y debe enlazar de vuelta a la X. Si esto no ocurre en todas las páginas que usan hreflang, estas anotaciones pueden ignorarse o no interpretarse correctamente." El mismo documento lo dice aún más claro: "Si dos páginas no se apuntan entre sí, las etiquetas se ignoran."
De ahí salen tres reglas:
| Situación | Comportamiento correcto | Comportamiento incorrecto |
|---|---|---|
| Traducción hecha y publicada | Declarar hreflang en los dos sentidos | Declararlo en un solo sentido |
| Sin traducción | No escribir ningún hreflang | Reutilizar el mismo slug para ese idioma |
| Traducción en borrador | No declarar nada hasta publicarla | Declararla "porque sale pronto" |
A la izquierda: un idioma declarado en un solo sentido apunta a una dirección que devuelve 200 pero no tiene contenido. A la derecha: solo se declaran, de forma recíproca, los idiomas con traducción real, y la línea del tercer idioma no se escribe en absoluto.
Otros dos errores frecuentes de la propia lista de Google merecen atención: códigos de idioma fuera de la norma ISO 639-1 y valores de región no oficiales como EU, UK o UN. El código de región debe ser ISO 3166-1 Alpha 2, y indicar una región por sí sola no es válido: no se escribe hreflang="ES", se escribe hreflang="es" o hreflang="es-ES".
x-default, por su parte, define una dirección de respaldo para los usuarios cuyo idioma no se puede resolver. En una web de agencia multiidioma la elección más sensata es la portada del idioma con el que se vende internacionalmente —normalmente el inglés— o, si existe, una pantalla de selección de idioma.
4. Soft 404: poner "no encontrado" y devolver 200
Un soft 404 es, según la definición de Google, una página cuyo contenido es un mensaje de error o un resultado vacío mientras el servidor devuelve un código de éxito 2xx. Es el fallo más difícil de detectar, porque ninguna herramienta de monitorización da la alarma: la página "funciona" y, además, nadie visita esa dirección.
En el sitio auditado, los contenidos inexistentes devolvían 200 más "no encontrado". Al cambiarlos por 404 honestos, tres fallos que habían estado completamente ocultos salieron a la luz a la vez:
| Fallo que salió a la luz | Direcciones afectadas |
|---|---|
| Las rutas codificadas en porcentaje no se descodificaban nunca | 23 |
| Páginas de categoría del sitemap sin equivalente real | 33 |
| Slugs de base de datos desalineados con la definición del producto | 10 |
El resultado más dramático: las páginas de producto en árabe no habían funcionado para ningún cliente real desde el día en que se publicaron. Solicitadas en UTF-8 crudo devolvían 200; solicitadas en la forma codificada en porcentaje que envía realmente un navegador, devolvían 404. Como era un soft 404, nadie se había dado cuenta: el equipo creía que las páginas en árabe estaban publicadas.
Regla de decisión
No tengas miedo de pasarte a 404 honestos. A corto plazo tu recuento de errores subirá, y eso no es un empeoramiento: es el momento en el que tu medición se vuelve fiel. Para las direcciones que no van a volver nunca, 410 es todavía más claro; pero qué dirección no va a volver es una decisión de contenido, así que tómala primero.
5. Alfabetos no latinos en la URL: la trampa de la codificación en porcentaje
Las rutas que contienen caracteres árabes, cirílicos o turcos las envía el navegador codificadas en porcentaje. La documentación de Google sobre estructura de URL lo recomienda de forma explícita: "Los caracteres fuera del rango ASCII deben codificarse en porcentaje." Ese mismo documento respalda usar en la dirección palabras en el idioma del público objetivo y, cuando haga falta, su transliteración.
El problema es que, si el lado servidor no resuelve esa codificación, un idioma entero muere en silencio. Para comprobarlo por tu cuenta, pide la misma dirección en dos formas:
- Forma cruda:
/ar/blog/<slug-en-arabe> - Forma codificada:
/ar/blog/%D8%A8...
Si las dos no devuelven el mismo código de estado, tienes un fallo. El número de idiomas que hay que probar es pequeño; el alcance del daño es un mercado entero.
Política aplicable: para los idiomas con alfabeto no latino, elige conscientemente una de estas tres opciones y aplícala de forma coherente en todos los idiomas: (a) el alfabeto propio del idioma de destino, si has verificado que la codificación en porcentaje funciona de punta a punta; (b) transliteración (por ejemplo budushcheye-... para el ruso); o (c) slug en inglés con prefijo de idioma. Ninguna de las tres es incorrecta. Lo incorrecto es comportarse de forma distinta de un idioma a otro.
Google recomienda además el guion frente al guion bajo como separador de palabras: "Te recomendamos que uses guiones (-) en lugar de guiones bajos (_) para separar las palabras de tus URL." El motivo es que el guion bajo se usa en programación para unir conceptos, no para separarlos.
6. Un sitemap no es una lista, es un compromiso
Con cada dirección que metes en el sitemap estás diciendo: "esta es una página real y merece ser indexada". El sitio auditado declaraba 1.469 direcciones; tras la limpieza quedaron 1.386. Lo que se descartó:
- 28 direcciones no devolvían HTML sino datos en crudo (JSON): un extremo de interfaz de aplicación se había declarado como si fuera una página.
- 21 direcciones no llegaban a renderizarse en absoluto.
- 33 direcciones eran páginas de categoría sin equivalente; sus cuerpos tenían entre 21 y 25 palabras y todas imprimían la misma plantilla de "no se ha podido cargar".
Además, las 1.469 direcciones se publicaban con el host equivocado (sin www): el sitemap declaraba una lista que contradecía la propia decisión canónica del sitio.
El segundo error silencioso estaba en el campo lastmod: generaba el valor "hoy" en cada petición. Eso vacía el campo de todo significado. lastmod tiene que alimentarse de la fecha real de última modificación del contenido; si no, el rastreador deja de tener en cuenta esa señal.
Lista de comprobación del sitemap
- ¿El host del sitemap es exactamente el host canónico del sitio?
- Saca diez direcciones al azar: ¿todas devuelven 200 y
Content-Type: text/html? - ¿La política de barra final se aplica también dentro del sitemap?
- ¿Los valores de
lastmodson distintos entre sí, o todos llevan el mismo día? - ¿Los idiomas sin traducción se quedan completamente fuera del sitemap?
- ¿Las páginas marcadas con
noindexse han eliminado del sitemap?
7. El error silencioso de robots.txt: la regla de grupo
Este fue a la vez uno de los fallos más baratos y más caros de la auditoría: el archivo contenía una línea Disallow, escrita correctamente, que era completamente inocua para Googlebot porque estaba en el grupo equivocado.
La causa es la lógica de grupos estandarizada en la RFC 9309. El estándar dice que un rastreador busca el grupo que coincide con su propio product token y obedece las reglas de ese grupo. El grupo comodín * solo entra en juego cuando no existe un grupo coincidente. Imagina un archivo así:
| Grupo | Reglas que contiene |
|---|---|
User-agent: Googlebot |
Disallow: /buscar |
User-agent: * |
Disallow: /buscar y Disallow: /carrito |
En este archivo Googlebot puede rastrear /carrito, porque esa línea no está en su propio grupo y no se combina con el grupo comodín. La regla es sencilla: si quieres que una regla se aplique, repítela dentro de cada grupo User-agent.
En lugar de revisarlo a ojo, copia tu archivo en el informe de robots.txt de Search Console y prueba la ruta objetivo. La primera línea en la que el resultado no coincida con lo que esperabas es, con toda probabilidad, este error de agrupación.
8. Caché de CDN: el idioma de un visitante servido a todos
Este fue el comportamiento más extraño que destapó la auditoría. La dirección raíz generaba una redirección 302 que variaba según el idioma del navegador del visitante. La capa intermedia guardaba esa respuesta durante una hora en caché sin enviar la cabecera Vary. Resultado: durante esa hora, el idioma de la primera persona que entraba en la web se servía a todas las siguientes. Un cliente corporativo que llegaba con el navegador en alemán acababa en el sitio en turco, y nadie conseguía entender por qué.
Para eso sirve exactamente la cabecera Vary: le dice a la caché de qué cabeceras de la petición depende la respuesta almacenada. En la formulación de MDN, incluir Vary "hace que las respuestas se almacenen en caché por separado según las cabeceras listadas en el campo Vary". Si no se envía la cabecera, la caché considera idénticas todas las peticiones a la misma dirección y devuelve la misma respuesta sin mirar el idioma, la cookie ni el dispositivo.
La respuesta cambia según el idioma, pero la clave de caché es solo la dirección. Durante una hora, el idioma del primer visitante se convierte en el idioma de todos.
Elige una de estas dos soluciones:
A — Separa la respuesta. Añade Vary: Accept-Language a toda respuesta que varíe según el idioma. La caché guardará una entrada distinta por idioma. El coste: baja la tasa de acierto de la caché.
B — Fija la respuesta (preferible). Que la dirección raíz haga una única redirección permanente sin mirar el idioma (por ejemplo / → 301 → /es) y que la preferencia de idioma se resuelva dentro de la página. Así la caché sigue siendo eficiente y el buscador ve un único comportamiento.
Segunda regla: no midas antes de purgar la caché
Una CDN puede retener respuestas HTML hasta veinticuatro horas. Si mides una corrección justo después de publicarla, estarás midiendo la versión antigua y concluirás que "no se ha arreglado". El orden correcto tras el despliegue es: publicar → purgar la caché de las rutas afectadas → medir. Por saltarse este paso hemos visto más de una vez cómo se revertía una corrección que funcionaba perfectamente.
9. Cadenas de redirección y destinos no canónicos
Antes de la auditoría, la dirección raíz se comportaba así: / → 302 → /es/ → 308 → /es. Tres paradas. Cada parada es latencia extra para el navegador y pérdida de señal para el buscador; además, que el primer salto sea un 302 (temporal) dice que el destino no es el canónico permanente. Se redujo a un solo paso: / → 301 → /es.
El segundo hallazgo fue más traicionero. El sitio tenía una tabla de redirecciones que llevaba las direcciones antiguas a las nuevas, y 329 de los destinos de esa tabla no eran canónicos — es decir, en cuanto se aplicaran las reglas, cada uno generaría una segunda redirección. Se detectó antes de que la canonicalización entrara en producción; de no ser así, el día del lanzamiento habrían nacido 329 cadenas nuevas.
Regla de decisión
Antes de añadir una fila a tu tabla de redirecciones, valida el destino contra la forma canónica: host correcto, política de barra final correcta y una página que devuelva realmente 200. Esa validación debería ser un paso obligatorio en cualquier trabajo que toque la tabla; depurarla después, fila a fila, cuesta muchas veces más.
10. Páginas que se pierden dentro de tu propia web
Que una página esté en el sitemap no significa que sea localizable. La auditoría sacó dos partidas de pérdida distintas.
49 direcciones huérfanas indexables. Páginas declaradas en el sitemap que no reciben ni un solo enlace en toda la web: una página de centro de ayuda (7 idiomas), cinco páginas de categoría de integraciones (35 direcciones) y 7 direcciones en las que los listados y el código se habían desalineado. Para algunas de ellas incluso se había escrito una función generadora de direcciones e integrado en el componente de menú, y nunca se llegó a llamar.
70 enlaces internos rotos. Cuatro tarjetas de categoría de la página de ayuda apuntaban a una ruta que no existía (4 tarjetas × 7 idiomas = 28 enlaces). La miga de pan (breadcrumb) de las páginas de detalle de servicio remitía a un índice de servicios que nunca se llegó a construir (2 posiciones × 3 servicios × 7 idiomas = 42 enlaces), y esa misma dirección rota entraba además en los datos estructurados.
El tercer hallazgo es más sutil: 21 de las 33 entradas de blog estaban a profundidad de clic 3 y su única vía de acceso era un paso de paginación marcado con noindex. Como los enlaces eran rastreables, técnicamente se rastreaban, pero no existía un enlace interno real e indexable que llevara a las entradas.
Método de medición
Pon a un lado la lista de direcciones de tu sitemap y al otro el grafo de enlaces internos de tu web (la suma de todos los <a href> de todas las páginas), y haz la diferencia. Lo que está en el sitemap y no en el grafo es huérfano; lo que está en el grafo y no devuelve 200 es un enlace roto. Generar estos dos conjuntos una vez al mes hace visible una pérdida que la mayoría de los sitios no llega a detectar nunca.
11. Contenido escaso y páginas que solo parecen traducidas
En la medición posterior a la auditoría, la media del sitio era de 472 palabras, con 176 páginas por debajo de 300. Pero el hallazgo de verdad no era la cifra en bruto, sino la forma de leerla.
Primera corrección: descuenta el marco de la página. Contar el texto de la página tal cual mete la cabecera, la navegación y el pie dentro del contenido. En el sitio que medimos, ese marco fijo suponía entre 117 y 233 palabras por idioma. Es decir, 300 palabras en bruto correspondían en realidad a un cuerpo de unas 120 palabras. Pon tu umbral real sobre el cuerpo sin marco, no sobre la cifra bruta.
Segunda corrección: normaliza la morfología del idioma. Mirando las cifras brutas, las traducciones al alemán parecían incompletas (mediana de 393 frente a 610 en español). El contenido era idéntico; toda la diferencia venía de la formación de palabras: Flugbuchungssoftware es una sola palabra en alemán, y la misma expresión ocupa cinco palabras en español. Medidos sobre ocho páginas traducidas por completo, los coeficientes salieron así:
| Idioma | Coeficiente (en = 1,00) |
|---|---|
| Alemán | 0,827 |
| Azerbaiyano | 0,916 |
| Turco | 0,929 |
| Ruso | 0,939 |
| Árabe | 0,963 |
| Español | 1,165 |
Aplicada esa corrección, quedó claro que en alemán y en español no había déficit de traducción y que el déficit real se concentraba en árabe (22 direcciones) e inglés (16 direcciones).
Tercer hallazgo: un resumen no es una traducción. Muchas de las versiones en árabe no eran traducciones completas, sino versiones abreviadas del texto en inglés: entre el 38 % y el 48 % de la mediana de su grupo. Sobre el papel contaban como "traducidas"; en la práctica no competían en ninguna consulta.
Cuarto hallazgo: 7 grupos con 67 direcciones tenían cuerpos idénticos carácter a carácter. La mayoría eran versiones de idioma que se habían abierto sin traducir.
Regla de decisión
Si "abres" un idioma sin traducirlo, ese idioma produce contenido duplicado y tampoco aporta nada a los idiomas que ya tienes. El umbral de publicación de un idioma nuevo debería ser este: el cuerpo en ese idioma alcanza al menos el 85 % del recuento de palabras normalizado del idioma origen. Por debajo, no publiques; y para un idioma que no publicas, tampoco escribas hreflang (ver sección 3).
12. Búsqueda con IA: el trabajo que viene después de la limpieza
No pases a esta sección sin haber cerrado los once puntos anteriores. La búsqueda con IA no es un canal aparte: es una capa montada sobre el mismo índice, y si la capa de abajo está rota, la de arriba funciona rota también.
Esto es lo que dicen las cifras. Según el seguimiento de BrightEdge entre febrero de 2025 y febrero de 2026, los resúmenes de IA aparecen en alrededor del 48 % de las consultas monitorizadas (un año antes rondaban el 30 %); en cerca de la mitad de las consultas sigue sin aparecer ningún resumen. En la medición de Seer Interactive de febrero de 2026, el CTR orgánico en consultas con resumen fue del 2,4 %, frente al 3,8 % en consultas sin él. En el panel estadounidense de 900 personas de Pew Research (marzo de 2025, 68.879 búsquedas), el 8 % de las visitas en las que se mostró un resumen de IA acabó en un clic sobre un enlace de resultado clásico; cuando no se mostraba resumen, la cifra era del 15 %. El clic sobre un enlace dentro del resumen se quedó en apenas el 1 %.
La cifra realmente crítica para viajes es esta: según datos de BrightEdge, solo el 17,7 % de las citas de los resúmenes de IA en consultas de viajes procede del top 10 orgánico (un año antes era el 5,7 %). Más de tres cuartas partes de las citas, por tanto, se extraen de fuentes que no están en la primera página.
Arriba, la comparación del CTR orgánico; abajo, la distribución de las fuentes citadas en consultas de viajes. Fuentes: Seer Interactive y BrightEdge, febrero de 2026.
Leídas juntas, esas dos cifras llevan a una conclusión práctica: estar en el primer puesto no garantiza que te citen, y que te citen es un trabajo aparte. Y ser citado tiene una contrapartida medible: según la medición de Seer Interactive de abril de 2026, las marcas citadas en una consulta reciben un 120 % más de clics orgánicos por impresión que las no citadas.
Qué hacer, entonces, y qué no
Empecemos por lo que no hay que hacer, porque en este terreno hay mucho ruido.
llms.txt no es una solución. En el análisis de Ahrefs sobre 137.000 dominios, el 97 % de los archivos llms.txt no recibió ninguna petición durante mayo de 2026; de los aproximadamente 38.000 dominios con un archivo válido, solo unos 1.100 recibieron siquiera una petición, el 96 % de esas peticiones venía de bots y la mayoría de esos bots eran herramientas de auditoría y perfilado, no agentes de IA. Por el lado de Google la situación es igual de clara: la documentación oficial sobre funciones de IA dice "No necesitas crear archivos legibles por máquina nuevos, archivos de texto para IA ni marcado para aparecer en estas funciones" y añade: "Tampoco hay datos estructurados de schema.org especiales que debas añadir."
Generar el archivo no hace daño, pero tu estrategia de visibilidad no puede construirse encima. Hay cuatro cosas que sí funcionan:
- En cada página, un párrafo de respuesta que una máquina pueda extraer limpiamente. Justo debajo del titular, de 40 a 60 palabras, definitorio y con sentido por sí solo. Frases como "en este artículo veremos…" no se pueden citar; una frase como "un void significa que, tras la emisión, el billete se considera nunca emitido, y solo es posible dentro de la ventana que define el proveedor" sí se puede citar.
- Cifras verificables con su fuente. Un dato con nombre de institución y año vale más, tanto para una persona como para una máquina, que una afirmación sin respaldo. La cifra que no puedas citar, no la escribas: cuéntalo de forma cualitativa.
- Datos estructurados estándar, bien implementados. No busques un esquema especial; rellena correctamente y de forma coherente tipos estándar como
Organization,BreadcrumbListoFAQPage. Dos fallos típicos que encontramos en la auditoría: el logotipo de la organización apuntaba a un archivo que no existía (cuando el buscador no puede recuperar el logo, descarta por completo la imagen del editor) y los datos de la miga de pan indicaban la categoría equivocada. - Contenido único y realmente traducido. Ninguna de las 67 direcciones que compartían cuerpo idéntico en siete idiomas era citable.
Los controles de fragmento también valen aquí: Google indica que nosnippet, data-nosnippet y noindex funcionan igualmente para las funciones de IA. Si no quieres que se use una sección en los resúmenes, ya tienes la herramienta.
13. Lista de veinte comprobaciones de visibilidad técnica
No requiere más herramientas que un navegador y curl. En cada punto está escrito el resultado esperado.
| # | Comprobación | Resultado esperado |
|---|---|---|
| 1 | Pedir el host sin www | 301 → versión con www (o al revés, de forma coherente) |
| 2 | Pedir la versión con barra final | 301 → a la forma única |
| 3 | Pedir la dirección raíz | 301 en un solo paso, sin mirar el idioma |
| 4 | Contar canonicals en diez páginas al azar | Exactamente uno por página |
| 5 | ¿El valor del canonical es la propia dirección de la página? | Sí, host y barra final incluidos |
| 6 | Conjunto hreflang en una página de producto o blog | Solo idiomas con traducción real |
| 7 | Pedir uno a uno todos los destinos hreflang | Todos 200 y con contenido real |
| 8 | ¿Cada destino apunta de vuelta? | Sí, de forma recíproca |
| 9 | ¿Los códigos de idioma son ISO 639-1? | Sí; ninguna región escrita en solitario |
| 10 | Inventar una dirección inexistente y pedirla | 404 (no 200 más "no encontrado") |
| 11 | Pedir un slug no latino en crudo y codificado | Las dos formas devuelven el mismo código |
| 12 | ¿El host del sitemap es el host canónico? | Sí |
| 13 | Muestrear diez direcciones del sitemap | Todas 200 y HTML |
| 14 | Revisar los valores de lastmod |
Distintos entre sí, fechas reales |
| 15 | Leer los grupos de robots.txt | Cada regla repetida en cada grupo |
| 16 | Vary en una respuesta dependiente del idioma |
Presente; o la respuesta no depende del idioma |
| 17 | Muestrear los destinos de redirección | Todos canónicos y devolviendo 200 |
| 18 | Sitemap menos grafo de enlaces internos | Conjunto vacío (sin huérfanas) |
| 19 | Recorrer enlaces de menú y miga de pan | Ninguno devuelve 404 |
| 20 | Orden de medición tras el despliegue | Publicar → purgar caché → medir |
14. Un calendario de auditoría
Si montas este trabajo como un proyecto puntual, volverá en seis meses. En el sitio que medimos, el deterioro no era solo cuestión de dejadez: el sistema se desviaba solo, porque cada plantilla de página nueva generaba su propia variante.
| Frecuencia | Trabajo | Por qué |
|---|---|---|
| En cada publicación | Puntos 1-5, 10, 20 | Una plantilla nueva no conoce la regla antigua |
| Semanal | Puntos 7, 8, 19 | Traducciones y añadidos rompen el conjunto |
| Mensual | Puntos 12-14, 18 | Sitemap y realidad se separan poco a poco |
| Trimestral | Puntos 6, 9, 11, 15-17 | La infraestructura y la tabla de redirecciones cambian |
Fuentes
- Google Search Central — Localized versions of your pages (hreflang)
- Google Search Central — Consolidate duplicate URLs (canonical)
- Google Search Central — HTTP status codes and soft 404 errors
- Google Search Central — URL structure best practices
- Google Search Central — AI features and your website
- IETF — RFC 9309: Robots Exclusion Protocol
- MDN Web Docs — Vary header
- BrightEdge — AI Overviews at the One-Year Mark: Presence, Size, and What They're Citing (febrero de 2026)
- Datos de Seer Interactive, recogidos por ALM Corp — Google AI Overviews and Organic CTR in 2026
- Datos de Seer Interactive, recogidos por Omnibound — Google AI Overviews Statistics (abril de 2026)
- Pew Research Center — Google users are less likely to click on links when an AI summary appears
- Ahrefs — We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read (junio de 2026)
Todas las mediciones sin fuente indicada (1.088 páginas, 921 canonicals ausentes, 1.469 → 1.386 direcciones de sitemap, 49 huérfanas, 70 enlaces rotos, 329 destinos de redirección no canónicos, los coeficientes de idioma) proceden de nuestra propia auditoría sobre la web de un proveedor de software de viajes con siete idiomas, realizada en julio de 2026.
Preguntas frecuentes
¿Para qué sirve exactamente la etiqueta canonical?
Cuando varias direcciones tienen el mismo contenido o uno muy parecido, le indica al buscador cuál debe considerarse "la original". Ahora bien, no es una orden: en palabras del propio Google es una señal fuerte, y la decisión final la toma el buscador. Para las direcciones que quieras retirar de forma permanente, usa una redirección 301 en lugar de un canonical: la redirección es la señal más fuerte.
¿Por qué es un problema que funcionen a la vez la dirección con www y la que no lleva www?
Porque técnicamente son dos sitios distintos. Si las dos devuelven 200, cada una de tus páginas pasa a ser accesible dos veces, y los enlaces entrantes, los datos de clic y el presupuesto de rastreo se parten por la mitad. Elige una, redirige la otra con un 301 y haz que el sitemap y los enlaces internos usen también la versión elegida.
¿Puedo escribir hreflang para todos los idiomas usando el mismo slug?
Solo si ese slug funciona de verdad en ese idioma. Google condiciona hreflang a la reciprocidad: si dos páginas no se apuntan entre sí, las etiquetas pueden ignorarse. Escribir hreflang para un idioma sin traducción equivale a declararle al buscador una página que no existe. Un hreflang que falta es mejor que un hreflang equivocado.
¿Qué es un soft 404 y cómo se detecta?
Es un servidor que devuelve un código de éxito 200 cuando el contenido es en realidad un mensaje de error. La forma más rápida de detectarlo es inventar una dirección que no exista en tu web y pedirla: si el código que vuelve no es 404, tienes soft 404. El informe de indexación de Search Console también lista estas páginas en una categoría propia.
¿Por qué las direcciones con caracteres árabes o cirílicos devuelven a veces 404?
El navegador envía esos caracteres codificados en porcentaje; si el servidor no resuelve la codificación, la dirección no se encuentra. Como la forma cruda funciona al probarla a mano, el fallo puede quedar oculto mucho tiempo. El método de comprobación es pedir la misma dirección tanto en crudo como codificada y confirmar que las dos respuestas devuelven el mismo código de estado.
¿Por qué ha bajado mi tráfico orgánico desde que se publican resúmenes de IA?
Las mediciones muestran una diferencia estructural: en los datos de Seer Interactive de febrero de 2026, el CTR orgánico fue del 2,4 % en consultas con resumen y del 3,8 % en consultas sin él. En el panel de Pew Research, las búsquedas con resumen generaron un clic en un enlace de resultado el 8 % de las veces, frente al 15 % sin resumen. Es decir, aunque mantengas la posición, recibirás menos clics en las consultas donde aparece un resumen; el objetivo tiene que ser que te citen dentro de ese resumen.
¿Debería crear un archivo llms.txt?
No hace daño, pero no bases tu plan de visibilidad en él. En el análisis de Ahrefs sobre 137.000 dominios, el 97 % de estos archivos no recibió ninguna petición durante mayo de 2026. Google, además, indica de forma explícita en su documentación oficial que para aparecer en las funciones de IA no hace falta ningún archivo legible por máquina nuevo, ni marcado, ni datos estructurados especiales.
¿Con qué frecuencia debería repetir la auditoría?
Si la planteas como un proyecto puntual, se degradará en pocos meses, porque cada plantilla de página nueva tiende a generar su propia variante de dirección. Un ritmo práctico: comprobaciones de dirección y canonical en cada publicación, comprobaciones de hreflang y enlaces internos cada semana, análisis de sitemap y huérfanas cada mes, y comprobaciones de infraestructura una vez al trimestre.
Cinco cosas que puedes hacer mañana por la mañana
- Ejecuta la prueba de las cinco variantes. Para tus tres páginas con más tráfico, pide la versión con y sin www, con y sin barra final y, si existe, la ruta antigua; anota los códigos en una tabla. Si más de una devuelve 200, ya sabes cuál es tu primera tarea.
- Cuenta canonicals en diez páginas. ¿Cuántos
rel="canonical"hay en el código fuente y el valor es la propia dirección de la página? Cada página que dé cero o más de uno es un hallazgo. - Pide uno a uno todos los destinos hreflang de un artículo. ¿Devuelven todos 200, tienen contenido real, apuntan de vuelta? Si hay un idioma sin equivalente, elimina esa línea: por sí sola, es la victoria más rápida que existe.
- Inventa una dirección que no exista y pídela. Si no recibes un 404, tienes soft 404; una sola corrección aquí saca a la luz varios fallos invisibles a la vez.
- Muestrea diez direcciones del sitemap. ¿El host es correcto, devuelven todas 200 y HTML, son reales los valores de
lastmod? Si el sitemap no dice la verdad, todas tus demás mediciones se apoyan en una base falsa.