La primera vez que abrí Google Search Console de un cliente y vi la posición media estancada en el puesto 18 durante meses, mi primer impulso fue pensar en contenido: escribir más, escribir mejor, publicar con más frecuencia. Me equivoqué. El problema no estaba en lo que se escribía, sino en lo que Google ni siquiera lograba leer bien. Esa es la razón por la que, antes de tocar una sola palabra de contenido, siempre empiezo por una auditoría técnica de SEO.

Una auditoría técnica no es un ejercicio académico ni una lista de errores para asustar a un cliente. Es un diagnóstico que responde una pregunta muy concreta: ¿puede Google rastrear, entender e indexar correctamente cada página que quieres posicionar? Si la respuesta es no, ninguna estrategia de contenido, por brillante que sea, va a rendir lo que debería.

Qué es una auditoría técnica de SEO y por qué no es opcional

Una auditoría técnica de SEO revisa la infraestructura del sitio —no el contenido en sí— para detectar todo lo que le impide a un motor de búsqueda rastrear, indexar y posicionar tus páginas correctamente. Cubre rastreo, indexación, velocidad de carga, arquitectura de la información, datos estructurados y señales de duplicidad.

La razón por la que insisto tanto en este orden —técnico antes que editorial— es simple: el contenido nuevo hereda los problemas del sitio que lo aloja. Si Google no puede rastrear una sección completa, o si el Core Web Vitals de tu plantilla es deficiente, cada artículo nuevo que publiques va a competir en desventaja desde el primer día, sin importar cuánto trabajo editorial le hayas puesto.

En el caso de un blog inmobiliario que llevé, esta fue exactamente la situación: contenido editorial sólido, calendario constante, pero una posición media que no se movía del puesto 18. La causa no eran los artículos —eran errores de Core Web Vitals, problemas de crawlability en categorías completas del sitio y ausencia total de schema markup. Corregir eso, no escribir más, fue lo que movió la aguja.

Antes de empezar: qué necesitas a mano

No hace falta un stack de herramientas caro para hacer un primer diagnóstico serio. Con esto es suficiente para empezar:

  • Google Search Console verificado y con al menos 3 meses de datos históricos.
  • Google Analytics 4 para cruzar tráfico con comportamiento.
  • Un rastreador de sitios — Screaming Frog (gratuito hasta 500 URLs) o Ahrefs Site Audit.
  • PageSpeed Insights o el reporte de Core Web Vitals dentro de Search Console.
  • Acceso al robots.txt y al sitemap.xml del sitio.

Si el sitio ya tiene tráfico, exporta también los últimos 3-6 meses de consultas de búsqueda desde Search Console antes de tocar nada. Esa exportación es tu línea base: sin ella, no vas a poder demostrarle a nadie —ni a ti misma— si las correcciones técnicas realmente movieron algo. Es un error común empezar a corregir sin haber fotografiado antes el estado inicial, y luego no tener con qué comparar el progreso tres meses después.

Sobre el presupuesto de herramientas: no necesitas gastar en todo desde el primer día. Google Search Console y PageSpeed Insights son gratuitos y suficientes para el 70% del diagnóstico inicial. Ahrefs, SEMrush o Screaming Frog en su versión de pago aportan valor real cuando el sitio supera las 500 URLs o cuando necesitas monitoreo continuo de posiciones, pero para una primera auditoría de un sitio pequeño o mediano, las herramientas gratuitas alcanzan perfectamente.

Paso 1 — Rastreo e indexación

Todo empieza aquí porque, si Google no rastrea una página, nada de lo que hagas en ella importa. En Search Console, el informe de Cobertura (o "Páginas" en la versión actual) te dice exactamente cuántas URLs están indexadas, cuántas fueron excluidas y por qué.

Qué revisar en Google Search Console

Presta atención especial a estas categorías dentro del informe de indexación:

  • "Rastreada actualmente no indexada": suele indicar contenido que Google considera de bajo valor o duplicado.
  • "Descubierta actualmente no indexada": normalmente un problema de presupuesto de rastreo (crawl budget) en sitios grandes.
  • "Página alternativa con etiqueta canónica adecuada": revisa que la URL canónica señalada realmente sea la correcta y no un error de configuración.

Rastreo con Screaming Frog

