Autor: admin

Google no mide solo palabras clave: también valora qué tan rápida y estable se siente tu web para quien la visita. Ahí entran los Core Web Vitals — tres métricas que resumen carga, interactividad y estabilidad visual. Si tu sitio falla en móvil, puedes perder posiciones aunque el contenido sea excelente.

Esta guía explica qué significan, qué umbrales usa Google y qué conviene medir primero — sin asumir que eres ingeniero de rendimiento.

Índice

• Qué son los Core Web Vitals
• Las tres métricas: LCP, INP y CLS
• Por qué importan para el SEO
• Umbrales: bueno, mejorable y malo
• Qué medir primero (y dónde mirar)
• Causas habituales de malas puntuaciones
• Checklist rápido antes de pedir ayuda
• Mitos frecuentes
• Preguntas frecuentes

Qué son los Core Web Vitals

Los Core Web Vitals (CWV) son un conjunto de métricas de rendimiento web que Google utiliza para evaluar la experiencia de página. No sustituyen a un buen contenido ni a una arquitectura técnica sana, pero sí pueden influir en el ranking cuando dos páginas compiten por la misma intención de búsqueda.

Desde 2021 forman parte de las señales de experiencia en la página. En la práctica, la mayoría de equipos los monitorizan porque:

• Reflejan lo que vive el usuario en móvil — donde ocurre la mayor parte del tráfico.
• Se pueden medir con herramientas gratuitas (PageSpeed Insights, Search Console).
• Corregirlos suele mejorar también conversiones y tasa de rebote, no solo SEO.

Las tres métricas: LCP, INP y CLS

LCP — Largest Contentful Paint (carga)

Mide cuánto tarda en aparecer el bloque principal de la página: un hero, una imagen grande o un titular destacado. Si el visitante ve pantalla en blanco demasiado tiempo, el LCP empeora. Es la métrica más visible para quien entra desde Google.

INP — Interaction to Next Paint (respuesta)

Sustituyó en gran medida al antiguo FID. Mide la latencia cuando el usuario interactúa: pulsa un botón, abre un menú, envía un formulario. Una web que «se siente lenta» al hacer clic suele tener INP alto, aunque el LCP sea aceptable.

CLS — Cumulative Layout Shift (estabilidad visual)

Cuenta cuánto «salta» el diseño mientras carga: un banner que empuja el texto, una fuente que cambia de tamaño, un anuncio que desplaza el botón de compra. Frustra al usuario y empeora la percepción de calidad.

Si quieres profundizar en el orden de prioridad para equipos técnicos, enlaza con nuestra guía SEO para desarrolladores: qué medir primero.

Por qué importan para el SEO

Google ha repetido que el contenido útil sigue siendo lo primero. Aun así, los CWV actúan como factor de desempate: ante dos URLs relevantes, la más rápida y estable tiene ventaja. Además:

• Rastreo más eficiente: páginas lentas consumen presupuesto de rastreo; Google puede indexar menos URLs de tu dominio.
• Mejor CTR indirecto: una web fluida retiene más; señales de engagement positivas refuerzan la visibilidad a medio plazo.
• Coherencia con mobile-first: Google indexa prioritariamente la versión móvil; los CWV se evalúan sobre todo en dispositivos reales.

Optimizar velocidad no es un truco de «hackear Google»: es alinear producto, UX y SEO. Proyectos con frontend moderno (por ejemplo sitios headless bien ejecutados) pueden facilitar buenos CWV, pero la arquitectura por sí sola no basta si las imágenes pesan megabytes o el servidor responde tarde.

Umbrales: bueno, mejorable y malo

Google publica rangos orientativos (pueden actualizarse; comprueba siempre la documentación oficial). Resumen práctico:

Métrica	Bueno	Necesita mejora	Malo
LCP	≤ 2,5 s	2,5 – 4,0 s	> 4,0 s
INP	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	≤ 0,1	0,1 – 0,25	> 0,25

Search Console agrupa URLs en «Bueno», «Necesita mejora» y «Mal» según datos de campo (usuarios reales de Chrome). PageSpeed Insights mezcla datos de laboratorio y de campo: útil para diagnosticar, pero no siempre coinciden al 100 %.

Qué medir primero (y dónde mirar)

