Checklist SEO técnico: qué revisar en una auditoría SEO web

El error más común es empezar por lo cosmético. Alguien reescribe las meta descripciones de veinte páginas mientras robots.txt bloquea una sección entera. Trabaja de lo general a lo particular, en cinco pasos.

1. Rastreo: ¿puede un robot obtener la página (robots.txt, códigos de estado, redirecciones)?
2. Indexación: ¿se permite que la página entre en el índice (noindex, canonical, duplicados)?
3. Comprensión: ¿dejan claro el marcado y el texto de qué trata la página (título, encabezados, datos estructurados, idioma)?
4. Velocidad: ¿carga la página sin retrasos evitables?
5. Seguridad: ¿se sirve el sitio por HTTPS sin configuraciones inseguras?

Decide primero qué vas a auditar: una página, una plantilla o todo el sitio. Un fallo en una plantilla se repite en miles de URL, así que un problema de plantilla pesa más que diez problemas sueltos. La guía de inicio SEO de Google es una buena referencia para lo básico.

Ten claros también los límites de las herramientas. Un escáner pasivo lee una URL y unos pocos archivos públicos de apoyo. No rastrea todo el sitio, no ejecuta JavaScript ni mide posiciones. En un sitio con cientos de páginas, combina un análisis rápido con Google Search Console.

Empieza por /robots.txt. Comprueba que responde con 200, que Disallow: / no afecta a todo el sitio y que no bloquea las hojas de estilo ni los scripts necesarios para renderizar la página. La sintaxis y los errores habituales están en robots.txt: cómo escribirlo y comprobarlo.

Después, los códigos de estado. Una página activa debe devolver 200, una eliminada 404 o 410, y una trasladada 301 o 308 hacia una única dirección final. Las cadenas de varias redirecciones ralentizan el rastreo y un bucle deja la página inaccesible. Un 302 temporal en una página movida de forma definitiva también conviene corregirlo. Google explica los traslados permanentes en su documentación sobre redirecciones.

Revisa por separado la versión HTTPS y los duplicados de host. Las versiones con y sin www no deben servir ambas el contenido: elige una y redirige la otra. Lo mismo vale para http y https.

Por último, el sitemap. Debe existir, estar declarado en robots.txt con una línea Sitemap: y listar solo URL canónicas que devuelvan 200. Los requisitos y errores están en sitemap.xml: requisitos, errores y cómo comprobarlo.

Una configuración mínima para este bloque se ve así:

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

Cuando el robot llega a una página, algo decide si entra en el índice. Aquí cuentan tres señales y no deben contradecirse.

Directivas noindex

Revisa la metaetiqueta robots y la cabecera HTTP X-Robots-Tag. Un noindex olvidado desde el entorno de pruebas es de los errores más caros al lanzar un sitio: la página funciona, pero nunca aparece en la búsqueda. Recuerda que el rastreador debe poder leer la directiva, así que una página con noindex no debe bloquearse además en robots.txt. Consulta la página de Google sobre cómo bloquear la indexación.

Canonical

La etiqueta rel="canonical" sugiere cuál es la URL principal entre varias páginas parecidas. Verifica que existe, que usa una dirección absoluta con https, que apunta a una página que devuelve 200 y que no señala a otra sin motivo. Los fallos típicos están reunidos en etiqueta canonical: cuándo usarla y errores comunes.

Páginas soft 404

Son páginas que dicen «no se ha encontrado nada» pero devuelven el estado 200. Gastan recursos de rastreo y no te aportan nada. Asegúrate de que una dirección inexistente devuelva un 404 real.

Un caso parecido es la página con casi nada de contenido en el HTML inicial, por ejemplo la que se monta solo con scripts. Si el código fuente apenas contiene texto, el buscador puede ver menos que un visitante.

Es la parte más visible de una auditoría, aunque no la más importante. Revisa como mínimo lo siguiente.

• El title existe, aparece una sola vez, describe esa página concreta y no es una palabra genérica como «Inicio». Procura que no sea tan largo que se corte; Google explica cómo elige los títulos en su documentación sobre title link.
• La meta description existe, difiere del título y no se trunca. Google puede reescribirla, pero una buena no estorba, como se ve en la documentación sobre fragmentos.
• Un único h1 con texto, y después subtítulos sin saltarse niveles.
• Un atributo lang en la etiqueta html con un código de idioma válido.
• Un meta viewport para que la página se vea bien en el móvil.
• Texto alt en las imágenes informativas, más los atributos width y height.
• Un doctype y una codificación de caracteres declarada.

Un head básico puede ser así:

<!doctype html>
<html lang="es">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Nombre de la página</title>
  <meta name="description" content="Descripción breve de la página para los resultados de búsqueda.">
  <link rel="canonical" href="https://example.com/page">
</head>

No persigas longitudes perfectas. Son orientaciones, no exigencias del buscador. Importa más que los metadatos sean únicos y describan la página con honestidad.

Los enlaces internos ayudan por igual a los visitantes y a los robots. Busca enlaces rotos, identificadores de sesión en las URL, enlaces mal formados (vacíos o con errores de escritura) y enlaces http en una página https. Para una revisión rápida basta una muestra de enlaces internos, pero un sitio grande necesita un rastreo completo.

Los datos estructurados dan a la página una descripción legible por máquinas. Comprueba que hay JSON-LD, que es un JSON válido, que @context está definido y que el tipo corresponde al contenido. Qué tipos necesita de verdad un sitio corriente se explica en datos estructurados JSON-LD: qué necesita un sitio web normal. El marcado no garantiza un resultado enriquecido, y marcar contenido que no se ve en la página va contra las normas de Google.

Si el sitio es multilingüe, revisa hreflang aparte: códigos de idioma válidos (uk para ucraniano, no ua), una autorreferencia en cada versión, enlaces recíprocos entre versiones y x-default. Los fallos habituales se describen en hreflang: errores comunes y cómo comprobarlos.

Por último, los metadatos sociales. Open Graph y Twitter Cards cambian el aspecto de un enlace en mensajería y redes, no la posición de la página. El favicon también entra aquí, y su ausencia se nota enseguida.

La velocidad se mide de dos maneras distintas que conviene no mezclar. Los datos de campo, de visitantes reales, aparecen en el informe de Core Web Vitals de Google Search Console y en PageSpeed Insights. Los datos de laboratorio los da Lighthouse. Qué significan LCP, INP y CLS y por qué sus umbrales están donde están se explica en Core Web Vitals para principiantes.

Un escáner pasivo no mide Core Web Vitals. Solo informa de señales indirectas de que una página puede cargar despacio:

• el tiempo de respuesta del servidor en la única petición principal (no es una métrica de Core Web Vitals);
• el tamaño del documento HTML;
• si la compresión de la respuesta está activada;
• si se admite HTTP/2;
• si hay cabeceras de caché;
• scripts que bloquean el renderizado en el head;
• la cantidad de hosts de terceros y de fuentes web;
• imágenes sin dimensiones declaradas, que pueden provocar saltos de diseño;
• formatos de imagen antiguos.

Son pistas sobre dónde mirar, no una puntuación. Si un escáner avisa de imágenes sin dimensiones, es un riesgo de salto de diseño, no un CLS medido. Para cifras reales usa datos de campo.

La seguridad tiene cabida en una auditoría técnica por dos motivos. Primero, Google recomienda servir las páginas por HTTPS. Segundo, fallos como el contenido mixto, un certificado caducado o un formulario que envía datos por http ahuyentan a los visitantes y rompen páginas.

Comprueba lo siguiente:

• todas las páginas son accesibles por HTTPS y http redirige a https;
• el certificado es válido, no ha caducado y está emitido para el nombre de host correcto;
• la página no tiene contenido mixto (scripts y estilos cargados por http);
• están definidas las cabeceras principales: Strict-Transport-Security, X-Content-Type-Options, una Content-Security-Policy y protección contra la inclusión en marcos.

Las cabeceras de seguridad no son por sí solas un factor de posicionamiento. Pero una CSP mal escrita puede bloquear scripts que tus páginas necesitan, y HSTS ahorra una redirección a quien vuelve al sitio. Cómo configurarlas y verificarlas se explica en cabeceras de seguridad y SEO. Si lo que necesitas es una revisión de seguridad, mira la comprobación de seguridad web.

Este es el resumen: qué comprobar y si el informe pasivo de SEOAudit lo muestra.

Para fijar prioridades, corrige primero lo que bloquea la visibilidad en el buscador: noindex, un robots.txt cerrado, errores del servidor, bucles de redirección. Después vienen los problemas que difuminan las señales: canonical en conflicto, hosts duplicados, errores de hreflang. Los metadatos, el marcado y las observaciones menores cierran la lista. El informe del escáner separa los resultados importantes de los informativos, y eso ayuda a no perder tiempo en detalles.

Repite la revisión tras cada lanzamiento relevante, cambio de plantilla, migración o traslado de dominio, y también de forma periódica, por ejemplo cada mes. Para una pasada automática está la página de auditoría SEO, y si te interesa la visibilidad en la búsqueda con IA, consulta la preparación para la búsqueda con IA.