Un rastreo completo del sitio te va a revelar lo que Search Console no muestra directamente: cadenas de redirecciones, enlaces internos rotos, páginas huérfanas (sin ningún enlace interno apuntando a ellas) y etiquetas noindex puestas por error en secciones que sí deberían posicionar.

Una plantilla de categoría con noindex mal configurado puede sacar de juego a cientos de páginas de producto o de artículo sin que nadie lo note durante meses. Es, en mi experiencia, el error técnico más silencioso y más caro.

También vale la pena revisar el archivo robots.txt línea por línea, no solo confiar en que "ya está configurado". He encontrado sitios bloqueando por accidente carpetas completas de imágenes —lo que afecta el posicionamiento en Google Imágenes— o bloqueando parámetros de URL que en realidad generaban contenido único y valioso. El sitemap.xml, por su parte, debería incluir únicamente URLs canónicas, indexables y que respondan con código 200; un sitemap inflado con URLs redirigidas o en error solo diluye la confianza que Google deposita en ese archivo.

Paso 2 — Core Web Vitals y rendimiento

Core Web Vitals mide la experiencia real de carga desde la perspectiva del usuario, con tres métricas centrales:

  • LCP (Largest Contentful Paint): cuánto tarda en cargar el elemento más grande visible. Ideal: menor a 2.5 segundos.
  • INP (Interaction to Next Paint): qué tan rápido responde la página a una interacción del usuario. Ideal: menor a 200 ms.
  • CLS (Cumulative Layout Shift): cuánto se mueve el contenido mientras carga la página. Ideal: menor a 0.1.

Los culpables más comunes de un mal desempeño en estas métricas suelen repetirse de sitio en sitio: imágenes sin dimensiones definidas (que provocan saltos de layout), fuentes web que bloquean el renderizado, scripts de terceros —chats, píxeles de publicidad, widgets de redes sociales— cargados de forma síncrona, y servidores de hosting compartido sin ningún tipo de cacheo.

Pantalla de código mostrando métricas de rendimiento web
Corregir Core Web Vitals casi nunca requiere reescribir el sitio: suele bastar con optimizar imágenes, diferir scripts y reservar espacio para el contenido que carga después.

Paso 3 — Arquitectura de la información y enlazado interno

La arquitectura del sitio determina qué tan fácil es para Google —y para tus usuarios— entender qué páginas son las más importantes. Una buena arquitectura sigue una jerarquía clara: home → categorías → subcategorías → páginas de contenido, con un máximo de 3-4 clics para llegar a cualquier página desde la portada.

El enlazado interno es la señal más subestimada del SEO técnico. Cada enlace interno es un voto de relevancia que le dice a Google "esta página importa". Si tus artículos más importantes solo reciben enlaces desde el menú de navegación y ningún otro artículo los menciona, estás desperdiciando la autoridad que ya tiene tu propio sitio.

Una revisión rápida de enlazado interno

  1. Identifica tus 10 páginas con mayor potencial de conversión o tráfico.
  2. Revisa cuántos enlaces internos reciben actualmente (Screaming Frog lo reporta directamente).
  3. Busca artículos relacionados que ya existan y que puedan enlazar hacia ellas de forma natural.
  4. Evita el enlazado interno genérico ("haz clic aquí"): usa texto ancla descriptivo con la palabra clave objetivo cuando sea natural hacerlo.

Paso 4 — Schema markup y datos estructurados

El schema markup no mejora tu posición directamente, pero mejora radicalmente cómo Google —y el usuario en los resultados de búsqueda— interpreta tu contenido. Un artículo con Article o BlogPosting bien marcado, una página de contacto con ContactPage, o un FAQ con FAQPage tienen más probabilidad de aparecer como resultado enriquecido (rich result) o snippet destacado.

Las validaciones más importantes de esta etapa:

  • Confirma que el schema esté implementado como JSON-LD (el formato que Google recomienda, más fácil de mantener que microdatos inline).
  • Usa la prueba de resultados enriquecidos de Google para validar sintaxis y cobertura de campos obligatorios.
  • No marques como Product algo que no es un producto, ni como Review una opinión que no cumple los requisitos — el spam de schema tiene penalización manual.