1. Home y landings de conversión — suelen concentrar tráfico y clics desde búsqueda.
2. Plantillas de producto o servicio — un problema en la plantilla afecta a cientos de URLs.
3. Versión móvil — prioriza móvil aunque tu analytics diga que desktop convierte más.

Herramientas habituales (sin entrar en configuración):

• Google Search Console → Informe «Experiencia» → Core Web Vitals.
• PageSpeed Insights — URL concreta, recomendaciones por métrica.
• Lighthouse en el navegador — diagnóstico rápido en laboratorio (ideal en desarrollo).

Para el kit completo de medición, consulta DevTools para SEO: guía para desarrolladores.

Cuando domines las tres métricas, el siguiente paso es una auditoría PageSpeed práctica: interpretar PSI, comparar datos de laboratorio y campo, y priorizar qué arreglar. También puedes probar tu URL en el simulador PageSpeed de nuestra landing de SEO técnico.

Causas habituales de malas puntuaciones

LCP alto

• Imágenes hero sin comprimir o servidas en resolución excesiva.
• Servidor lento o sin caché (TTFB elevado).
• Fuentes o scripts que bloquean el renderizado inicial.

INP alto

• JavaScript pesado en la página principal.
• Widgets de terceros (chat, analytics, mapas) que compiten por el hilo principal.
• Formularios o filtros que recalculan demasiado al interactuar.

CLS alto

• Imágenes o vídeos sin reservar espacio (width/height).
• Banners o pop-ups que insertan contenido encima del fold.
• Fuentes web que cambian el tamaño del texto al cargar.

Muchas causas son transversales: no importa si usas WordPress clásico, un CMS headless o un framework moderno — el diagnóstico empieza por medir y priorizar.

Checklist rápido antes de pedir ayuda

1. ¿Tienes el informe de CWV en Search Console sin errores masivos de rastreo?
2. ¿Has probado la home y la landing principal en PageSpeed (móvil)?
3. ¿El problema afecta a una URL o a toda una plantilla?
4. ¿Los datos de campo (usuarios reales) confirman lo que ves en laboratorio?
5. ¿Has anotado qué cambió en el sitio antes de que empeoraran las métricas?

Si tras esto sigues en rojo, conviene una auditoría SEO técnica priorizada con plan de acción sobre LCP, INP y CLS — no un parche genérico. Para el workflow de medición paso a paso, revisa la guía práctica de auditoría PageSpeed.

Mitos frecuentes

«Con un 100 en Lighthouse ya estoy en el top 1»

Lighthouse es laboratorio. Google también mira datos de campo. Puedes tener 100 en local y «Necesita mejora» en Search Console.

«Los CWV lo arregla solo el hosting»

Un buen servidor ayuda al LCP, pero imágenes, scripts y diseño influyen igual. Cambiar de plan sin medir suele ser caro e ineficaz.

«Solo importan en e-commerce»

Cualquier sitio que compita en búsqueda se beneficia: blogs, landings B2B, webs corporativas.

«Un plugin de caché soluciona todo»

La caché mitiga TTFB y HTML, pero no arregla CLS por diseño ni INP por JavaScript excesivo.

Preguntas frecuentes

¿Cuánto tardan en mejorar los Core Web Vitals tras optimizar?

Los datos de campo en Search Console se actualizan en ciclos de 28 días aproximadamente. Tras desplegar mejoras, espera al menos un mes para ver tendencia estable.

¿Qué diferencia hay entre datos de campo y de laboratorio?

Campo: usuarios reales, redes y dispositivos variados — lo que usa Google para CWV en ranking. Laboratorio: simulación controlada — ideal para depurar, pero no siempre refleja tu audiencia.

¿Debo optimizar desktop o móvil primero?

Móvil. Es el referente principal del índice mobile-first y donde suelen aparecer los peores LCP e INP.

¿Los Core Web Vitals sustituyen al contenido?

No. Una web rápida con contenido pobre no rankea. Primero asegura indexación y relevancia; luego afina CWV para ganar el desempate.

Cada vez más empresas escuchan la expresión WordPress headless con Next.js, pero pocas explican qué significa en la práctica — y menos aún cómo afecta al posicionamiento en Google. Esta guía va directo al punto: conceptos claros, beneficios reales y cuándo merece la pena considerarlo.

No necesitas ser desarrollador para entender la idea. Sí conviene saber qué esperar antes de invertir en una arquitectura distinta a la de un WordPress tradicional con tema.

