SEO técnico: qué es y cómo revisar rastreo, indexación, canónicas y redirecciones

El SEO técnico es la parte del posicionamiento que se ocupa de que Google pueda rastrear tus páginas, indexarlas y saber cuál es la versión buena de cada una. Abarca robots.txt y noindex, el sitemap, la URL canónica, los códigos de estado y las redirecciones, el hreflang y el JavaScript. No mejora una página: evita que una buena se quede fuera.

Para comprobarlo en tu web: Auditoría SEO

Es la base del posicionamiento web: el contenido y los enlaces solo cuentan si Google llega a la página y la guarda en su índice. Esta guía repasa cada pieza con lo que documenta Google y con la forma de comprobarla tú mismo.

¿Qué diferencia hay entre rastrear e indexar?

Rastrear es que Googlebot descargue una URL; indexar es que Google analice lo descargado y lo guarde en su índice. Son pasos distintos y fallan por motivos distintos. Una página puede rastrearse y no indexarse, y una URL bloqueada para el rastreo puede acabar indexada sin contenido.

Entre los dos hay un paso más, el renderizado: Google procesa las páginas en tres fases, rastreo, renderizado e indexación, y toda página que responde 200 pasa por la cola de renderizado1.

El informe de indexación de páginas de Google Search Console es el punto de partida: dice qué URL están fuera del índice y por qué, ya sea un bloqueo en robots.txt, una etiqueta noindex, un 404, un 404 blando, una redirección o un duplicado sin canónica elegida2.

robots.txt frente a noindex: ¿cuál usar?

robots.txt dice a los rastreadores a qué URL pueden acceder; noindex dice a Google que no muestre una página en sus resultados. Confundirlos es el error técnico más caro, porque el efecto es el contrario del buscado.

Google lo explica así: robots.txt sirve sobre todo para no sobrecargar tu servidor y no es un mecanismo para mantener una página fuera de Google. Una URL bloqueada puede seguir apareciendo en los resultados, sin descripción, si otras webs la enlazan3. Para que noindex funcione, la página no puede estar bloqueada en robots.txt: si Googlebot no puede pedirla, nunca lee la etiqueta. Y poner noindex dentro del propio robots.txt no lo admite Google4.

Un robots.txt comentado para una web de servicios con buscador y área de cliente:

# robots.txt de https://www.example.com/ (siempre en la raíz del host)
# Todo lo que va detrás de # es un comentario y los rastreadores lo ignoran.

User-agent: *
# Los resultados del buscador interno generan miles de URL sin valor propio.
Disallow: /buscar
# El carrito y el área de cliente no tienen nada que posicionar.
Disallow: /carrito/
Disallow: /mi-cuenta/
# NO bloquees aquí una página que quieras sacar de Google con noindex:
# Googlebot no podría pedirla y nunca leería la etiqueta.

# Ubicación del sitemap, siempre con URL absoluta.
Sitemap: https://www.example.com/sitemap.xml

Google admite los comentarios con # y el campo sitemap, que debe llevar una URL completa con el protocolo5.

¿Necesitas un sitemap XML?

Un sitemap XML es un archivo que lista las URL que quieres que Google conozca, con datos opcionales como la fecha de la última modificación. Ayuda a descubrir páginas, pero Google advierte que no garantiza que se rastree e indexe todo lo que contiene6.

Google dice que quizá no lo necesites si tu web es pequeña, unas 500 páginas o menos, y está bien enlazada por dentro. Aun así, reconoce que en la mayoría de los casos una web sale ganando con él6. Si lo tienes, que sea coherente: incluir una URL en el sitemap la sugiere como canónica, aunque sea una señal débil7. Por eso no debe llevar URL que redirigen, que dan error o que tienen noindex.

La URL canónica: una sola versión de cada página

La URL canónica es la que Google elige como representante de un grupo de páginas duplicadas o casi iguales. Una misma página puede responder en http y en https, con www y sin él, con barra final y sin ella, o con parámetros de campaña. Para Google son URL distintas.

Google ordena las formas de indicar tu preferencia según su fuerza7:

1. Redirección: señal fuerte de que el destino debe ser la canónica.
2. rel="canonical": señal fuerte. Solo la acepta en el <head> y recomienda URL absolutas.
3. Inclusión en el sitemap: señal débil.

