Curso gratis · Sin registro

SEO técnico avanzado

Crawl budget, JavaScript, indexación y las señales técnicas que van más allá de lo básico

📚 7 módulos⏱ 40-45 minutos de lectura🎯 Avanzado

Felipe Morales — Fundador de ESBUENISIMO LABS, 15 años en SEO

Contenido del curso

1Crawl budget: el presupuesto que Google le dedica a tu sitio
2Cómo Google rastrea contenido en JavaScript
3Directivas de indexación: noindex, canonical y robots.txt
4Datos estructurados avanzados
5Log file analysis: lo que Googlebot realmente hace en tu sitio
6Core Web Vitals: métricas y cómo priorizar su corrección
7Cómo priorizar el trabajo técnico avanzado

Módulo 1

Crawl budget: el presupuesto que Google le dedica a tu sitio

Google no rastrea infinitamente — entender ese límite cambia cómo se prioriza el trabajo técnico.

El crawl budget es, en términos simples, la cantidad de páginas que Googlebot está dispuesto a rastrear en tu sitio dentro de un período de tiempo determinado. Para sitios chicos (unos pocos cientos de páginas) casi nunca es un problema real. Para sitios grandes —con miles de artículos, filtros de ecommerce, o parámetros de URL— administrar ese presupuesto se vuelve una parte central del SEO técnico.

→Cada redirección, error 404 o página duplicada que Google rastrea es presupuesto que no se usó en una página que sí importa.
→Un sitio más rápido permite que Googlebot rastree más páginas en el mismo tiempo asignado.
→Enlaces internos hacia páginas irrelevantes (política de cookies, términos y condiciones) desde todas las páginas del sitio desperdician parte de ese presupuesto en cada rastreo.

Tip: Si tu sitio tiene menos de 1.000 páginas, el crawl budget probablemente no sea tu problema técnico prioritario — hay señales de mayor impacto para atacar primero. Este concepto se vuelve crítico recién en sitios grandes.

Cómo verificar el rastreo real

El reporte de estadísticas de rastreo en Search Console (Configuración → Estadísticas de rastreo) muestra cuántas solicitudes hace Googlebot por día y a qué tipo de archivos — es la forma más directa de confirmar si el bot está gastando tiempo en algo que no debería.

Módulo 2

Cómo Google rastrea contenido en JavaScript

El renderizado no es instantáneo ni gratis — entender el proceso evita errores costosos en sitios modernos.

Googlebot procesa el contenido en dos etapas: primero rastrea el HTML inicial, y en una segunda pasada (que puede tardar de segundos a días) renderiza el JavaScript para ver el contenido final que ve un usuario real. Si el contenido más importante depende completamente de JavaScript para aparecer, existe el riesgo de que se indexe tarde o de forma incompleta.

→Contenido crítico (texto principal, enlaces internos importantes) debería estar presente en el HTML renderizado en servidor cuando sea posible, no depender solo de JavaScript del lado del cliente.
→Usá la herramienta de Inspección de URL en Search Console para ver exactamente cómo Google renderiza una página específica.
→Verificá que los enlaces internos usen etiquetas `<a href>` reales — enlaces generados solo con JavaScript sin un href real pueden no ser rastreados como enlaces.

Tip: Frameworks modernos como Next.js con renderizado en servidor (SSR) o generación estática (SSG) resuelven la mayoría de estos problemas de fábrica — la exposición al riesgo es mucho mayor en sitios armados solo con JavaScript del lado del cliente sin ningún tipo de renderizado previo.

Verificar que no hay bloqueo accidental

Un error común es bloquear, sin darse cuenta, archivos JavaScript o CSS necesarios para el renderizado a través de robots.txt — eso le impide a Google ver la página completa tal como la ve un usuario, y puede afectar cómo la evalúa.

Módulo 3

Directivas de indexación: noindex, canonical y robots.txt

Tres herramientas distintas, con propósitos distintos, que suelen confundirse entre sí.

Estas tres directivas controlan cómo Google indexa tu sitio, pero cada una responde una pregunta distinta — usarlas mal (o combinarlas de forma contradictoria) es una de las causas más comunes de problemas de indexación en auditorías técnicas.

Directiva	Qué responde	Cuándo usarla
robots.txt (disallow)	¿Puede Googlebot rastrear esta URL?	Para evitar que se rastreen secciones enteras sin valor SEO (paneles internos, buscadores internos)
Meta robots noindex	¿Puede esta página aparecer en los resultados de búsqueda?	Para páginas que sí necesitan ser rastreadas pero no deberían indexarse (páginas de agradecimiento, filtros duplicados)
Canonical (rel=canonical)	¿Cuál es la versión 'oficial' de esta página si existen duplicados?	Para consolidar variantes de una misma página (con o sin parámetros, http/https, con o sin barra final)

Tip: Un error grave y común: bloquear una URL en robots.txt Y ponerle noindex al mismo tiempo. Si robots.txt le impide a Google rastrear la página, nunca va a poder ver el noindex — y puede seguir indexándola solo por los enlaces que apuntan a ella.