Índice

• Qué es WordPress headless con Next.js
• Ventajas para SEO y rendimiento
• Cuándo tiene sentido (y cuándo no)
• Qué revisar antes de lanzar
• Mitos frecuentes
• Preguntas frecuentes

Qué es WordPress headless con Next.js

En un WordPress clásico, el mismo sistema genera el contenido y la web que ve el visitante: entras al panel, escribes un post y el tema PHP lo muestra tal cual.

En un enfoque headless (sin cabeza pública), WordPress se queda como gestor de contenido: ahí creas páginas, entradas de blog, imágenes y textos. Pero la web que navega el usuario — y la que rastrea Google — la construye otra herramienta. En muchos proyectos modernos, esa capa es Next.js, un framework muy usado para sitios rápidos y escalables.

En resumen: WordPress headless con Next.js = contenido en WordPress + experiencia web en Next.js. Los dos hablan entre sí, pero cada uno hace lo suyo.

Ventajas para SEO y rendimiento

Google premia sitios útiles, rápidos y técnicamente sanos. Un proyecto headless bien ejecutado puede ayudar en tres frentes:

1. Velocidad de carga

Los temas WordPress genéricos suelen cargar muchos scripts y estilos que no usa cada página. Un frontend dedicado puede servir solo lo necesario, lo que mejora métricas como LCP — uno de los Core Web Vitals que conviene medir primero.

2. Control del HTML público

El SEO depende del HTML que recibe Google: títulos, descripciones, enlaces internos, datos estructurados. Separar contenido y presentación permite optimizar esa capa sin tocar el flujo de trabajo del equipo editorial en WordPress.

3. Escalabilidad del producto

Si tu web no es solo un blog — landings de servicios, herramientas interactivas, áreas de cliente — Next.js encaja mejor que un tema monolítico. Más flexibilidad suele traducirse en mejor experiencia de usuario, y eso también influye en señales de calidad.

Cuándo tiene sentido (y cuándo no)

Situación	¿Headless + Next.js?
Empresa con web corporativa, blog y landings de servicio	Sí, si buscas rendimiento y crecimiento a medio plazo
Blog personal o web pequeña con pocos cambios al año	Probablemente no — un buen tema WordPress basta
Tienda online estándar con WooCommerce y poco presupuesto técnico	Evaluar con cuidado — la complejidad sube
SEO y velocidad como ventaja frente a la competencia	Sí, es uno de los motivos más habituales
Equipo sin desarrolladores y sin agencia de mantenimiento	No recomendable — requiere soporte técnico continuo

Headless no es moda: es una apuesta por separar contenido y producto web. Si tu prioridad es publicar posts ocasionales sin tocar código, quédate en WordPress clásico. Si compites por posiciones en Google en sectores exigentes, merece estudiarse.

Qué revisar antes de lanzar

Antes de dar por bueno un proyecto wordpress headless nextjs, valida lo esencial — sin entrar en detalles de implementación:

1. Velocidad en móvil: prueba las páginas clave con PageSpeed Insights o un simulador. Si fallan en móvil, el SEO sufrirá.
2. Indexación en Google: revisa Search Console. Las URLs importantes deben rastrearse sin errores masivos.
3. Títulos y descripciones únicos: cada página necesita su propio snippet en resultados de búsqueda.
4. Enlaces internos: blog, servicios y contacto deben conectarse de forma lógica.
5. Experiencia editorial: el equipo que escribe contenido debe poder publicar en WordPress sin fricción.

Para profundizar en herramientas de medición, consulta nuestra guía de DevTools para SEO.

Mitos frecuentes

«Headless es malo para SEO»

Falso. Google indexa la web pública, no el panel de WordPress. Si esa capa es rápida, clara y sin errores, headless puede posicionar igual o mejor que un tema genérico.

«WordPress deja de servir para algo»

Tampoco. Sigue siendo el corazón del contenido. Lo que cambia es quién pinta la fachada del edificio.

«Next.js solo es para developers de Silicon Valley»

Es tecnología de uso extendido en agencias y productos digitales. Lo relevante no es la etiqueta, sino tener quien lo mantenga.

«Migrar a headless arregla el SEO de un día para otro»

La arquitectura ayuda, pero el contenido, la autoridad y la monitorización continua siguen siendo imprescindibles.

Preguntas frecuentes

