Saltar al contenido
Doctor SEO

SEO Técnico

La infraestructura: rastreo, renderizado, indexación, velocidad y todo lo que rompe silenciosamente.

Al terminar este nivel podrás diagnosticar por qué una URL concreta no aparece en Google y señalar en qué punto exacto se rompió la cadena. Esa cadena tiene tres eslabones y casi nadie los separa: Googlebot tiene que poder rastrear la URL, Google tiene que decidir indexarla, y solo después existe la posibilidad de posicionar. Un fallo en el primer eslabón se arregla en el servidor, en robots.txt o en el enlazado interno. Un fallo en el segundo casi nunca se arregla con configuración.

Eso es justo lo que la mayoría hace mal. El SEO técnico se trata como una lista de casillas que se marcan una vez (sitemap enviado, robots.txt presente, HTTPS activo) cuando en realidad es una disciplina de diagnóstico. La pregunta útil no es «¿tengo sitemap?», sino «¿qué URLs está rastreando Googlebot esta semana, cuáles ha decidido no indexar y qué tienen en común?». Quien sabe responder a eso arregla problemas reales. Quien solo marca casillas arregla los síntomas de otra web.

El segundo error, casi tan frecuente, es suponer que un problema técnico se anuncia con un error visible. No lo hace. Los fallos más caros del SEO técnico son silenciosos: una cadena de redirecciones que funciona perfectamente para el usuario, un canonical que apunta a la URL equivocada y vacía una sección entera en unas semanas, un parámetro de filtrado que genera cientos de miles de URLs que nadie pidió. El navegador no se queja. Google Search Console tarda en contarlo. Solo un rastreo propio y los logs del servidor lo ven venir.

Este nivel está escrito para ejecutar, no solo para entender. Cada lección termina en algo que se hace: un rastreo con Screaming Frog, una consulta sobre un fichero de log, una comprobación concreta en Google Search Console, una checklist que se recorre antes de tocar un servidor.

Qué cubre este nivel

  • Escribir y auditar un robots.txt que controle a Googlebot y a los rastreadores de IA sin bloquear por accidente recursos que Google necesita para renderizar.
  • Distinguir un problema de rastreo de un problema de indexación y de un problema de calidad, y saber qué informe de Google Search Console lo demuestra.
  • Leer un rastreo de Screaming Frog entero: códigos de estado, canonicals, profundidad de clic, contenido duplicado y redirecciones encadenadas.
  • Interpretar Core Web Vitals con los umbrales que Google documenta y decidir si merece la pena invertir en velocidad en tu caso.
  • Diagnosticar una web hecha con JavaScript: qué ve Googlebot después de renderizar y qué se queda fuera del HTML servido.
  • Planificar una migración web o un cambio de estructura de URLs sin perder posicionamiento, con una checklist previa y una verificación posterior.

Rastreo, renderizado e indexación son tres decisiones distintas

Google toma tres decisiones separadas sobre cada URL, y confundirlas es el origen de la mayoría de los diagnósticos equivocados. La primera es de rastreo: Googlebot pide la URL al servidor y recibe (o no) una respuesta. La segunda es de renderizado: para páginas que dependen de JavaScript, Google ejecuta el código en una instancia de Chromium y obtiene el HTML final. La tercera es de indexación: Google decide si esa página merece un sitio en su índice.

Cada decisión falla por motivos propios. El rastreo falla por robots.txt, por códigos de estado 5xx, por tiempos de respuesta del servidor o porque la URL sencillamente no está enlazada desde ninguna parte. El renderizado falla cuando el contenido depende de una petición que Googlebot no ejecuta, cuando la hidratación tarda demasiado o cuando los enlaces internos no son etiquetas de anclaje reales con atributo href. La indexación falla cuando Google sí ha visto la página y ha decidido que no aporta nada.

Ese último caso es el que más frustración genera. El estado «Rastreada, actualmente sin indexar» de Google Search Console no es un error técnico que se arregle reenviando el sitemap: es un juicio. Google ha invertido recursos en descargar la página y ha concluido que no justifica el espacio. Reenviar, solicitar indexación o añadir datos estructurados no cambia ese juicio. Cambiarlo exige que la página diga algo que no diga ya otra página mejor posicionada.