Un error frecuente es implementar schema una sola vez y nunca volver a revisarlo. Si tu plantilla cambia —un rediseño, un nuevo tema, una migración de CMS— el schema markup puede romperse silenciosamente sin que nada en el sitio se vea distinto a simple vista. Agenda una validación de schema cada vez que haya un cambio de plantilla, no solo cuando lo implementas por primera vez.

Paso 5 — Canibalización y contenido duplicado

La canibalización de palabras clave ocurre cuando dos o más páginas de tu propio sitio compiten por la misma intención de búsqueda, dividiendo la autoridad entre ellas en lugar de sumarla. Es uno de los problemas técnicos más comunes en sitios con mucho tiempo publicando contenido sin una estrategia de arquitectura clara.

Para detectarla, cruza en Search Console qué palabras clave traen impresiones a más de una URL de tu sitio. Si encuentras dos artículos compitiendo por la misma consulta, casi siempre la solución es consolidar: fusionar el contenido en una sola página autorizada y redirigir la otra con un 301, o diferenciar claramente la intención de búsqueda de cada una si de verdad son distintas.

Paso 6 — Priorizar: qué arreglar primero

El error más común al terminar una auditoría técnica es entregar una lista de 40 problemas sin ningún orden. Yo priorizo con una matriz simple de dos ejes: impacto potencial en tráfico/conversión versus esfuerzo de implementación.

  1. Alto impacto, bajo esfuerzo: corrige primero. Ejemplo: quitar un noindex puesto por error, arreglar redirecciones rotas.
  2. Alto impacto, alto esfuerzo: planifica como proyecto. Ejemplo: migrar la arquitectura de URLs, rehacer Core Web Vitals de la plantilla principal.
  3. Bajo impacto, bajo esfuerzo: agrupa y resuelve en lote cuando tengas tiempo. Ejemplo: completar etiquetas alt faltantes.
  4. Bajo impacto, alto esfuerzo: generalmente, no vale la pena priorizarlo todavía.

Un consejo adicional que aprendí a la mala: cuando presentes los resultados de la auditoría a un equipo o a un cliente, no entregues la lista técnica completa como primer documento. Empieza por 3-5 hallazgos con mayor impacto potencial, explicados en términos de negocio ("esto está bloqueando que el 30% del catálogo se indexe", no "hay 400 URLs con noindex"). La lista técnica completa es para el equipo de desarrollo; el resumen ejecutivo es para quien aprueba el presupuesto y el tiempo necesario para corregirlo.

Caso real: de la posición 18 a la posición 7

En el blog inmobiliario que mencioné al inicio, aplicar exactamente este orden —rastreo e indexación primero, luego Core Web Vitals, después schema— llevó la posición promedio del sitio de 18 a 7 en Google Search Console en un trimestre, sin cambiar todavía la estrategia editorial. El contenido que ya existía simplemente empezó a competir en igualdad de condiciones.

Checklist resumen

Guarda esta lista como punto de partida para tu propia auditoría:

  • ☐ Revisar el informe de indexación completo en Search Console.
  • ☐ Rastrear el sitio completo con Screaming Frog o similar.
  • ☐ Verificar robots.txt y sitemap.xml (que estén actualizados y sin bloqueos accidentales).
  • ☐ Medir LCP, INP y CLS en las plantillas principales.
  • ☐ Mapear la arquitectura de enlazado interno de tus páginas prioritarias.
  • ☐ Validar el schema markup implementado con la prueba de resultados enriquecidos.
  • ☐ Buscar canibalización cruzando keywords vs. URLs en Search Console.
  • ☐ Priorizar correcciones por impacto vs. esfuerzo antes de ejecutar nada.

Preguntas frecuentes

Una auditoría completa, una o dos veces al año. Pero el monitoreo de errores críticos —indexación, Core Web Vitals, caídas repentinas de tráfico— debería ser continuo, no anual.

No para empezar. Google Search Console es gratuito y cubre buena parte de lo esencial. Screaming Frog tiene una versión gratuita hasta 500 URLs, suficiente para sitios pequeños y medianos.

Puedes hacer un primer diagnóstico siguiendo esta guía. Para priorizar correctamente y ejecutar correcciones técnicas más profundas —arquitectura, migración, Core Web Vitals a nivel de plantilla— un especialista SEO acelera el proceso y evita errores costosos.