Auditoría SEO técnica: qué revisa, paso a paso, y qué recibes al final

Qué es una auditoría SEO técnica y en qué se diferencia del resto

Una auditoría SEO técnica responde a una pregunta sencilla: ¿puede Google llegar a tus páginas, leerlas y entender cuáles importan? No juzga si los textos son buenos ni si tienes suficientes enlaces desde otras webs. Mira los cimientos. Si los cimientos están torcidos, todo lo que construyes encima trabaja con pérdidas. Y, a diferencia del contenido, los problemas técnicos suelen afectar a decenas de páginas a la vez, no a una sola.

La diferencia con una auditoría de contenido es fácil de explicar. La de contenido pregunta si la página responde bien a lo que busca la gente. La técnica pregunta si la página llega siquiera a Google de la forma correcta. En la práctica, la auditoría técnica es el primer paso de cualquier proyecto de optimización SEO, porque te dice qué hay que arreglar antes de invertir en artículos nuevos.

A continuación repasamos las comprobaciones una a una, en el orden en que las hacemos. En cada una incluimos un ejemplo real, encontrado en nuestra propia web. No porque nos guste enseñar nuestros errores, sino porque son justo el tipo de problemas que no se ven a simple vista y que una buena auditoría detecta. Todos están corregidos, y en cada paso describimos brevemente la solución.

Paso 1: la indexación y el acceso de los rastreadores

Lo primero que comprobamos es si las páginas importantes están en el índice de Google. La fuente fiable aquí es el informe de indexación de páginas de Search Console, no una búsqueda site: en Google. El informe muestra qué páginas están indexadas y, para el resto, el motivo: un error 404, una página marcada con noindex, bloqueada por robots.txt, un duplicado sin canónica seleccionada por el usuario o «rastreada, actualmente sin indexar».

Google dice claramente en su documentación que no debes esperar que todas las URL de tu web estén indexadas, solo las páginas canónicas. Así que no te asustes ante una lista de páginas sin indexar. Mira si entre ellas hay alguna página que te dé dinero. Ahí empieza el trabajo. Si tu página de servicio principal aparece como «rastreada, actualmente sin indexar», es un problema. Si aparecen páginas de filtros o URL con parámetros, muchas veces es justo el comportamiento que quieres.

Nuestro ejemplo: el 16 de septiembre de 2026, Search Console nos envió un correo con un error «Not found (404)» para una dirección del tipo /blog/cat-costa-un-site-de-prezentare. Esa página no existía y no estaba enlazada desde ningún sitio del menú ni del texto. La causa estaba en los datos estructurados: cada artículo declaraba en su schema de migas de pan una dirección /blog/nombre-del-articulo, cuando los artículos están en realidad en /blog-nombre-del-articulo. Google también sigue las direcciones del schema, no solo los enlaces visibles. Corregimos la dirección en el schema, añadimos una redirección 301 para cualquier dirección antigua de ese tipo y ampliamos nuestra comprobación automática de enlaces para que lea también las direcciones dentro del JSON-LD.

Paso 2: canonical, redirecciones y páginas duplicadas

Casi todas las webs tienen varias direcciones que llevan al mismo contenido: con y sin www, con y sin barra final, con parámetros de seguimiento. Google elige una de ellas como versión principal. Tu trabajo es darle señales que digan lo mismo. La documentación de Google describe la redirección como una señal fuerte, la etiqueta canonical también como una señal fuerte y el sitemap como una señal débil. Y advierte de forma explícita que no se indiquen URL canónicas distintas para la misma página mediante métodos diferentes.

Eso es exactamente lo que encontramos en la versión antigua de nuestra web, en la auditoría del 6 de septiembre de 2026. Todas las páginas del sitemap salvo la portada aparecían sin barra final. El servidor las redirigía con un 301 a la versión con barra. Y la página con barra tenía la etiqueta canonical apuntando de vuelta a la versión sin barra. Tres señales, dos direcciones. Para Google es como decirle «ve allí» y, cuando llega, «en realidad, vuelve».

La solución no es complicada, pero hay que aplicarla en los tres sitios a la vez: la dirección del sitemap, el destino de la redirección y el canonical deben ser la misma URL, carácter por carácter. En la web reconstruida atamos los tres a una única regla para generar direcciones, para que ya no puedan separarse. Después comprobamos en la web publicada que cada dirección del sitemap responde directamente con un 200, sin ninguna redirección por el camino.

Paso 3: la velocidad y las Core Web Vitals

Las Core Web Vitals son tres mediciones que Google usa para describir la experiencia real en una página. Los umbrales que recomienda Google son: LCP, el momento en que aparece el elemento principal, por debajo de 2,5 segundos; INP, lo rápido que responde la página a un clic, por debajo de 200 milisegundos; CLS, cuánto salta el contenido mientras carga, por debajo de 0,1. Google dice que estas mediciones se alinean con lo que sus sistemas de clasificación buscan recompensar, junto con otros aspectos de la experiencia en la página.

En una auditoría no te quedas en la puntuación de PageSpeed. Mides en un móvil, con la caché vacía y con velocidad y procesador limitados, en varios tipos de páginas, no solo en la portada. Después buscas la causa de cada problema, porque una puntuación por sí sola no arregla nada. Una web puede puntuar bien en la portada y tener problemas serios en los artículos o en las fichas de producto. Por eso elegimos una página de cada tipo de plantilla y las medimos todas, varias veces, para no sacar conclusiones de una sola ejecución.

