SEO técnico y Core Web Vitals: la guía completa
El H1 de mi sitio tardaba 2,4 segundos en aparecer y no lo sabía. Así se diagnostica el SEO técnico que cuesta visibilidad.
El SEO técnico es el conjunto de configuraciones que permiten que un buscador descubra, rastree, indexe y entienda un sitio antes de evaluar su contenido. A diferencia del contenido y los enlaces, el SEO técnico se ocupa de cómo experimenta el sitio Google, no de cómo lo experimenta una persona, y por eso sus fallas son invisibles: la página se ve perfecta en pantalla mientras pierde visibilidad por algo que nadie revisó.
Esta guía recorre las capas que sostienen la salud técnica de cualquier sitio: crawlabilidad, indexación y crawl budget, Core Web Vitals (LCP, INP y CLS), datos estructurados y renderizado de JavaScript. La idea central es que la mayoría de las pérdidas de tráfico orgánico no nacen de malas decisiones de diseño ni de falta de artículos, sino de ajustes técnicos silenciosos: un H1 que depende de JavaScript, un parámetro que duplica URLs, una etiqueta noindex olvidada tras un rediseño. Se explica cada capa, cómo medirla y cómo priorizar los arreglos por impacto real.
Los problemas técnicos que más cuestan visibilidad rara vez son los más complejos: son los que nadie revisó porque el sitio se veía bien. El H1 de este propio sitio tardaba 2,4 segundos en pintarse porque dependía de JavaScript, y a simple vista nada parecía roto.
Qué cubre el SEO técnico y por qué es la base de todo lo demás
El SEO técnico es la capa sobre la que se apoyan el contenido y la autoridad. De nada sirve el mejor artículo si Google no puede rastrearlo, si lo descarta del índice o si tarda tanto en cargar que la experiencia se degrada. Conviene pensarlo como una secuencia: primero el robot descubre la URL, luego la rastrea, después decide si la indexa, más tarde la renderiza para entenderla y, recién entonces, la evalúa para posicionarla. Una falla en cualquier eslabón anula todo lo que viene después.
Esa secuencia se traduce en cinco frentes de trabajo que esta guía desarrolla uno por uno.
| Capa | Qué resuelve | Pregunta clave |
|---|---|---|
| Crawlabilidad | Que el robot pueda descubrir y acceder a las URLs | ¿Google llega a la página? |
| Indexación y crawl budget | Qué entra y qué no entra al índice | ¿Se indexa lo correcto? |
| Core Web Vitals | La calidad de la experiencia de carga e interacción | ¿Carga rápido y estable? |
| Datos estructurados | Que los motores entiendan y desambigüen las entidades | ¿El sitio se interpreta bien? |
| Renderizado de JavaScript | Que el contenido exista para el robot, no solo para el navegador | ¿Google ve el mismo contenido? |
Crawlabilidad: cómo Google descubre y rastrea el sitio
La crawlabilidad es la capacidad del robot de buscar, encontrar y acceder a las URLs de un sitio. Depende de tres piezas que conviene auditar juntas: el archivo robots.txt (que permite o bloquea rutas), el sitemap XML (que declara las URLs que importan) y el enlazado interno (que es el camino real por el que el robot navega de página en página).
Los errores de crawlabilidad más frecuentes son discretos y costosos. Un Disallow demasiado amplio en robots.txt que bloquea una sección entera. Páginas huérfanas sin ningún enlace interno que las apunte, por lo que el robot nunca las descubre. Cadenas de redirecciones 301 encadenadas que diluyen señales y consumen tiempo de rastreo. Un sitemap que lista URLs que devuelven 404 o que apunta a versiones con parámetros en lugar de las canónicas.
Indexación y crawl budget: qué entra y qué no al índice
Que una página se rastree no garantiza que se indexe. La indexación es la decisión del buscador de incluir la URL en su índice y, por tanto, de hacerla elegible para posicionar. Se controla con la etiqueta meta robots (index o noindex) y con la etiqueta canonical, que indica cuál es la versión preferida cuando existe contenido similar en varias URLs.
El crawl budget es la cantidad de recursos que Google dedica a rastrear un sitio en un periodo. En sitios grandes se vuelve crítico: si miles de URLs sin valor (combinaciones de filtros, parámetros de orden, resultados de búsqueda interna) consumen ese presupuesto, las páginas que sí deben posicionar se rastrean con menos frecuencia. El objetivo no es que Google rastree todo, sino que rastree lo correcto.
- Aplicar noindex, follow a páginas útiles para la navegación pero sin valor de búsqueda (filtros sin demanda, paginación profunda).
- Usar canonical para consolidar variantes hacia la URL principal y evitar contenido duplicado.
- Bloquear en robots.txt los parámetros sin valor SEO, como identificadores de sesión y órdenes de listado.
- Mantener el sitemap limpio: solo URLs indexables, canónicas y con respuesta 200.
Una pista práctica: cuando el informe de cobertura muestra muchas URLs en estado rastreada pero no indexada o descubierta pero no indexada, casi siempre el problema es de crawl budget o de contenido duplicado, no de calidad del texto.
Core Web Vitals explicados: LCP, INP y CLS
Los Core Web Vitals son las tres métricas con las que Google cuantifica la experiencia real de carga, interactividad y estabilidad visual de una página. Son señal de posicionamiento y, sobre todo, son el lenguaje con el que se traduce un problema técnico abstracto en algo medible. Cada métrica tiene un umbral de bueno, regular y malo definido por Google.
| Métrica | Qué mide | Bueno | Regular | Malo |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Cuánto tarda en pintarse el elemento más grande visible | Hasta 2,5 s | 2,5 a 4,0 s | Más de 4,0 s |
| INP (Interaction to Next Paint) | La latencia de respuesta a las interacciones del usuario | Hasta 200 ms | 200 a 500 ms | Más de 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se mueve el contenido de forma inesperada al cargar | Hasta 0,1 | 0,1 a 0,25 | Más de 0,25 |
INP reemplazó a FID (First Input Delay) en marzo de 2024 como métrica de interactividad, y es más exigente porque mide todas las interacciones a lo largo de la visita, no solo la primera. Conviene tener presente qué provoca cada métrica para saber dónde buscar: el LCP suele venir de imágenes pesadas, fuentes que bloquean el render o contenido que depende de JavaScript; el INP, de tareas largas en el hilo principal; el CLS, de imágenes y banners sin dimensiones reservadas.
¿Cuáles son los problemas técnicos invisibles que más cuestan rendimiento?
La experiencia directa optimizando este sitio dejó una lección clara: los arreglos de mayor impacto no eran visibles. El caso más ilustrativo fue el H1. El encabezado principal de la portada dependía de JavaScript para aparecer, de modo que tardaba en pintarse y arrastraba el LCP.
de retraso en el LCP por un H1 que dependía de JavaScript para renderizarse, sin ningún síntoma visible en pantalla
Fuente: Caso propio, cristobalcazor.com
Corregir ese tipo de problemas, que no cambian nada de lo que ve el usuario, fue lo que movió la aguja en las métricas de laboratorio y de campo.
de puntaje en PageSpeed Insights móvil tras corregir dependencias de render, sin alterar el diseño del sitio
Fuente: Caso propio, cristobalcazor.com
El sentido de invertir en esto se entiende mejor con el dato de negocio. Cada fracción de segundo de mejora en velocidad móvil tiene un efecto medible sobre la conversión.
de conversión retail por cada 0,1 segundos de mejora en la velocidad móvil
Fuente: Deloitte y Google, Milliseconds Make Millions, 2020
Cuando estas fallas técnicas se acumulan, el síntoma suele ser una caída sostenida de visibilidad sin causa aparente. Para diagnosticarla con método antes de tocar nada, sirve la guía sobre cómo abordar una caída en el tráfico orgánico.
Datos estructurados y desambiguación de entidades
Los datos estructurados son un vocabulario (Schema.org, en formato JSON-LD) que se añade al código para explicarle al motor qué representa cada cosa: una persona, un producto, un artículo, una empresa. Cumplen dos funciones. La primera, habilitar resultados enriquecidos en la SERP, como estrellas de reseñas, precios o preguntas frecuentes. La segunda, más estratégica, es desambiguar entidades: ayudar a que el motor conecte el sitio con la entidad correcta del mundo y no la confunda con otra de nombre parecido.
Esa segunda función gana peso con los motores de IA, que se apoyan en entidades bien definidas para decidir a quién citar. Una marca con su esquema Organization o Person bien construido (con sus propiedades sameAs apuntando a perfiles oficiales) le da al motor las señales que necesita para identificarla sin ambigüedad. El esquema se valida siempre en el validador de Schema.org antes de publicar.
Renderizado de JavaScript y su impacto en el SEO
El renderizado es el proceso por el que el contenido generado con JavaScript se convierte en HTML que el robot puede leer. Aquí está una de las fuentes de error más sutiles: lo que ve una persona en el navegador no siempre es lo que ve Google en el primer rastreo. Si el contenido principal (encabezados, texto, enlaces) depende de que se ejecute JavaScript, existe el riesgo de que el motor lo procese tarde o no lo procese.
El principio de control es simple: el contenido que importa para posicionar debería existir en el HTML que entrega el servidor, sin depender de la ejecución del cliente. El JavaScript queda para enriquecer la experiencia (animaciones, interacciones), no para entregar el contenido esencial. Renderizar en el servidor lo visible y dejar el cliente para lo accesorio es lo que evita sorpresas como el caso del H1 retrasado descrito antes.
Preguntas frecuentes sobre SEO técnico
¿Qué es exactamente el SEO técnico?
Es la parte del SEO que se ocupa de la infraestructura del sitio: que el robot pueda rastrear las URLs, que se indexe lo correcto, que las páginas carguen rápido y estables, que los datos estructurados estén bien y que el contenido exista para el motor y no solo para el navegador. No trabaja el texto ni los enlaces externos, sino las condiciones que permiten que esos factores se evalúen.
¿Cuál es la diferencia entre crawlabilidad e indexación?
La crawlabilidad es la capacidad del robot de descubrir y acceder a una URL; la indexación es la decisión posterior de incluirla o no en el índice. Una página puede rastrearse y aun así no indexarse, por ejemplo si lleva una etiqueta noindex o si una canonical la consolida hacia otra versión. Son dos eslabones distintos de la misma cadena.
¿Los Core Web Vitals son un factor de posicionamiento?
Sí, forman parte de las señales de experiencia de página de Google, aunque no son el factor de mayor peso. Su valor real va más allá del ranking: una mala experiencia de carga afecta la conversión de forma directa, y mejorar LCP, INP y CLS suele traducirse en más interacción y más ingresos, no solo en mejores métricas de laboratorio.
¿Por qué un problema técnico puede ser invisible en pantalla?
Porque el sitio se renderiza distinto para una persona y para el robot, y porque muchas configuraciones críticas viven en el código o en la cabecera de la respuesta, no en lo que se ve. Un H1 que depende de JavaScript, una etiqueta noindex heredada de un entorno de pruebas o un parámetro que duplica URLs no dejan ninguna huella visual, pero degradan el rendimiento orgánico.
¿Por dónde conviene empezar una auditoría de SEO técnico?
Por la base de la cadena: primero asegurar que las páginas importantes se rastrean e indexan (robots.txt, sitemap, cobertura en Search Console), porque cualquier mejora de velocidad o contenido es inútil si la URL no llega al índice. Recién después conviene atacar Core Web Vitals, datos estructurados y renderizado, priorizando siempre los arreglos por impacto sobre el negocio.
Medir ese impacto exige mirar más allá de las sesiones. El detalle de qué métricas observar para conectar el SEO técnico con resultados de negocio está en cómo medir el impacto real del SEO más allá del tráfico.
El SEO técnico como cimiento de toda estrategia
El SEO técnico no compite con el contenido ni con la autoridad: los hace posibles. Cuando la crawlabilidad, la indexación, los Core Web Vitals, los datos estructurados y el renderizado funcionan, cada artículo y cada enlace rinden lo que deben rendir. Y cuando algo falla en esa base, suele hacerlo en silencio, sin avisos visibles, costando visibilidad que nadie atribuye a su causa real. Revisar el sitio como lo experimenta Google, no como lo experimenta el usuario, es la diferencia entre adivinar y diagnosticar.
En Milimetrix auditamos la salud técnica de los sitios y priorizamos los arreglos por impacto, no por lo que se ve. Si un proyecto necesita una auditoría técnica o una hoja de ruta de optimización, conversemos.