Cuando un cliente nuevo me pide «quiero posicionar en estas keywords», casi nunca empiezo por ahí. Empiezo por comprobar si Google puede rastrear e indexar la web con normalidad. Puedes tener el mejor contenido del sector para una keyword, pero si la página no se indexa, o si Google tarda semanas en descubrir el contenido nuevo, o si el rendimiento de carga espanta tanto a usuarios como al propio crawler, ese contenido nunca va a competir en igualdad de condiciones. El SEO técnico no es la parte más vistosa del trabajo, pero es la que determina si el resto del esfuerzo tiene una base sobre la que construir.
Por qué empiezo aquí y no por las keywords
El orden importa. Investigar keywords y escribir contenido sobre una web con problemas de indexación es como amueblar una casa antes de comprobar que tiene cimientos. La mayoría de los problemas de posicionamiento graves que he diagnosticado en cuentas ajenas —no la falta de contenido, sino la caída repentina de tráfico o el estancamiento inexplicable— tienen origen técnico: una migración mal hecha, un robots.txt que bloquea sin querer secciones enteras, o páginas que Google ha dejado de considerar relevantes por problemas de rendimiento. Antes de escribir una sola palabra nueva, quiero descartar que el problema esté aquí.
Rastreo e indexación: lo primero que reviso
Sin rastreo no hay indexación, y sin indexación no hay posicionamiento posible, por mucho que el contenido sea bueno. Empiezo siempre por:
robots.txt
Parece elemental, pero he encontrado más de una vez directivas de bloqueo heredadas de una fase de desarrollo que nunca se quitaron al pasar a producción, bloqueando secciones enteras del sitio sin que nadie se diera cuenta durante meses.
Cobertura de índice en Search Console
El informe de cobertura te dice qué páginas están indexadas, cuáles están excluidas y por qué. Presto especial atención a las categorías «rastreada, actualmente no indexada» y «detectada, actualmente no indexada»: normalmente indican problemas de calidad percibida o de presupuesto de rastreo, no errores técnicos evidentes, y requieren investigación caso por caso.
Sitemap.xml
Compruebo que esté actualizado, que no incluya URLs con error 404 o redirigidas, y que esté correctamente declarado en Search Console. Un sitemap desactualizado no bloquea la indexación por sí solo, pero es una señal de que el mantenimiento técnico del sitio lleva tiempo descuidado.
Presupuesto de rastreo (crawl budget)
En sitios grandes (miles de URLs, típico en ecommerce con muchas variantes de producto o filtros), el presupuesto de rastreo sí importa: si Google gasta su tiempo de rastreo en páginas de filtros combinados sin valor, tiene menos margen para descubrir y revisar el contenido que realmente quieres posicionar. En sitios pequeños (un blog corporativo, una web de servicios), esto rara vez es un problema real, y perder tiempo optimizándolo es priorizar mal.
Renderizado e indexación mobile-first
Google indexa con el renderizado móvil como referencia principal, no el de escritorio. Esto significa que si tu versión móvil oculta contenido que sí existe en desktop (un patrón habitual en diseños responsive mal planteados, donde se «esconde» contenido para simplificar la vista móvil), ese contenido puede no contar para la indexación de la misma forma. Compruebo esto renderizando la página como la vería el rastreador móvil de Google, no asumiendo que «responsive» es sinónimo de «todo el contenido está disponible igual en ambas versiones».
Core Web Vitals: lo miro, pero no me detengo aquí
Los umbrales actuales que maneja Google son LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos (que sustituyó a FID como métrica de interactividad) y CLS por debajo de 0,1. Las causas más habituales de fallo siguen siendo imágenes sin optimizar, tiempo de respuesta de servidor lento y recursos que bloquean el renderizado. No voy a extenderme aquí porque ya le dediqué un artículo completo con el checklist real que uso para auditar esto: Core Web Vitals en 2026: checklist real para auditar tu web. En esta auditoría general, Core Web Vitals es un punto de control más, no el centro del análisis.
Errores 404, redirecciones y cadenas de redirect
Un rastreo completo con una herramienta como Screaming Frog suele sacar a la luz enlaces internos apuntando a URLs que ya no existen, cadenas de redirecciones (A redirige a B, que redirige a C) que diluyen la señal de enlazado interno innecesariamente, y a veces redirecciones en bucle que confunden tanto al usuario como al rastreador. Ninguno de estos problemas suele ser dramático por sí solo, pero acumulados en un sitio con años de historia (cambios de plantilla, migraciones parciales, categorías eliminadas) generan una fricción técnica constante que vale la pena limpiar de una vez.
HTTPS y contenido mixto
Con HTTPS ya como estándar, el problema que sigo encontrando no es la ausencia de certificado, sino el contenido mixto: recursos (imágenes, scripts) que se cargan todavía por HTTP dentro de una página servida por HTTPS, lo cual genera advertencias de seguridad en el navegador y, en ciertos casos, bloqueo directo del recurso. Es un rastreo rápido de comprobar y, cuando aparece, casi siempre se debe a una plantilla antigua o a un plugin que no se ha actualizado para servir sus propios recursos de forma segura.
Contenido duplicado y canonicalización
En ecommerce especialmente, es habitual que la misma ficha de producto sea accesible por varias URLs (por parámetros de filtro, por variantes de color/talla, por rutas de categoría distintas que llevan al mismo producto). Sin una etiqueta canonical bien definida, apuntando siempre a la URL «principal» de cada producto, Google puede fragmentar la señal de relevancia entre varias versiones de la misma página, o directamente indexar la versión equivocada. Comprobar que cada página tiene un canonical coherente, y que ese canonical no forma cadenas ni apunta a páginas con error, es un punto que reviso siempre en ecommerce con muchas combinaciones de filtro.
Renderizado con JavaScript: cuando lo que ve el usuario no es lo que rastrea Google
Si el sitio está construido con un framework que renderiza gran parte del contenido en el cliente (JavaScript pesado, sin renderizado en servidor), existe un riesgo real de que el contenido tarde en aparecer para el rastreador, o directamente no se procese correctamente en la primera pasada de rastreo. Google es capaz de ejecutar JavaScript, pero no con la misma inmediatez que procesa HTML plano, y en sitios con mucho volumen de páginas esto puede traducirse en indexación más lenta de lo esperado. La comprobación rápida es usar la herramienta de inspección de URL de Search Console y ver el HTML renderizado tal y como lo procesa Google, comparándolo con lo que ve un usuario real — si faltan bloques de contenido importantes en la versión renderizada, ahí hay un problema que priorizar.
Análisis de logs: la comprobación que casi nadie hace y que más dice la verdad
Search Console te dice qué ha indexado Google, pero no exactamente qué está rastreando y con qué frecuencia, más allá de un resumen agregado. El análisis de logs del servidor (revisar directamente qué URLs visita Googlebot, con qué frecuencia y qué código de respuesta recibe) es la técnica que uso en sitios grandes cuando sospecho un problema de presupuesto de rastreo mal repartido: por ejemplo, descubrir que Googlebot dedica una parte desproporcionada de sus visitas a páginas de paginación o filtros de bajo valor, mientras que páginas de producto nuevas tardan días en recibir la primera visita del rastreador. Es una técnica que reservo para sitios con volumen suficiente de páginas — en una web de servicios con 30-40 páginas, el análisis de logs no suele aportar nada que Search Console no te diga ya de forma más sencilla.
Datos estructurados: una capa que ayuda, no que arregla lo de base
El schema markup (marcado de datos estructurados) ayuda a que Google entienda mejor el contenido y, en algunos tipos de contenido, habilita resultados enriquecidos en los resultados de búsqueda. Lo reviso siempre como parte de la auditoría técnica, comprobando que el marcado existente (si lo hay) no tenga errores de sintaxis que invaliden su lectura. Pero es una capa adicional sobre una base que ya tiene que funcionar: no compensa un problema de indexación ni sustituye contenido de calidad, por mucho marcado que le añadas encima.
Cómo lo explico a un cliente sin perfil técnico
Un informe técnico lleno de términos como «crawl budget», «canonical» o «renderizado» no le sirve de nada a alguien que gestiona un negocio y no vive dentro del SEO. Cuando presento los hallazgos, traduzco cada problema técnico a su consecuencia de negocio: no digo «tienes contenido duplicado sin canonicalizar», digo «Google no sabe cuál de estas tres versiones del mismo producto debe mostrar, así que probablemente esté repartiendo la fuerza de posicionamiento entre las tres en vez de concentrarla en una». El detalle técnico queda documentado para quien vaya a implementarlo (yo mismo o el equipo de desarrollo del cliente), pero la conversación con quien toma la decisión de negocio se centra en el impacto, no en la jerga.
Arquitectura de enlazado interno: una mención, no el análisis completo
Cómo estructuras las categorías y el enlazado interno afecta directamente a qué páginas percibe Google como más relevantes dentro de tu propio sitio. Es un tema con suficiente profundidad como para tratarlo aparte con detalle; aquí me limito a comprobar que no haya páginas «huérfanas» (sin ningún enlace interno que lleve a ellas, lo cual dificulta tanto el rastreo como que un usuario llegue de forma natural) y que las páginas que más quiero posicionar reciban enlazado interno proporcional a su importancia, no al revés.
Cómo priorizo qué arreglar primero
Con la lista de problemas encontrados, no ataco por orden de aparición en el informe, sino por una matriz simple de impacto contra esfuerzo:
- Impacto alto, esfuerzo bajo (por ejemplo, un robots.txt bloqueando secciones enteras por error): se corrige primero, casi siempre en el mismo día.
- Impacto alto, esfuerzo alto (una migración de canonicalización mal planteada en todo el catálogo): se planifica como proyecto, no como parche rápido.
- Impacto bajo, esfuerzo bajo (limpiar un puñado de redirecciones en cadena): se agrupa y se resuelve en bloque cuando hay tiempo.
- Impacto bajo, esfuerzo alto: normalmente se descarta o se pospone indefinidamente, salvo que forme parte de un proyecto mayor que ya justifique el esfuerzo por otros motivos.
Las herramientas que uso (y cuáles no hacen falta para empezar)
Search Console y PageSpeed Insights (o Lighthouse directamente desde Chrome DevTools) son gratuitas y suficientes para el 80% de lo que se necesita revisar en la mayoría de sitios pequeños y medianos. Screaming Frog, en su versión gratuita, permite rastrear hasta 500 URLs, que cubre webs de servicios y blogs corporativos sin coste. Solo recomiendo herramientas de pago (versión completa de Screaming Frog, Sistrix, Ahrefs para el módulo de auditoría técnica) cuando el volumen de páginas del sitio supera lo que la versión gratuita puede cubrir, o cuando se necesita monitorización continua automatizada, no para una auditoría puntual.
Checklist resumen de la auditoría
- robots.txt: ¿bloquea sin querer secciones que sí deberían rastrearse?
- Cobertura de índice en Search Console: ¿qué porcentaje de páginas importantes está realmente indexado?
- Sitemap.xml: ¿actualizado, sin URLs rotas ni redirigidas?
- Renderizado móvil: ¿el contenido visible coincide entre desktop y la versión que indexa Google?
- Core Web Vitals: ¿dentro de umbrales en las plantillas principales (home, categoría, ficha de producto o artículo)?
- Errores 404 y cadenas de redirección: ¿hay enlaces internos apuntando a páginas rotas?
- HTTPS: ¿hay contenido mixto cargándose por HTTP?
- Canonicalización: ¿cada página tiene una URL canónica clara y sin cadenas?
- Enlazado interno: ¿hay páginas huérfanas sin ningún enlace interno que lleve a ellas?
- Renderizado JS: ¿el HTML que procesa Google incluye todo el contenido relevante?
No todos los puntos aplican con la misma intensidad a cualquier sitio: un blog corporativo pequeño rara vez tiene problemas serios de presupuesto de rastreo o de renderizado JS, mientras que un ecommerce con miles de referencias puede tener problemas graves ahí que en un sitio pequeño ni existirían. Parte del criterio de una auditoría bien hecha es saber en qué puntos merece la pena profundizar según el tamaño y la complejidad real del sitio, no aplicar la misma checklist de 200 puntos genérica a cualquier proyecto sin criterio.
Con qué frecuencia repito esta auditoría
Para la mayoría de sitios, una revisión técnica completa con cadencia trimestral es razonable, complementada con monitorización más ligera y continua de cobertura de índice y Core Web Vitals entre medias. La excepción es cuando hay un cambio grande de por medio: una migración de dominio, un rediseño completo, o un cambio de plataforma (por ejemplo, de una plantilla a otra, o de WordPress a otro CMS). En esos casos, la auditoría técnica no espera al trimestre siguiente — se hace inmediatamente después del cambio, porque es precisamente cuando más probabilidad hay de que algo se haya roto sin que nadie lo note hasta que el tráfico ya ha caído.
El momento de mayor riesgo: las migraciones
La mayoría de las caídas de tráfico orgánico más graves que he visto no vienen de una penalización ni de un cambio de algoritmo, sino de una migración mal ejecutada: cambio de dominio, cambio de estructura de URLs, o paso de una plataforma a otra sin mapear correctamente las redirecciones antiguas hacia las nuevas. Cuando una web cambia de URLs sin redirección 301 página a página (no genérica al home, sino específica de la URL antigua a su equivalente nueva), Google trata el contenido como perdido, no como movido, y toda la autoridad acumulada durante años se pierde de golpe. Si tienes una migración planeada, la auditoría técnica antes y después del cambio no es opcional — es la diferencia entre una transición limpia y meses de recuperación de tráfico perdido innecesariamente.
Lo que el SEO técnico no te va a dar
Una web técnicamente impecable no posiciona por sí sola. El SEO técnico elimina obstáculos y asegura que Google pueda evaluar tu contenido en igualdad de condiciones frente a la competencia — no sustituye tener contenido relevante, autoridad de dominio o enlaces externos de calidad. Y sobre plazos: arreglar un problema técnico puede reflejarse en Search Console en cuestión de días o semanas (una vez Google vuelve a rastrear e indexar), pero eso no significa que vayas a subir posiciones en keywords competidas en ese mismo plazo. Para keywords con mucha competencia, mejorar la base técnica es una condición necesaria, no suficiente, y los resultados en posicionamiento siguen dependiendo de factores que tardan meses en construirse, no semanas.
Si quieres ver el planteamiento completo de una estrategia de SEO, no solo la parte técnica, tengo una guía completa de SEO que cubre el resto de piezas. Y si quieres profundizar en cómo está evolucionando el SEO con la IA generativa, tengo un artículo sobre SEO avanzado, E-E-A-T y lo que viene después de las keywords.