Core Web Vitals y el peso real de la velocidad

La velocidad es un factor de posicionamiento modesto y un factor de negocio grande, y conviene tratarla así. Google documenta tres métricas de Core Web Vitals con umbrales públicos: LCP (Largest Contentful Paint) hasta 2,5 segundos, INP (Interaction to Next Paint) hasta 200 milisegundos y CLS (Cumulative Layout Shift) hasta 0,1. Google evalúa esos valores en el percentil 75 de las visitas reales, no en una prueba de laboratorio aislada.

La consecuencia práctica de ese percentil 75 es que una web puede ir rapidísima en el portátil de quien la desarrolla y suspender igualmente. Las métricas de campo proceden de usuarios reales, con sus móviles reales y sus conexiones reales. Por eso una auditoría de velocidad que solo mire una ejecución local de Lighthouse es una auditoría incompleta: da un número de laboratorio, y el número de laboratorio no es el que Google usa.

La segunda consecuencia es de prioridad. Si una página no se indexa, su LCP da igual. Si una sección entera está bloqueada en robots.txt, su CLS da igual. La velocidad se optimiza cuando el rastreo y la indexación ya funcionan, no antes. En este nivel la velocidad aparece justo en ese sitio: después del rastreo y la indexación, y antes de cualquier pulido cosmético.

Los cambios que rompen en silencio

Las redirecciones, los canonicals y las migraciones web comparten una propiedad peligrosa: cuando se hacen mal, la web sigue funcionando para las personas. Un usuario que llega a una cadena de tres redirecciones ve la página final y no nota nada. Googlebot sí lo nota, porque cada salto consume una petición y porque una cadena larga acaba tratándose como un callejón sin salida.

Los canonicals tienen el mismo perfil de riesgo. Una etiqueta canonical mal generada por una plantilla, que apunta todas las fichas de producto a su página de categoría, elimina esas fichas del índice sin provocar un solo error en el navegador. El síntoma llega semanas después, en forma de caída de tráfico que nadie relaciona con el despliegue del mes anterior. La defensa es un rastreo periódico con Screaming Frog que compare cada URL rastreada con la URL canónica que declara.

Las migraciones web concentran todos esos riesgos a la vez, y por eso tienen lección propia. Un cambio de dominio, de CMS o de estructura de URLs sin un mapa de redirecciones completo y comprobado es la forma más rápida conocida de perder visibilidad. Lo que salva una migración no es la habilidad durante el fin de semana del cambio: es la checklist preparada antes y la verificación sistemática después.

Facetas, paginación y presupuesto de rastreo en ecommerce

Un ecommerce genera URLs mucho más rápido de lo que Googlebot puede rastrearlas, y ahí está la raíz de todo problema de crawl budget. Un catálogo de mil productos con cinco filtros combinables produce con facilidad cientos de miles de combinaciones de URL, casi todas con contenido prácticamente idéntico. Googlebot las descubre, las rastrea y gasta en ellas las peticiones que no dedica a las fichas que sí venden.

El presupuesto de rastreo, sin embargo, no es un problema universal. Un sitio de doscientas páginas no tiene un problema de crawl budget por mucho que el término se repita: Googlebot lo recorre entero sin esfuerzo. El crawl budget importa cuando el número de URLs rastreables supera con claridad al número de URLs que merecen existir, y eso ocurre sobre todo en ecommerce, en portales de clasificados y en cualquier web con un buscador interno indexable.

La solución combina varias herramientas de este nivel y ninguna funciona sola. El enlazado interno decide qué se descubre primero, robots.txt decide qué no se rastrea nunca, los canonicals consolidan lo duplicado y el análisis de logs es lo único que confirma si el cambio ha surtido efecto. Los logs del servidor muestran exactamente qué pidió Googlebot y cuándo, sin muestreo y sin estimaciones.

Orden de triaje: síntoma, causa probable y dónde mirar

Un diagnóstico técnico se hace de abajo hacia arriba: primero el acceso, después la indexación, después la calidad y al final la velocidad. Esta tabla recoge los síntomas más habituales en el orden en que conviene descartarlos, con la causa más probable y el sitio donde se comprueba.