¿Cuánto cuesta un proyecto WordPress headless con Next.js?

Depende del alcance: número de plantillas, idiomas, integraciones y mantenimiento. Suele costar más que un tema premium, pero menos que rehacer la web cada dos años por problemas de rendimiento.

¿Puedo seguir editando contenido como siempre?

En la mayoría de setups, sí. WordPress sigue siendo el panel de edición. Lo que cambia es cómo se ve ese contenido en la web final.

¿Es compatible con SEO en varios idiomas?

Sí, pero requiere planificación. Lo importante es que cada versión de una página sea clara para Google y para el usuario, sin duplicar contenido sin criterio.

¿Qué diferencia hay con «Next.js vs WordPress clásico para SEO»?

Este post explica la combinación de ambos. La comparación directa entre enfoques la abordamos en un artículo dedicado del blog.

Cuando un desarrollador habla de SEO suele imaginar keywords y meta descriptions. Pero el posicionamiento real empieza antes: en el servidor, en el código que genera el HTML y en los encabezados HTTP que nunca ves a simple vista. El SEO para desarrolladores no trata de escribir buen copy; trata de construir una base técnica que no frene a Google.

El problema es que hay docenas de métricas posibles. Esta guía te da el orden correcto para medir primero lo que más impacta, sin perderte en un océano de datos.

Índice

• La pirámide del SEO técnico
• 1. Rastreo: lo primero que medir
• 2. Indexación correcta
• 3. Core Web Vitals
• 4. Velocidad en móvil
• La pila de medición en 2026
• Integrarlo en tu flujo de trabajo
• Preguntas frecuentes

La pirámide del SEO técnico

La mayoría de los artículos listan métricas sin jerarquía. Pero el SEO técnico tiene una lógica de capas: si la capa inferior falla, las de arriba no sirven de nada.

1. Rastreo — ¿puede Googlebot llegar al contenido?
2. Indexación — ¿entiende Google qué URL es la canónica y en qué idioma?
3. Rendimiento — ¿cumple los umbrales de Core Web Vitals?
4. Contenido y autoridad — ¿responde mejor que la competencia?

Un desarrollador puede influir en las tres primeras capas directamente. La cuarta depende del equipo editorial, pero también se beneficia de una estructura de URLs limpia y un buen enlazado interno.

1. Rastreo: lo primero que medir

Si Googlebot no puede rastrear una página, no existe para el buscador. Los errores de rastreo más frecuentes en sitios con frontend moderno (React, Next.js) o CMS desacoplado — por ejemplo un proyecto WordPress headless con Next.js — son:

Errores 5xx

Una respuesta del servidor (timeout, error de API del CMS, SSR fallido) le dice a Google que la página no está disponible. Unos pocos 5xx intermitentes en rutas secundarias son tolerables; en la home o landings de servicio son críticos. Monitoriza en Search Console → Cobertura → Error de servidor (5xx).

Redirects en cadena

Un redirect 301 es correcto; tres redirects en cadena (/contacto → /contacto/ → /es/contacto/) consumen presupuesto de rastreo y pueden confundir la atribución de PageRank. Apunta siempre al destino final en un solo salto cuando sea posible.

robots.txt mal configurado

Un Disallow: / accidental en producción bloquea todo el sitio. Verifica https://tudominio.com/robots.txt antes de cada deploy. En Next.js (y otros frameworks) puedes definirlo de forma versionada en el repositorio.

JavaScript que bloquea el rastreo

Si el contenido crítico solo existe en el DOM tras ejecutar JavaScript, Googlebot puede no verlo en el primer rastreo. Server Components en Next.js App Router eliminan este problema: el HTML llega completo en la primera respuesta.

2. Indexación correcta

Que Googlebot llegue a tu página no garantiza que la indexe bien. Hay tres señales que Google comprueba para decidir qué URL indexar:

Canonical

El <link rel="canonical"> le dice a Google cuál es la URL definitiva. En sitios multiidioma, cada página debe tener su propio canonical apuntando a su versión con locale:

<!-- correcto -->
<link rel="canonical" href="https://tudominio.com/es/servicio/" />

<!-- incorrecto: apunta al CMS o subdominio de administración -->
<link rel="canonical" href="https://cms.tudominio.com/servicio/" />

Valida siempre en View Source de la URL pública, no en React DevTools.

hreflang