También pide no usar robots.txt para esto: una URL bloqueada puede indexarse igual, sin su contenido7. Y recuerda que son preferencias: Google puede elegir otra canónica si las señales se contradicen. Para que no pase, que las redirecciones, la canónica, el sitemap y los enlaces del menú apunten a la misma URL.

Así quedan las etiquetas técnicas en el <head> de una página con versión en dos idiomas:

<!-- El idioma va en la etiqueta html. Google no lo usa para detectar el idioma,
     pero los lectores de pantalla y el navegador sí. -->
<html lang="es">
<head>
  <!-- Título y descripción: los textos que suelen verse en el resultado -->
  <title>Fontanería urgente 24 horas | Example</title>
  <meta name="description" content="Fontaneros en tu casa en menos de una hora, todos los días. Presupuesto antes de empezar y factura con garantía.">

  <!-- Canónica: absoluta, con el protocolo y el host que has elegido -->
  <link rel="canonical" href="https://www.example.com/es/fontaneria/">

  <!-- hreflang: cada versión se lista a sí misma y a todas las demás -->
  <link rel="alternate" hreflang="es" href="https://www.example.com/es/fontaneria/">
  <link rel="alternate" hreflang="en" href="https://www.example.com/en/plumbing/">
  <link rel="alternate" hreflang="x-default" href="https://www.example.com/es/fontaneria/">

  <!-- Solo en páginas que NO quieres en Google y que robots.txt no bloquea:
  <meta name="robots" content="noindex"> -->
</head>

Cómo escribir bien el título y la descripción lo explicamos en la guía del título SEO y la meta descripción.

Códigos de estado y redirecciones

Un código de estado HTTP es el número con el que el servidor responde a cada petición: 200 si la página existe, 3xx si se ha movido, 4xx si no está y 5xx si el servidor ha fallado. Google decide qué indexa en gran parte con ese número.

Entre 301 y 308 la diferencia es del protocolo, no de Google: la 308 garantiza que el navegador repite la petición con el mismo método, mientras que algunos clientes antiguos convierten en GET lo que llega a una 30110.

Tres reglas sobre redirecciones, todas de Google:

• Mejor en el servidor. Las redirecciones con JavaScript solo si no hay otra opción, porque el renderizado puede fallar y Google no llegar a verlas8.
• Sin cadenas. Googlebot sigue hasta 10 saltos9, pero Google aconseja redirigir directamente al destino final y, si no puedes evitar una cadena, que tenga pocos saltos: idealmente no más de 3 y menos de 511.
• Que duren. En un cambio de URL, Google recomienda mantener las redirecciones todo lo posible y, en general, al menos un año11.

Para ver la cadena que recorre un visitante, basta con curl (cambia example.com por tu dominio):

# Sigue las redirecciones y muestra solo los códigos y los destinos
curl -sIL http://example.com/servicios | grep -iE "^(HTTP|location)"

# Salida de una web con una cadena de tres saltos (ejemplo):
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/servicios         <- de http a https
# HTTP/2 301
# location: https://www.example.com/servicios     <- de sin www a www
# HTTP/2 301
# location: https://www.example.com/servicios/    <- añade la barra final
# HTTP/2 200

Se arregla con una regla en el servidor que mande cada variante, de una vez, a https://www.example.com/servicios/. Repite la prueba con las otras variantes: todas deben llegar al 200 en un solo salto.

Página 404 personalizada y 404 blandos

Un 404 blando es una URL que no existe pero responde con un código distinto de 404 o 410. Google describe los dos casos típicos: una página de error bonita servida con un 200, y una web que redirige cualquier URL desconocida a la portada. Ambos le dificultan entender e indexar tu web12.

La solución no obliga a renunciar a una buena página de error. Puedes devolver el código 404 y mostrar a la vez el contenido que quieras: un buscador, enlaces a las secciones principales y una frase que explique qué ha pasado12. Search Console marca como «404 blando» las páginas que parecen un error aunque respondan 2002.

En las aplicaciones de una sola página, donde el servidor responde 200 a todo, Google propone redirigir a una URL que sí devuelva 404 o añadir noindex a la vista de error1.