Nuestro ejemplo, de septiembre de 2026: la carga era buena, pero el contenido saltaba. En la portada medimos un CLS de 0,117, por encima del límite de 0,1. La causa era el banner de cookies, que aparecía antes de que cargaran las fuentes y luego se recolocaba, empujando el texto. Web.dev incluye exactamente este tipo de causa entre las más frecuentes: fuentes que se muestran más grandes o más pequeñas que la fuente de reserva y elementos añadidos a la página por delante del contenido existente. Movimos la aparición del banner a después de la carga de las fuentes. Medido en la web en producción tras publicar, el CLS bajó a 0,023.

Paso 4: datos estructurados, encabezados y versiones de idioma

Los datos estructurados son código que le dice a Google de forma explícita qué hay en la página: una empresa, un servicio, un artículo, preguntas frecuentes, una ruta de navegación. En la auditoría compruebas tres cosas: si existen, si el tipo encaja con la página y si las direcciones que contienen llevan a páginas reales. Para validarlos, Google recomienda la prueba de resultados enriquecidos. En nuestra web antigua, las páginas de servicios solo tenían un schema genérico de negocio local, sin ninguna descripción del servicio, aunque eran páginas comerciales.

Aquí entra también la estructura de los encabezados. Cada página debería tener un único encabezado principal, el H1, que diga de qué trata. En la web antigua, cada página tenía dos: el encabezado real y otro, idéntico en toda la web, que había quedado en una parte oculta del código. Los visitantes nunca lo veían. El rastreador, sí. No es un error grave, pero es el tipo de señal mezclada que se suma a otras y hace que una página sea más difícil de entender.

Si la web tiene varios idiomas, también revisas hreflang, la etiqueta que enlaza entre sí las versiones de una misma página. Google exige que cada versión se enumere a sí misma y a todas las demás, y si los enlaces no son recíprocos, pueden ignorarse. También recomienda una versión x-default para los visitantes cuyo idioma no coincide con ninguna. En nuestra web en cinco idiomas encontramos una variante más sutil del problema: las páginas en inglés tenían en su schema unas migas de pan que apuntaban a las direcciones en rumano.

Paso 5: enlaces internos y el orden de las comprobaciones

La última parte es cómo se enlazan las páginas entre sí. Buscas páginas importantes a las que no lleva ningún enlace, enlaces internos a direcciones que redirigen o dan error y páginas que faltan en el sitemap. En la web antigua, la página de reservas se generaba y tenía enlaces hacia ella, pero faltaba en el sitemap. Un problema pequeño, pero justo la página que quieres que la gente encuentre.

Esta comprobación se hace mejor de forma automática, en toda la web, no página a página, porque una persona se cansa después de las primeras decenas de enlaces. En cada publicación ejecutamos un script que sigue todos los enlaces internos, también los de los datos estructurados, y no publicamos nada si encuentra alguno roto. En resumen, el orden en que trabajamos una auditoría técnica es este:

• 01Indexación: el informe de indexación de páginas de Search Console, robots.txt, sitemap, errores 404 y soft 404.
• 02Direcciones: redirecciones, canonical, versiones con y sin www o barra final, parámetros.
• 03Velocidad: LCP, INP y CLS medidos en móvil, en varios tipos de página, con la causa de cada problema.
• 04Código: datos estructurados validados, un único H1 por página, títulos y descripciones únicos.
• 05Idiomas: hreflang recíproco, x-default, direcciones correctas en cada idioma.
• 06Enlaces: enlaces internos rotos, páginas sin enlaces hacia ellas, páginas importantes que faltan en el sitemap.

Cuánto dura, qué recibes al final y cuándo merece la pena

La duración depende casi solo del tamaño y la complejidad de la web. Una web corporativa con unas decenas de páginas se revisa mucho más rápido que una tienda online con miles de productos, filtros y variantes de URL. También importa el acceso a Search Console: sin él, buena parte de las comprobaciones se convierten en suposiciones, porque no ves lo que ve Google. Desde fuera puedes revisar, aun así, las direcciones, la velocidad y el código.

Lo que deberías recibir al final no es una puntuación ni un PDF de 80 páginas generado por una herramienta. Es una lista de problemas ordenados por impacto, cada uno con tres cosas: dónde aparece, la prueba, es decir, una captura, una medición o una línea de un informe, y la solución concreta. Lo ideal es recibir también una comprobación después de las correcciones, porque muchos problemas parecen resueltos y no lo están hasta que los ves confirmados en Search Console.

Una auditoría técnica merece la pena cuando has rehecho o migrado la web, cuando has añadido un idioma nuevo, cuando el tráfico orgánico baja sin una explicación clara o cuando tienes páginas buenas atascadas en la segunda página de Google. No merece la pena repetirla cada mes en una web pequeña que no cambia. Ahí basta con mirar Search Console de vez en cuando.

Fuentes y lecturas.

• 01Google Search Central — Understanding Core Web Vitals and Google search results
• 02Google Search Central — How to specify a canonical URL with rel="canonical" and other methods
• 03Google Search Central — Tell Google about localized versions of your page
• 04Google Search Console Help — Page indexing report
• 05Google Search Central — Breadcrumb (BreadcrumbList) structured data
• 06web.dev — Cumulative Layout Shift (CLS)

Preguntas frecuentes

El equipo de The Niche SocietyIngenieros de IA y software desde Bucarest · LinkedIn

publicado 2026-09-28