En sitios EN + ES, cada página necesita las etiquetas hreflang correctas. Un error típico es apuntar hreflang="en" a la misma URL en lugar de a la versión EN:

<link rel="alternate" hreflang="en" href="https://tudominio.com/en/service/" />
<link rel="alternate" hreflang="es" href="https://tudominio.com/es/servicio/" />

Si el CMS gestiona traducciones y el frontend las consume por API, configura hreflang en la capa que genera el HTML público (p. ej. generateMetadata en Next.js).

Sitemap coherente

El sitemap debe listar solo las URLs canónicas e indexables. Una URL que aparece en el sitemap pero tiene noindex crea una señal contradictoria que Google resuelve a su criterio. Genera el sitemap dinámicamente desde la misma fuente de datos que las rutas.

3. Core Web Vitals

Google usa los Core Web Vitals como señal de ranking desde 2021. En 2026 el peso ha aumentado para búsquedas móviles. Las tres métricas que debes monitorizar:

Métrica	Qué mide	Umbral verde
LCP (Largest Contentful Paint)	Tiempo hasta que el elemento visual más grande es visible	< 2,5 s
INP (Interaction to Next Paint)	Respuesta a interacciones del usuario (clics, teclado)	< 200 ms
CLS (Cumulative Layout Shift)	Estabilidad visual: el contenido no debe moverse al cargar	< 0,1

Causas frecuentes de LCP alto

• Imagen hero sin priority en next/image: el navegador la descarga tarde.
• Fuentes web bloqueantes: usa font-display: swap o cárgalas con next/font.
• TTFB alto por SSR lento: revisa consultas lentas al CMS/API o ausencia de caché o regeneración incremental.

Causas frecuentes de CLS alto

• Imágenes sin dimensiones (width y height explícitos o aspect-ratio en CSS).
• Banners o cookies que aparecen tarde y empujan el contenido.
• Fuentes que sustituyen al web font del sistema con métricas distintas.

4. Velocidad en móvil: la métrica que más se ignora

PageSpeed Insights ofrece dos pestañas: datos de laboratorio (Lighthouse) y datos de campo (CrUX). Los datos de campo son los que Google usa para ranking. En sitios nuevos o con poco tráfico, CrUX estará vacío; en ese caso los datos de laboratorio son tu mejor proxy.

Comprueba siempre en modo móvil con red simulada 4G, no solo en escritorio. Un sitio con 95 de Lighthouse en desktop puede tener 60 en móvil por imágenes no optimizadas o JavaScript excesivo.

Puedes simular este análisis directamente en el simulador de PageSpeed de Veloce Devs sin instalar nada.

La pila de medición en 2026

Estas herramientas cubren las cuatro capas de la pirámide en la mayoría de proyectos:

Herramienta	Qué mide	Gratuita
Google Search Console	Rastreo, indexación, CWV de campo, sitemaps	Sí
PageSpeed Insights	CWV de laboratorio + campo, auditoría Lighthouse	Sí
Screaming Frog (free tier)	Rastreo masivo, redirects, canonicals, meta tags	Sí (500 URLs)
curl / httpstatus	Cadenas de redirect, headers HTTP, status codes	Sí
Suite SEO / rank tracking	Keywords, rankings, auditoría recurrente	Varía (p. ej. servicios SEO de Veloce Devs)

Integrarlo en tu flujo de trabajo

Medir una vez no sirve de nada. El SEO técnico se mantiene integrando comprobaciones en el ciclo de desarrollo:

En cada pull request

• ¿El cambio afecta a rutas o slugs? → Añadir redirect si se elimina una URL existente.
• ¿Se añaden imágenes nuevas? → Verificar alt descriptivo y formato WebP/AVIF.
• ¿Nuevo componente con JS pesado? → Comprobar impacto en bundle con @next/bundle-analyzer.

Semanal

• Revisar Search Console: nuevos errores 5xx, 404 o páginas «Rastreadas, sin indexar».
• Comprobar Core Web Vitals en las landing pages principales.

Mensual

• Auditoría con Screaming Frog o similar: redirects en cadena, títulos duplicados, páginas huérfanas.
• Comparar impresiones y posiciones en GSC con el mes anterior.
• Revisar sitemap: ¿incluye todas las URLs nuevas y excluye las de noindex?

Preguntas frecuentes

¿Con qué empiezo si el sitio ya está en producción con problemas?