Que una web tenga 404 no es un problema en sí. Google lo dijo en su blog: que algunas URL devuelvan 404 no afecta a cómo funcionan en los resultados las demás páginas de tu web12. Lo que sí conviene revisar son los enlaces tuyos que llevan a ellas, como contamos en enlaces rotos: cómo encontrarlos y arreglarlos.

hreflang y la declaración de idioma

hreflang es una anotación que dice a Google qué versiones de una página existen en otros idiomas o regiones, para que muestre la adecuada a cada persona. Se puede poner en el <head>, en una cabecera HTTP o en el sitemap. Google pone tres condiciones13:

• Cada versión se lista a sí misma y a todas las demás.
• Las URL son absolutas, con https://.
• Los enlaces van en las dos direcciones. Si la página A apunta a B pero B no apunta a A, Google puede ignorar la anotación.

El valor x-default marca la página para quien no encaja en ninguno de los idiomas listados, como un selector de idioma13.

Con el atributo lang hay un malentendido frecuente. Google dice que no usa el lang del HTML ni el hreflang para detectar el idioma de una página: lo deduce del contenido visible13. Por eso también recomienda URL distintas para cada idioma, en lugar de cambiar el texto con cookies o con la configuración del navegador14. Declarar lang sigue siendo obligatorio por otro motivo: es el criterio 3.1.1 de las pautas de accesibilidad WCAG, de nivel A, y permite a los lectores de pantalla usar la pronunciación correcta15.

Enlaces rastreables y JavaScript

Google solo puede rastrear un enlace si es un elemento <a> con un atributo href. Un <span> con un evento de clic, un <a> sin href o un href="javascript:…" pueden pasar desapercibidos16. Si tu menú o tu paginación funcionan así, hay páginas que Google quizá nunca descubra.

Google renderiza JavaScript, pero con cola y con límites: si el contenido principal solo aparece tras ejecutarlo, depende de que ese renderizado salga bien1. Con los rastreadores de los asistentes de IA la cuestión es distinta, y la tratamos en la guía sobre el contenido que solo se ve con JavaScript.

Checklist de SEO técnico

Para ordenar lo que encuentres junto al resto de bloques, sigue el método de la auditoría SEO con checklist.

¿Qué revisa SmoothSeen de todo esto?

Declaración de interés: este blog es de SmoothSeen, una herramienta de auditoría web. En la URL que analizas comprueba buena parte de esta lista: robots.txt y noindex, el sitemap, la URL canónica, HTTPS, las redirecciones y sus cadenas, la página 404 personalizada, el idioma declarado y los códigos hreflang, además del título, la meta descripción y los enlaces rotos. Lo tienes resumido en lo que mide el análisis de posicionamiento web.

No se conecta a Search Console, así que no ve qué URL ha indexado Google: eso lo responde el informe de indexación. Para ver cómo encaja lo técnico con el contenido y la autoridad, vuelve a la guía de posicionamiento web.

Preguntas frecuentes

¿Puedo usar robots.txt para quitar una página de Google?

No. robots.txt impide rastrear, no indexar: una URL bloqueada puede seguir apareciendo en los resultados, sin descripción, si otras webs la enlazan. Para sacarla usa noindex en la etiqueta meta o en la cabecera X-Robots-Tag, y deja la página accesible para que Googlebot lea esa instrucción. Si la quieres oculta para todo el mundo, protégela con contraseña.

¿Es mejor una redirección 301 o 308?

Para Google dan igual: las dos son permanentes y las dos indican que el destino debe ser la URL canónica. La diferencia está en el protocolo HTTP, porque la 308 obliga a conservar el método de la petición, algo que importa en formularios y en APIs, no en páginas normales. Usa la que tu servidor configure con más facilidad.

¿Hace falta poner una canónica en cada página?

No es obligatorio, pero es una práctica sencilla y útil: una canónica que apunta a la propia URL, absoluta y en el <head>, deja claro cuál es la versión buena cuando aparecen parámetros de campaña o variantes con y sin barra final. Lo importante es que coincida con las redirecciones, el sitemap y los enlaces internos.

Qué hacer ahora

Pasa el curl -sIL por las cuatro variantes de tu dominio y pide una URL inventada para ver qué código devuelve tu página de error. Después abre el informe de indexación de Search Console y anota las páginas importantes que estén fuera. Si quieres ver el resto de la lista comprobado en tu web y comparado con tus competidores, haz una auditoría SEO gratuita con SmoothSeen.