Orden Síntoma Causa probable Dónde mirar
1 La URL no aparece en Google ni con el operador site: Bloqueo en robots.txt, etiqueta noindex o respuesta 4xx/5xx Inspección de URLs en Google Search Console y rastreo con Screaming Frog
2 «Descubierta, actualmente sin indexar» Googlebot conoce la URL pero no la prioriza: enlazado interno pobre o presupuesto de rastreo agotado Informe de indexación de páginas y logs del servidor
3 «Rastreada, actualmente sin indexar» Juicio de calidad de Google, contenido duplicado o casi duplicado Comparación directa con las URLs del sitio que sí se indexan
4 «URL alternativa con etiqueta canónica adecuada» en páginas que deberían indexarse Canonical generado por la plantilla apuntando a la URL equivocada Columna de canonical en el rastreo de Screaming Frog
5 Caída brusca de tráfico justo después de un despliegue Redirecciones perdidas, cambio de estructura de URLs o robots.txt de pruebas subido a producción Comparación del rastreo anterior y posterior, más robots.txt en producción
6 Google indexa una versión incompleta de la página Contenido inyectado con JavaScript que Googlebot no obtiene al renderizar Prueba de resultados enriquecidos y HTML renderizado en la inspección de URLs
7 Miles de URLs con parámetros en el índice Facetas rastreables y buscador interno indexable Informe de indexación de páginas y rastreo en modo lista
8 La página posiciona pero convierte mal en móvil Core Web Vitals fuera de umbral en datos de campo Informe de Core Web Vitals en Google Search Console

Las 14 lecciones de este nivel

  1. robots.txt en 2026: la guía definitiva (incluye bots de IA)
  2. Sitemaps XML: cuándo importan y cuándo no
  3. Crawl budget: quién debe preocuparse de verdad
  4. Indexación: por qué ‘Rastreada, actualmente sin indexar’ es un juicio de calidad
  5. Canonicals, noindex y el arte de no contradecirte
  6. JavaScript SEO: renderizado, hidratación y lo que Googlebot ve
  7. Core Web Vitals 2026: LCP, INP, CLS y cuánto pesan de verdad
  8. Redirecciones: 301, 302, cadenas y pérdidas silenciosas
  9. Códigos de estado HTTP para SEOs
  10. Paginación, facetas y el infierno del ecommerce
  11. Análisis de logs: la herramienta más subestimada que tienes
  12. Hreflang e internacionalización sin romper nada
  13. Migraciones web: la checklist que evita el desastre
  14. Cómo hacer un crawl con Screaming Frog como un profesional

Cómo estudiar este nivel

El orden de las lecciones de este nivel es un orden de diagnóstico, no una clasificación temática, así que conviene respetarlo. Las cuatro primeras construyen el modelo mental de rastreo e indexación, y sin ese modelo las lecciones de canonicals y de JavaScript se leen como trucos sueltos.

  • Antes de empezar, verifica tu web en Google Search Console y exporta el informe de indexación de páginas. Ese informe es el material de trabajo de casi todas las lecciones.
  • Instala Screaming Frog en su versión gratuita y lanza hoy un rastreo completo de tu sitio. Guarda ese rastreo como punto de comparación para cuando empieces a aplicar cambios.
  • Haz una lección al día y aplícala a tu propia web antes de pasar a la siguiente. Dos lecciones leídas seguidas sin ejecutar nada no dejan poso.
  • Pide a tu proveedor de hosting acceso a los logs del servidor en cuanto empieces el nivel. Suele tardar unos días y los necesitarás en la lección de análisis de logs.
  • Reserva la lección de migraciones para cuando tengas una real entre manos y vuelve a ella entonces con la checklist delante.

Cuando termines estas catorce lecciones, la infraestructura dejará de ser el cuello de botella y podrás dedicar el resto del tiempo al contenido y a los enlaces, que es donde se gana el posicionamiento. Para ver cómo encaja este nivel con los demás, abre el índice completo del curso de SEO gratuito, donde están los niveles anteriores y los siguientes en el orden recomendado.