Empieza por Search Console: resuelve primero los errores 5xx (afectan rastreo), luego los canonicals incorrectos (afectan indexación), y finalmente los CWV fuera de rango (afectan ranking). En ese orden obtienes el mayor impacto con el menor esfuerzo.

¿Los Core Web Vitals son el factor SEO más importante?

No. Son un factor de desempate cuando el contenido es de calidad similar. Primero asegúrate de que las páginas se rastrean e indexan correctamente; luego optimiza rendimiento. Una página con LCP perfecto pero sin indexar no posiciona.

¿Next.js App Router ya resuelve el SEO automáticamente?

Resuelve mucho: Server Components generan HTML completo, generateMetadata centraliza los meta tags, y next/image optimiza formatos. Pero sigue siendo responsabilidad tuya configurar canonicals, hreflang, sitemap coherente y evitar errores HTTP en producción.

¿Cuánto tiempo tarda en verse el impacto de correcciones técnicas?

Depende de la frecuencia de rastreo del sitio. Dominios nuevos o con poco tráfico pueden tardar de 2 a 8 semanas. Usa Inspección de URL → Solicitar indexación en Search Console para acelerar páginas clave tras cada corrección importante.

Si escribes código, el SEO no es algo que puedas delegar por completo a marketing. La mayoría de los fallos de posicionamiento empiezan en ingeniería: JavaScript que bloquea el rastreo, etiquetas canonical rotas, Core Web Vitals fuera de rango o sitemaps que no coinciden con tu arquitectura real de URLs. Las devtools para SEO existen para cerrar esa brecha entre desarrollo y visibilidad orgánica.

Esta guía recorre el kit esencial para desarrolladores —desde el navegador hasta CI/CD— con recursos oficiales y un flujo de trabajo que puedes aplicar en tu repositorio hoy.

Índice

• Por qué el SEO es responsabilidad del desarrollador
• DevTools del navegador (Chrome y Edge)
• Lighthouse y PageSpeed Insights
• Google Search Console
• Rastreo, logs y CLI
• SEO en arquitecturas headless
• Checklist pre-deploy para devs
• Preguntas frecuentes

Por qué el SEO es responsabilidad del desarrollador

Google no indexa promesas de marketing: indexa HTML servido, respuestas HTTP, enlaces internos y señales de rendimiento. Cuando un sitio tarda más de tres segundos en móvil o devuelve 5xx en rutas sin locale, el daño ocurre antes de que alguien escriba una meta description.

Los equipos que mejor rinden suelen compartir un patrón: los desarrolladores validan SEO técnico en cada pull request y marketing se centra en intención de búsqueda y contenido. No necesitas ser consultor SEO; necesitas saber qué medir y dónde mirar.

DevTools del navegador (Chrome y Edge)

Chrome DevTools (y equivalentes en Edge) son la primera línea de defensa. Estas pestañas importan más en auditorías:

1. Lighthouse

Genera puntuaciones de rendimiento, accesibilidad, buenas prácticas y SEO básico para la URL cargada. Usa modo incógnito con extensiones desactivadas para evitar falsos positivos.

2. Network

Filtra por Doc, JS y CSS. Busca:

• Recursos que bloquean el render (CSS crítico ausente, JS síncrono en <head>).
• Respuestas 404 o cadenas de redirect (301 → 301 → 200).
• TTFB alto en documentos HTML (servidor, caché o SSR lento).

3. Coverage

Muestra cuánto JS/CSS descargado no se usa en la vista actual — ideal para detectar bundles hinchados en landings ligeras.

4. Elements + búsqueda de meta tags

Con Ctrl+F dentro de Elements, verifica en el HTML servido:

• Un solo <title> y un <meta name="description"> por página.
• <link rel="canonical"> apuntando a la URL canónica.
• hreflang coherente en sitios multilingües (en, es, x-default cuando aplique).
• noindex accidental en producción.

Lighthouse y PageSpeed Insights

Lighthouse local mide la sesión actual; PageSpeed Insights añade datos de campo (CrUX) cuando existen. En sitios nuevos sin tráfico, CrUX estará vacío — confía en datos de laboratorio y Search Console.

Puedes probar tu dominio con PageSpeed Insights o herramientas como el simulador PageSpeed de nuestra landing SEO. Puntuaciones rojas suelen indicar problemas de LCP (hero sin prioridad, fuentes bloqueantes) o INP (demasiado JavaScript en el hilo principal).