Canonical: una sugerencia, no una orden absoluta

Google trata el canonical como una fuerte señal, no como una instrucción obligatoria — puede elegir una URL distinta como canónica si encuentra evidencia más fuerte (más backlinks, más rastreo) apuntando a otra versión. Por eso conviene mantener consistencia entre canonical, sitemap y enlaces internos, todos apuntando a la misma versión.

Módulo 4

Datos estructurados avanzados

Más allá de FAQPage y Organization: schema que resuelve problemas técnicos específicos.

Además de los tipos de schema más comunes, existen marcados más específicos que ayudan a Google a entender relaciones complejas entre entidades de tu sitio — especialmente útiles en sitios grandes con múltiples tipos de contenido.

→`ItemList`: para páginas de listado (categorías, resultados de búsqueda internos) que ayudan a Google a entender el orden y la estructura de una colección.
→`speakable`: marca secciones de texto optimizadas para ser leídas por asistentes de voz.
→`sameAs` a nivel de `Person` (no solo `Organization`): conecta al autor de un artículo con sus perfiles verificables, reforzando E-E-A-T.
→`mainEntityOfPage`: aclara cuál es la entidad principal de una página cuando hay múltiples schemas combinados.

Tip: Antes de agregar un schema nuevo, validalo siempre con la herramienta de prueba de resultados enriquecidos de Google — un schema mal formado no solo no ayuda, puede generar advertencias en Search Console que ensucian el diagnóstico de errores reales.

Módulo 5

Log file analysis: lo que Googlebot realmente hace en tu sitio

Search Console muestra un resumen — los logs del servidor muestran cada visita real, sin filtrar.

El análisis de logs del servidor es revisar el registro crudo de cada solicitud que llega a tu servidor, filtrado por las visitas de Googlebot. A diferencia de Search Console, que muestra datos agregados y con cierto delay, los logs muestran exactamente qué URLs visitó el bot, cuándo, y con qué código de respuesta.

→Identificá qué porcentaje del rastreo de Googlebot se está yendo a páginas de bajo valor (parámetros, páginas de error, duplicados).
→Confirmá si páginas nuevas importantes están siendo rastreadas rápido después de publicarse, o si tardan más de lo esperado.
→Detectá páginas que Googlebot dejó de visitar — puede ser señal de que perdieron enlaces internos o autoridad.

Tip: El análisis de logs es una técnica de nivel avanzado, más relevante para sitios grandes con miles de páginas — para un blog de tamaño mediano, Search Console suele ser suficiente para la mayoría de los diagnósticos.

Módulo 6

Core Web Vitals: métricas y cómo priorizar su corrección

Tres métricas de experiencia real de carga que Google usa como señal de ranking.

Core Web Vitals mide la experiencia de carga real de una página con tres métricas específicas. A diferencia de otras señales técnicas, estas se miden con datos de usuarios reales (Chrome UX Report), no solo en un entorno de laboratorio.

Métrica	Qué mide	Umbral 'bueno' de referencia
LCP (Largest Contentful Paint)	Tiempo hasta que carga el elemento visual más grande de la pantalla	2.5 segundos o menos
INP (Interaction to Next Paint)	Qué tan rápido responde la página a una interacción del usuario	200 milisegundos o menos
CLS (Cumulative Layout Shift)	Cuánto se mueve el contenido visualmente mientras carga (ej: un botón que se desplaza)	0.1 o menos

Tip: El CLS suele ser el más fácil y barato de corregir: casi siempre se debe a imágenes o anuncios sin dimensiones reservadas de antemano, que empujan el contenido cuando terminan de cargar.

Módulo 7

Cómo priorizar el trabajo técnico avanzado

No todo lo técnico tiene el mismo impacto — este módulo cierra con un criterio de decisión.

El SEO técnico avanzado tiene un riesgo particular: es fácil pasar semanas optimizando detalles de bajo impacto (como el log file analysis en un sitio chico) mientras un problema básico de indexación sigue sin resolverse. El criterio de priorización siempre debería partir de la pregunta '¿esto le está impidiendo a Google ver o entender contenido que ya es bueno?'.

→Primero: cualquier problema que bloquee la indexación de páginas importantes (noindex accidental, bloqueo en robots.txt, canonical mal configurado).
→Segundo: Core Web Vitals en las páginas de mayor tráfico, no en todo el sitio parejo.
→Tercero: crawl budget y análisis de logs, solo si el sitio ya es lo suficientemente grande como para que sea relevante.
→Cuarto: refinamientos de schema y marcado avanzado, una vez que lo anterior está resuelto.

Tip: Un sitio con SEO técnico impecable pero contenido mediocre sigue sin rankear bien. Lo técnico despeja el camino, pero no reemplaza al contenido ni a la autoridad — es condición necesaria, no suficiente.

Resultados reales