Referencias objetivo:

• LCP < 2,5 s
• INP < 200 ms
• CLS < 0,1
• Puntuación SEO Lighthouse ≥ 90 en plantillas principales

Google Search Console

Search Console es la fuente de verdad de cómo Google ve tu sitio. Como desarrollador, revisa semanalmente:

• Páginas → Indexación: 5xx, 404, “Rastreadas, sin indexar” y redirects innecesarios.
• Sitemaps: envía https://tudominio.com/sitemap.xml y confirma que las URLs canónicas coinciden.
• Core Web Vitals: URLs en rojo/ámbar que requieren cambios de código, no de copy.
• Inspección de URL: prueba una URL recién desplegada y solicita indexación tras corregir canonicals o hreflang.

Rastreo, logs y CLI

Cuando el sitio crece, el navegador no escala. Añade herramientas CLI al flujo:

Herramienta	Propósito
curl -I URL	Comprobar status HTTP, Location, headers de caché y redirects.
Screaming Frog (free tier)	Rastrear enlaces rotos, títulos duplicados, meta vacíos y profundidad de clic.
npx lighthouse URL --view	Auditorías repetibles en CI o scripts locales.
Validadores de schema	Probar JSON-LD (Organization, FAQPage, BlogPosting) antes de publicar.

Ejecutar Lighthouse en GitHub Actions o tu pipeline de CI/CD evita regresiones cuando alguien añade un script de terceros “solo para probar”.

SEO en arquitecturas headless

En setups desacoplados (CMS + frontend separado), el SEO se reparte así:

• Frontend (p. ej. Next.js): API de metadata, sitemap, robots.txt, HTML semántico, SSR/ISR.
• CMS (p. ej. WordPress): contenido, metadatos del plugin SEO, traducciones, campos custom expuestos por API.
• CDN: HTTPS, compresión, reglas de caché sin romper HTML dinámico.
• Monitorización: keywords, rankings y auditorías recurrentes a medida que crece el sitio.

La investigación de keywords y el seguimiento de posiciones complementan Lighthouse (rendimiento puntual) con datos SERP continuos. Explora opciones en nuestra página de servicios SEO si necesitas una suite gestionada.

Si evalúas un CMS desacoplado con frontend moderno, la guía WordPress headless con Next.js: qué es y por qué importa para el SEO resume ventajas, mitos y cuándo tiene sentido.

Checklist pre-deploy para desarrolladores

Añade esta lista a tu plantilla de PR o wiki del repo:

1. ¿Canonical y hreflang presentes en HTML servido (View Source, no solo React DevTools)?
2. ¿El sitemap incluye solo URLs indexables (sin borradores, sin noindex)?
3. ¿Un H1 por vista y jerarquía H2/H3 lógica?
4. ¿Imágenes con alt descriptivo y formatos modernos (WebP/AVIF)?
5. ¿Lighthouse móvil ≥ 90 en rendimiento y SEO en plantillas afectadas?
6. ¿Redirects 301 para URLs legacy y rutas sin locale?
7. ¿Search Console sin nuevos 5xx o 404 tras el deploy?
8. ¿Datos estructurados validados sin errores críticos?

¿Prefieres una revisión integral? Solicita una auditoría SEO técnica con roadmap priorizado.

Preguntas frecuentes

¿Lighthouse basta para SEO?

No. Lighthouse cubre señales técnicas básicas y rendimiento, pero no sustituye Search Console (indexación real), análisis de keywords o auditorías de enlazado interno a gran escala.

¿Qué es “SEO dev” en la práctica?

Aplicar SEO técnico dentro del ciclo de desarrollo: metadata en componentes de servidor, URLs limpias, rendimiento, schema y monitorización post-deploy — en lugar de parchear problemas tras el lanzamiento.

¿Debo usar plugins SEO en WordPress headless?

Sí en el CMS (Yoast, Rank Math u otro — con extensión API/GraphQL si hace falta) para que el frontend consuma títulos y descriptions. El frontend público genera el HTML: valida siempre la salida en producción.

¿Cuánto tarda Google en indexar correcciones técnicas?

De horas a varias semanas según autoridad y presupuesto de rastreo. Tras corregir canonicals o sitemap, usa Inspección de URL en Search Console para acelerar páginas clave.