Categoría: Seo Técnico

Una checklist de auditoría SEO no sustituye a un informe completo — pero sí evita el caos de «revisamos de todo un poco» y acabamos con veinte tickets sin prioridad. Si eres desarrollador, tech lead o PM con responsabilidad sobre el front, esta lista te da un recorrido ordenado: de lo que puede bloquear la indexación a lo que afina CTR y rich results.

El orden importa. Primero confirmas que Google puede indexar; después arreglas URLs, contenido técnico, velocidad y enlaces. Si quieres el contexto narrativo de cada bloque, complementa con nuestra auditoría SEO técnica paso a paso; aquí el foco es ejecutar y marcar casillas.

Índice

• Antes de empezar: URLs y herramientas
• Fase 1 — Indexación y rastreo
• Fase 2 — Arquitectura y URLs
• Fase 3 — On-page técnico
• Fase 4 — Rendimiento y Core Web Vitals
• Fase 5 — Enlaces internos y datos estructurados
• Cómo puntuar y priorizar hallazgos
• Errores que invalidan la auditoría
• Preguntas frecuentes

Antes de empezar: URLs y herramientas

No audites «el sitio entero» en abstracto. Elige una muestra representativa — suele bastar con 8–15 URLs:

• Home y 2–3 landings de servicio o producto.
• 1–2 entradas de blog con tráfico orgánico (Search Console).
• 1 plantilla de categoría o listado si aplica.
• 1 URL problemática que ya sospeches (404, lenta, duplicada).

Herramientas mínimas (gratuitas):

• Google Search Console — indexación, sitemap, CWV de campo.
• PageSpeed Insights — laboratorio + datos de campo por URL.
• Rich Results Test — schema y elegibilidad SERP.
• DevTools del navegador — red, consola, View Source.
• Rastreador desktop (Screaming Frog, Sitebulb, etc.) — opcional pero muy útil en sitios >50 URLs.

Si aún no tienes claro qué medir antes de abrir tickets, repasa SEO para desarrolladores: qué medir primero y la guía de DevTools para SEO.

Fase 1 — Indexación y rastreo

Si Google no indexa, nada de lo demás compite. Marca cada ítem; cualquier ❌ aquí es prioridad crítica.

• ☐ Propiedad correcta en Search Console (dominio o prefijo de URL coherente con producción).
• ☐ robots.txt no bloquea secciones indexables (blog, landings, fichas).
• ☐ URLs clave sin noindex accidental (meta robots o cabecera HTTP).
• ☐ Sitemap XML accesible, sin errores de procesamiento y alineado con URLs públicas.
• ☐ Inspección de URL en GSC: «URL está en Google» en home + 3 URLs de negocio.
• ☐ Canonical declarada = canonical seleccionada por Google (sin conflictos masivos).
• ☐ Sin picos de «Descubierta: no indexada» o «Duplicada» sin explicación en el informe de páginas.
• ☐ Respuestas HTTP correctas: 200 en contenido, 301 (no cadenas largas) en migraciones, 404 limpios donde toca.

Señal de alerta: plantillas de producto o blog con tráfico histórico que pasan a «Excluida» tras un deploy. Para el flujo completo de esta fase, ver el paso 1 de la auditoría técnica paso a paso.

Fase 2 — Arquitectura y URLs

• ☐ HTTPS en todo el sitio; una sola variante canónica de host (www vs no-www, barra final consistente).
• ☐ Redirecciones: máximo un salto 301 por URL migrada; sin bucles ni 302 permanentes por error.
• ☐ Profundidad de clic: páginas importantes a ≤3 clics desde home.
• ☐ Slugs legibles, estables y en el idioma correcto (sin mezclar /es/blog/english-slug/).
• ☐ Multidioma: hreflang recíproco y coherente si hay ES/EN u otros locales.
• ☐ Parámetros, filtros y ordenaciones: no generan miles de URLs indexables duplicadas.
• ☐ Subdominios de preview, staging o API no indexables ni enlazados desde producción.
• ☐ Sitemap y enlaces internos apuntan al dominio público, no al CMS oculto.

Fase 3 — On-page técnico

Recorre cada plantilla de la muestra (home, landing, artículo):

• ☐ Un solo <h1> claro por URL; jerarquía H2/H3 lógica.
• ☐ <title> único (~50–60 caracteres útiles) y meta description que invite al clic sin relleno.
• ☐ Canonical autoreferenciada salvo reglas de sindicación explícitas.
• ☐ Contenido principal visible en el HTML inicial (View Source muestra titular y cuerpo).
• ☐ Imágenes con alt descriptivo; formatos modernos (WebP/AVIF) cuando sea posible.
• ☐ Open Graph y Twitter Card básicos en plantillas compartibles.
• ☐ Paginación con enlaces crawlables o señales claras (no solo botones JS sin fallback).
• ☐ Sin títulos o descriptions duplicados masivos en la muestra del rastreo.

Fase 4 — Rendimiento y Core Web Vitals

Google usa señales de experiencia; LCP, INP y CLS resumen carga, respuesta e estabilidad. En la checklist:

• ☐ PageSpeed Insights en móvil para las 3–5 URLs con más impresiones o conversión.
• ☐ Informe Core Web Vitals en Search Console sin URLs «Poor» en plantillas de negocio.
• ☐ LCP: elemento principal identificado (hero, imagen producto, titular) y optimizado.
• ☐ INP: interacciones clave (menú, filtros, CTA) sin bloqueos largos del hilo principal.
• ☐ CLS: imágenes y embeds con dimensiones reservadas; banners que no empujan contenido.
• ☐ TTFB razonable en plantillas dinámicas (no confundir caché puntual con rendimiento real).
• ☐ Terceros auditados: analytics, chat, tags — cargan después del contenido crítico cuando sea posible.

Conceptos en profundidad: Core Web Vitals: qué son y qué medir. Para el workflow de velocidad paso a paso, usa la guía práctica de auditoría PageSpeed.

¿Quieres una primera foto rápida antes del informe largo? En la landing de SEO técnico tienes el simulador PageSpeed para probar una URL de tu muestra.

Fase 5 — Enlaces internos y datos estructurados

Enlaces internos

• ☐ Páginas nuevas enlazadas desde home, blog o landings relevantes.
• ☐ Sin enlaces rotos (404) en menús, footer o contenido legacy.
• ☐ Anclas descriptivas en enlaces contextuales (no solo «haz clic aquí»).
• ☐ Cluster temático: artículos relacionados se enlazan entre sí (auditoría, velocidad, arquitectura).

Datos estructurados

• ☐ Organization / WebSite en home sin errores críticos.
• ☐ Article o BlogPosting en entradas del blog.
• ☐ FAQPage solo donde las preguntas son visibles en la página.
• ☐ Product, LocalBusiness u otros tipos solo si aplican al negocio real.
• ☐ Rich Results Test sin errores que bloqueen el tipo de resultado esperado.

Guía de implementación en stacks modernos: Schema.org con Next.js.

Cómo puntuar y priorizar hallazgos

Cuando termines las cinco fases, no abras veinte tickets a la vez. Clasifica cada hallazgo:

Severidad	Ejemplos de la checklist	Acción
Crítica	noindex masivo, 5xx, migración sin 301, robots.txt bloqueando /blog/	Parar campañas; corregir en horas o días
Alta	Canonical incorrecta, sitemap roto, CWV «Poor» en URLs money	Sprint actual
Media	Titles duplicados, imágenes pesadas, enlaces rotos secundarios	Backlog 2–4 semanas
Baja	Schema opcional, micro-optimizaciones de alt	Cuando haya capacidad

Entrega un documento con: URL, evidencia (captura o export), severidad, responsable (dev, contenido, infra) y criterio de cierre. Una checklist de auditoría SEO que no termina en acciones concretas es solo una lista bonita en Notion.

Si tras la checklist valoras ayuda externa, consulta cuánto cuesta el SEO técnico para entender modelos de precio y qué debe incluir un presupuesto serio.

Errores que invalidan la auditoría

Medir solo la home en desktop con WiFi perfecto

Las plantillas que escalan (categoría, producto, artículo) suelen ser las que fallan en móvil. La home puede estar bien mientras el resto pierde tráfico.

Confundir puntaje Lighthouse con SEO

Un 100 en laboratorio no garantiza posición. CWV de campo y indexación importan tanto o más.

Ignorar el HTML inicial

Si View Source está vacío y el contenido solo aparece tras JavaScript, la checklist de on-page puede marcarse ✅ en DevTools pero ❌ para Google.

Arreglar schema antes que canonicals

Rich results no compensan URLs duplicadas o no indexadas. Respeta el orden de las fases.

No repetir la checklist tras cambios grandes

Rediseños, plugins nuevos o migraciones headless requieren pasar la lista otra vez — no asumas que «ya lo hicimos en enero».

Preguntas frecuentes

¿Cuánto tarda pasar esta checklist?

Con muestra de 10 URLs y herramientas abiertas: medio día a un día para una persona que conoce el proyecto. Sitios grandes necesitan rastreo automatizado y validación con desarrollo — de dos a cinco días.

¿Checklist vs auditoría SEO completa?

La checklist es el esqueleto operativo; la auditoría completa añade profundidad (enlaces externos, contenido, competencia). Empieza aquí si necesitas orden rápido; profundiza con la guía paso a paso si hay caída de tráfico.

¿Puedo automatizar parte de la lista?

Sí: rastreos programados, alertas de uptime, CI con Lighthouse, informes CWV. La interpretación de canonicals, hreflang y cambios de producto sigue necesitando criterio humano.

¿Con qué frecuencia repetirla?

Trimestral en sitios activos; mensual durante migraciones o lanzamientos grandes. Search Console alerta sobre picos, pero no sustituye una revisión programada.

¿Qué hago después de marcar todo?

Prioriza críticos y altos, asigna responsables y mide de nuevo en 4–6 semanas. Para velocidad, vuelve a PageSpeed Insights o al simulador de la landing SEO con las mismas URLs de la muestra.

En reuniones de producto o con tu agencia, tarde o temprano aparece la duda: páginas estáticas o dinámicas para SEO. Suena a decisión técnica, pero en el fondo es otra cosa: ¿Google recibe HTML claro y rápido, o una pantalla que tarda en armarse en el navegador?

Aquí no vas a encontrar código. Solo queremos ayudarte a entender qué significa cada opción, qué le importa a Google y cuándo tiene sentido mezclar enfoques — como hacen muchos sitios modernos con generación estática más actualizaciones periódicas.

Índice

• Qué significa estática y dinámica en SEO
• Qué ve Google en cada caso
• SSG, SSR, CSR e ISR — en lenguaje claro
• Cuándo conviene lo estático
• Cuándo necesitas dinámico
• El enfoque híbrido (lo más habitual hoy)
• Errores que vemos a menudo
• Checklist rápido antes de decidir
• Mitos frecuentes
• Preguntas frecuentes

Qué significa estática y dinámica en SEO

Página estática (en sentido SEO): el servidor entrega HTML casi listo. El contenido principal — titular, texto, enlaces — ya está ahí cuando llega la respuesta. Google no tiene que esperar a que un montón de JavaScript «monte» la página desde cero.

Página dinámica: el HTML se genera en el momento de la petición o gran parte del contenido aparece después, en el navegador, cuando ya cargaron scripts y datos. Puede ser perfecto para un panel de usuario; para una landing que quieres posicionar, exige más cuidado.

Importante: «estática» no significa «nunca cambia». Una home que se regenera cada cinco minutos con posts nuevos sigue siendo estática para Google si cada visita recibe HTML completo. Lo que importa es qué recibe el rastreador, no el nombre del framework.

Qué ve Google en cada caso

Google rastrea millones de URLs. Para decidir si indexar y posicionar, necesita:

• HTML con contenido — títulos, párrafos, enlaces internos.
• Respuesta rápida — páginas lentas consumen presupuesto de rastreo.
• Señales coherentes — canonical, meta description, hreflang si hay idiomas.

Si tu página dinámica devuelve HTML vacío y el texto solo aparece tras JavaScript, Google puede renderizarla — pero tarda más, falla más a menudo y compites en desventaja frente a una URL estática equivalente.

Prueba sencilla: abre tu URL en el navegador → clic derecho → Ver código fuente (no DevTools). ¿Ves el titular y el cuerpo del artículo? Si sí, vas bien encaminado. Si solo ves un contenedor vacío, hay trabajo SEO por delante.

SSG, SSR, CSR e ISR — en lenguaje claro

Los equipos técnicos usan siglas. Traducidas a SEO:

Enfoque	Qué pasa	SEO en una frase
SSG (estática)	HTML generado antes, servido tal cual	Muy favorable: rápido y predecible para rastreadores
SSR (dinámica en servidor)	HTML generado en cada petición en el servidor	Bien si el servidor responde rápido y el HTML llega completo
CSR (dinámica en navegador)	HTML mínimo; el contenido lo pinta JavaScript	Riesgo alto si no hay pre-renderizado o fallback
ISR (híbrido)	Estática que se regenera cada X tiempo	Equilibrio habitual: velocidad + contenido actualizable

Si estás valorando Next.js frente a WordPress clásico, la comparativa de arquitecturas encaja con nuestro artículo sobre Next.js vs WordPress para SEO. Si ya separaste CMS y frontend, la guía de WordPress headless con Next.js explica cómo encaja este reparto de roles.

Cuándo conviene lo estático

Prioriza HTML pregenerado cuando:

• El contenido cambia poco — landings de servicio, páginas legales, entradas de blog publicadas.
• El tráfico orgánico es clave — quieres LCP bajo y rastreo eficiente.
• La misma URL sirve lo mismo a casi todos — sin personalización por usuario.
• Tienes muchas URLs — catálogos, blog con cientos de posts; el coste de generar una vez y servir rápido escala mejor.

Las páginas estáticas suelen puntuar mejor en Core Web Vitals porque entregan menos sorpresas al cargar. Eso no garantiza el primer puesto, pero elimina una fricción habitual.

Cuándo necesitas dinámico

No todo puede — ni debe — ser estático:

• Datos en tiempo real — stock, precios que cambian cada minuto, disponibilidad de citas.
• Contenido por sesión — área privada, carrito, recomendaciones basadas en historial.
• Personalización fuerte — dashboards, portales B2B, resultados de búsqueda interna compleja.
• Formularios y flujos interactivos — simuladores, configuradores de producto.

La clave SEO: separa lo indexable de lo funcional. La ficha de producto puede ser estática o ISR; el checkout dinámico no necesita rankear. Mezclar ambos mundos con criterio evita bloquear conversiones por obsesionarse con SSG en toda la web.

El enfoque híbrido (lo más habitual hoy)

La mayoría de proyectos serios no eligen «todo estático» o «todo dinámico». Combinan:

• Blog y landings → generación estática o ISR (rápidas, indexables).
• API y áreas logadas → dinámico (donde importa la experiencia en vivo).
• Revalidación periódica → contenido fresco sin regenerar el sitio entero en cada clic.

Ese híbrido es justo lo que muchos equipos buscan al pasar de un WordPress monolítico a un frontend moderno: conservar el flujo editorial y ganar velocidad en lo público. Si quieres profundizar en rendimiento tras el cambio, la guía práctica de auditoría PageSpeed te ayuda a medir si la apuesta está funcionando.

Errores que vemos a menudo

Renderizar todo en cliente «porque es más moderno»

Single Page Apps sin pre-renderizado: Google puede indexar, pero compites con sitios que entregan HTML al instante. Para SEO transaccional o de contenido, suele ser mala apuesta.

Estático en build, vacío en producción

Generar páginas en despliegue pero no incluir datos reales del CMS — URLs en el sitemap con contenido placeholder o desactualizado.

Confundir caché con estático

Una página PHP con caché agresiva se siente estática, pero si la caché falla el TTFB se dispara. Mide comportamiento real, no solo la etiqueta del stack.

Indexar URLs que deberían ser privadas

Versiones dinámicas de área de cliente, parámetros de sesión o filtros infinitos generando duplicados. La arquitectura dinámica necesa reglas claras de canonical y robots.

Checklist rápido antes de decidir

1. ¿Qué URLs necesitan posicionarse en Google? (lista corta)
2. ¿El View Source de esas URLs muestra el contenido principal?
3. ¿Con qué frecuencia cambian? (diario / semanal / rara vez)
4. ¿Hay personalización por usuario en esas mismas URLs?
5. ¿El presupuesto de rastreo en Search Console muestra errores o lentitud?
6. ¿Has medido LCP en móvil en plantillas clave?

Si la mayoría de URLs estratégicas cambian poco y deben rankear, inclínate por estático o ISR. Si viven de datos en vivo, diseña dinámico con SSR o separación clara de rutas indexables.

Mitos frecuentes

«Google no indexa JavaScript»

Sí renderiza JS, pero con retraso y límites. No es equivalente a recibir HTML desde el primer byte.

«Estático = obsoleto»

Con revalidación programada, un blog estático puede actualizarse en minutos sin perder velocidad.

«Dinámico siempre es más lento para SEO»

SSR bien hecho en servidor cercano puede ser excelente. Lo lento es CSR puro en páginas que deberían indexarse.

«Hay que elegir uno para toda la web»

Los proyectos maduros mezclan por tipo de página. La pregunta correcta es «¿esta URL concreta debe ser estática o dinámica?»

Preguntas frecuentes

¿Las páginas estáticas rankean mejor que las dinámicas?

No hay factor de ranking «estático». Lo que ayuda es la velocidad, el HTML accesible al rastreo y la calidad del contenido — y lo estático suele facilitar esos tres.

¿Un WordPress clásico es estático o dinámico?

Dinámico en origen (PHP genera HTML en cada petición), aunque plugins de caché lo acerquen a comportamiento estático. Para Google importa el resultado final medido, no la etiqueta.

¿Qué es ISR y por qué lo mencionan con SEO?

Regenera páginas estáticas en intervalos. Combina velocidad de lo pregenerado con contenido que se actualiza sin rebuild completo del sitio.

¿Debo migrar mi SPA a estático para SEO?

Depende. Si las URLs que quieres posicionar no muestran contenido en View Source, valora pre-renderizado, SSR o rutas híbridas antes que un rediseño total.

¿Cómo sé si mi decisión funciona?

Search Console (indexación, CWV), View Source en plantillas clave y una auditoría de velocidad en URLs con tráfico o intención comercial. Si necesitas orden, empieza por auditoría SEO técnica paso a paso.

«¿Cuánto cuesta el SEO técnico?» es una de las primeras preguntas cuando un sitio crece, migra de plataforma o deja de rankear. La respuesta honesta: depende — del tamaño del proyecto, del estado actual y de si buscas un informe único o acompañamiento continuo.

Esta guía explica qué suele incluir cada modelo de precio, qué variables encarecen el trabajo y cómo leer un presupuesto sin confundir SEO técnico con paquetes genéricos de «posicionamiento web».

Índice

• SEO técnico vs SEO «general»
• Modelos de contratación
• Qué encarece o abarata el proyecto
• Rangos orientativos de mercado (2026)
• Qué debe incluir un buen presupuesto
• Retainers mensuales: cuándo tienen sentido
• Señales de alerta al comparar precios
• Preguntas frecuentes

SEO técnico vs SEO «general»

SEO técnico cubre la capa que permite a Google rastrear, indexar y valorar tu sitio: arquitectura, velocidad, Core Web Vitals, canonicals, sitemap, datos estructurados, HTTPS, redirecciones, etc. No es redacción de artículos ni gestión de redes sociales.

Un paquete barato de «10 keywords + 4 posts al mes» rara vez incluye arreglar una migración rota o un INP crítico en móvil. Si tu problema es indexación o rendimiento, necesitas presupuesto alineado con una auditoría SEO técnica real, no solo contenido.

Relacionado: auditoría PageSpeed práctica y Core Web Vitals explicados.

Modelos de contratación

Modelo	Qué es	Ideal para
Auditoría puntual	Diagnóstico + informe priorizado; implementación opcional aparte	Baseline pre-migración, due diligence, segundo opinion
Proyecto acotado	Auditoría + bloque de fixes acordados (p. ej. CWV en plantillas clave)	Rediseño, lanzamiento tienda, salida de penalización técnica
Retainer mensual	Horas recurrentes: monitorización, nuevas URLs, soporte a desarrollo	Sitios activos, e-commerce, equipos que publican a menudo
Híbrido agencia + herramienta	Retainer humano + panel/SaaS de seguimiento	Equipos que quieren datos continuos sin montar stack propio

Qué encarece o abarata el proyecto

Volumen y complejidad del sitio

• Decenas de URLs vs miles (e-commerce, filtros, paginación).
• Multidioma (hreflang, slugs distintos, CMS headless).
• Subdominios o entornos staging indexables por error.

Estado de partida

• Migración reciente sin 301 completos.
• Histórico de penalizaciones o spam técnico.
• Plugins que inyectan scripts, duplicados masivos, 5xx intermitentes.

Profundidad de implementación

Solo informe es más barato que informe + tickets para desarrollo + validación post-deploy. Si tu equipo no tiene capacidad interna, el precio seo técnico total sube porque la agencia o consultor coordina con devs.

Sector y competencia

Mercados saturados (legal, finanzas, e-commerce nacional) exigen más iteración en rendimiento y arquitectura; no porque Google cobre más, sino porque el margen de error es menor.

Rangos orientativos de mercado (2026)

Cifras muy aproximadas en mercado hispano/europeo para servicios profesionales — no presupuesto de herramientas DIY. Sirven para calibrar expectativas; cada proveedor estructura distinto.

Servicio	Rango orientativo	Notas
Auditoría técnica (sitio pequeño)	800 – 2.500 €	~50–200 URLs, informe + call de priorización
Auditoría técnica (medio/grande)	2.500 – 8.000+ €	E-commerce, multidioma, varios entornos
Proyecto fixes CWV + indexación	3.000 – 15.000 €	Depende de horas dev; a menudo por fases
Retainer SEO técnico mensual	600 – 3.000+ €/mes	Horas incluidas, SLA, monitorización GSC/CWV

En EE. UU. los rangos equivalentes suelen ser un 20–40 % superiores; en LATAM pueden ser menores con la misma complejidad relativa. Lo barato sin alcance definido suele salir caro en retrabajo.

Qué debe incluir un buen presupuesto

1. Alcance explícito: URLs auditadas, plantillas, idiomas, herramientas.
2. Entregables: informe, lista priorizada (crítico / alto / medio), no solo capturas.
3. Horas de implementación o quién ejecuta (cliente vs agencia).
4. Validación post-cambio: re-rastreo, GSC, PageSpeed en URLs acordadas — ver cómo ejecutar una auditoría PageSpeed y el paso a paso de auditoría SEO técnica y la checklist de auditoría SEO para desarrolladores.
5. Propiedad: accesos, exportaciones, documentación para tu equipo.

Si el presupuesto no menciona indexación, CWV o schema, probablemente no es SEO técnico puro. Para saber qué revisar antes de pagar, usa la guía de SEO para desarrolladores: qué medir primero.

Retainers mensuales: cuándo tienen sentido

Un retainer encaja cuando:

• Publicas blog o catálogo con frecuencia (nuevas URLs que indexar).
• Tienes roadmap de producto que afecta frontend (A/B tests, terceros, features).
• Quieres monitorización de Core Web Vitals y errores de rastreo sin esperar al trimestre.
• Necesitas un interlocutor técnico en reuniones con desarrollo o agencia de performance.

No encaja si el sitio es estático, casi no cambia y ya tienes informe claro con fixes aplicados — ahí basta auditoría puntual + revisión anual.

Señales de alerta al comparar precios

• «Posicionamiento garantizado» en X días — nadie serio lo promete.
• Precio fijo sin preguntar tamaño del sitio ni acceso a GSC.
• Informe generado 100 % automático sin revisión humana.
• Confusión entre SEO técnico y compra de enlaces / PBN.
• Sin separación entre auditoría e implementación (sorpresas a mitad de proyecto).

Preguntas frecuentes

¿El precio del SEO técnico incluye contenido?

Normalmente no. Algunas agencias venden paquetes mixtos; aclara si las horas van a redacción o a rastreo, velocidad e indexación.

¿Puedo hacer solo la auditoría y aplicar yo los cambios?

Sí, es el modelo más habitual en equipos con desarrolladores. Asegura que el informe traduzca hallazgos a tickets accionables.

¿Cuánto tarda en verse ROI?

Fixes de indexación pueden mostrar efecto en semanas; CWV en ciclos de ~28 días en datos de campo; autoridad de contenido tarda más. El SEO técnico desbloquea; no sustituye estrategia editorial.

¿Herramientas SaaS sustituyen a una agencia?

Complementan. Un panel ayuda a monitorizar; no prioriza una migración fallida ni negocia con tu equipo de backend. Muchos retainers combinan ambos.

¿Cómo presupuestar una migración WordPress → headless?

Auditoría pre-migración + plan de 301 + validación post-lanzamiento. Suele ser proyecto, no solo retainer. Contexto en WordPress headless con Next.js.

Google entiende texto, pero también datos estructurados: etiquetas que describen qué es cada página (artículo, empresa, FAQ, producto…). Schema.org es el vocabulario estándar más usado. En proyectos con Next.js — sobre todo headless o híbridos — suele tener sentido porque controlas el HTML que recibe el buscador sin depender de un plugin que inyecte markup genérico.

Esta guía explica qué aporta al SEO, qué tipos conviene priorizar y qué errores evitar. No es un manual de código: es el mapa que necesitas antes de hablar con desarrollo o validar una auditoría.

Índice

• Qué es Schema.org
• Por qué encaja con Next.js y sitios headless
• JSON-LD, microdatos y RDFa
• Tipos de schema que más importan al SEO
• Rich results: qué puedes ganar (y qué no)
• Cómo validar antes de publicar
• Errores habituales
• Preguntas frecuentes

Qué es Schema.org

Schema.org es un conjunto de tipos y propiedades acordados por buscadores y la industria para describir contenido en la web. Ejemplos:

• Un artículo de blog → tipo Article o BlogPosting.
• La home de una agencia → Organization + WebSite.
• Un bloque de preguntas visibles → FAQPage.
• Un producto en tienda → Product con precio y disponibilidad.

No sustituye a un buen title, meta description ni a contenido útil. Actúa como capa de contexto: ayuda a Google a clasificar la página y, en algunos casos, a mostrar resultados enriquecidos (estrellas, FAQ expandible, breadcrumbs en SERP).

En una auditoría SEO técnica, el schema suele revisarse en el paso de datos estructurados — después de indexación y rendimiento, pero antes de escalar contenido.

Por qué encaja con Next.js y sitios headless

En WordPress clásico, plugins como Yoast o Rank Math generan JSON-LD automáticamente. En arquitecturas donde el CMS guarda contenido y Next.js sirve el frontend (como en muchos proyectos WordPress headless con Next.js), la responsabilidad del markup estructurado pasa al equipo que construye las plantillas públicas.

Ventajas de abordarlo en Next.js (como concepto, no como receta):

• Consistencia: mismo patrón de schema en todas las rutas (blog, landings, contacto).
• Datos dinámicos: título, fecha, imagen y autor del post pueden alimentar BlogPosting desde la API del CMS.
• Menos duplicados: evitas que CMS y frontend inyecten dos bloques JSON-LD contradictorios.
• Control de QA: puedes validar schema en staging antes del deploy, igual que canonicals o hreflang.

El keyword schema.org nextjs no implica que Next.js “tenga SEO mágico”: implica que tienes libertad — y obligación — de definir bien la capa estructurada.

JSON-LD, microdatos y RDFa

Google recomienda JSON-LD: un bloque <script type="application/ld+json"> en el HTML, separado del contenido visible. Es más fácil de mantener que microdatos incrustados en cada etiqueta HTML.

Formato	Ventaja	Inconveniente
JSON-LD	Limpio, versionable, ideal para SPAs y SSR	Debe reflejar contenido real de la página
Microdatos	Acoplado al HTML visible	Verboso; fácil romper al cambiar plantillas
RDFa	Flexible en XML/HTML complejos	Poco habitual en stacks modernos

Tipos de schema que más importan al SEO

Sitio corporativo / agencia

• Organization — nombre, logo, URL, redes (sameAs).
• WebSite — sitio y, opcionalmente, acción de búsqueda interna.
• LocalBusiness — solo si tienes ficha física verificable; no inventes direcciones.

Blog y contenido

• BlogPosting o Article — headline, datePublished, author, image.
• BreadcrumbList — migas visibles alineadas con la URL.

Landings de servicio

• Service — descripción del servicio, provider (Organization).
• FAQPage — solo si las preguntas están en el HTML visible (no ocultas solo para robots).

E-commerce (si aplica)

• Product, Offer, AggregateRating — con datos reales; reseñas falsas penalizan.

Prioriza los tipos que corresponden a plantillas con tráfico: home, artículos, páginas de servicio. Añadir diez tipos irrelevantes no mejora posiciones.

Rich results: qué puedes ganar (y qué no)

Los resultados enriquecidos son snippets con FAQ desplegable, estrellas, breadcrumbs, etc. Google decide si los muestra; el schema solo te hace elegible.

• FAQ visible → posible acordeón en SERP (cuando Google lo considera útil).
• Artículo bien marcado → mejor comprensión; no garantiza carrusel Top Stories.
• Product + reviews reales → estrellas en algunos mercados.

Schema no sustituye Core Web Vitals ni enlaces internos. Es una pieza más del puzzle técnico.

Cómo validar antes de publicar

1. Prueba de resultados enriquecidos de Google — URL en vivo o fragmento HTML.
2. Search Console → Mejoras / datos estructurados — errores e impresiones de rich results.
3. Inspección manual: “Ver código fuente” y buscar un solo bloque coherente por tipo principal.
4. Coherencia con la página: fechas, imágenes y autor del JSON-LD deben coincidir con lo visible.
5. Tras cada deploy — igual que revisar canonicals en migraciones.

Para el resto de señales técnicas, combina esta revisión con la guía de DevTools para SEO y, si el foco es velocidad, con la auditoría PageSpeed práctica.

Errores habituales

• FAQPage sin FAQ visible — política de spam; riesgo de ignorar todo el bloque.
• Duplicar Organization en cada URL con datos distintos — confunde a Google.
• Campos obligatorios vacíos — image, author, datePublished en artículos.
• Schema del CMS + schema del frontend en headless sin coordinación — duplicados o conflictos.
• Markup de Product/Review inventado — puede acarrear acciones manuales.
• Confundir schema con ranking directo — ayuda a elegibilidad, no es un boost garantizado.

Preguntas frecuentes

¿Schema.org es obligatorio para indexar?

No. Las páginas sin schema se indexan con normalidad. Los datos estructurados mejoran comprensión y, a veces, la presentación en resultados.

¿Next.js incluye Schema.org por defecto?

No de forma automática en todas las rutas. Depende de cómo construyas metadata y scripts en cada plantilla o de lo que exponga tu CMS vía API.

¿Yoast en headless sigue valiendo para schema?

Muchas instalaciones headless leen SEO del CMS (title, meta, opengraphImage). El JSON-LD puede generarse en el frontend, en el CMS o en ambos — lo crítico es una sola fuente de verdad coherente.

¿Cuántos tipos de schema por página?

Un tipo principal claro (Article, Service, FAQPage…) más tipos anidados lógicos (Organization como publisher). Evita listar tipos no relacionados con el contenido.

¿Con qué frecuencia revisarlo?

En cada plantilla nueva, rediseño o cambio de CMS. Trimestral en sitios estables, como parte del paso de schema en una auditoría técnica.

Una auditoría PageSpeed no es magia ni un número para presumir en LinkedIn: es el proceso de medir qué tan rápida y estable se siente tu web, interpretar el informe y decidir qué optimizar primero. Si solo miras el puntaje verde o rojo sin contexto, acabarás cambiando el hosting o instalando plugins al azar.

Esta guía es práctica — centrada en PageSpeed Insights, Lighthouse y los datos de campo de Google — y encaja como capítulo de rendimiento dentro de una auditoría SEO técnica más amplia. También puedes usar la checklist de auditoría SEO para desarrolladores como lista accionable. No sustituye revisar indexación ni enlaces; complementa el paso de Core Web Vitals.

Índice

• Qué es una auditoría PageSpeed
• PageSpeed vs auditoría SEO completa
• Herramientas que usarás
• Datos de laboratorio vs datos de campo
• Pasos de la auditoría (workflow)
• Cómo leer LCP, INP y CLS en el informe
• Qué arreglar primero
• Errores habituales
• Preguntas frecuentes

Qué es una auditoría PageSpeed

Es un diagnóstico enfocado en rendimiento percibido y métricas de experiencia: tiempo hasta que el contenido principal es visible (LCP), respuesta a interacciones (INP) y estabilidad del layout (CLS). Google expone gran parte de esto en PageSpeed Insights y en Search Console bajo Core Web Vitals.

El objetivo no es “llegar a 100” en Lighthouse, sino:

• Identificar plantillas problemáticas (home, categorías, fichas de producto, landings).
• Separar problemas de servidor, frontend, imágenes y terceros.
• Priorizar cambios con impacto en usuarios reales y, como efecto secundario, en SEO.

Si aún no dominas qué significan las siglas, repasa Core Web Vitals: qué son y qué medir antes de profundizar en la auditoría.

PageSpeed vs auditoría SEO completa

Auditoría PageSpeed	Auditoría SEO técnica completa
Velocidad, CWV, recursos bloqueantes, peso de página	Indexación, canonicals, sitemap, arquitectura, schema, enlaces
Horas a pocos días por plantilla clave	Días a semanas según tamaño del sitio
Ideal tras rediseño, pico de rebote o antes de campañas de pago	Ideal antes de migraciones y de escalar contenido o link building

Puedes hacer una auditoría PageSpeed solo cuando el tráfico cae en móvil o Search Console marca URLs en rojo en Experiencia. Si además hay páginas “Descubierta — sin indexar”, arregla rastreo primero con la auditoría SEO técnica paso a paso antes de obsesionarte con el puntaje Lighthouse.

Si tras medir velocidad necesitas presupuesto para implementación o acompañamiento mensual, el artículo sobre cuánto cuesta el SEO técnico explica rangos orientativos y qué debe incluir un presupuesto serio.

Herramientas que usarás

• PageSpeed Insights (PSI): URL pública, mezcla datos de campo (CrUX, si hay volumen) y prueba de laboratorio (Lighthouse).
• Lighthouse en Chrome DevTools: repetible en local o staging; útil para comparar antes/después de un cambio.
• Google Search Console: informe Core Web Vitals por grupos de URLs — visión agregada de usuarios Chrome.
• WebPageTest o similar (opcional): waterfall detallado, múltiples ubicaciones y conexiones simuladas.

Para el día a día del desarrollador, combina PSI con la guía de DevTools para SEO: pestaña Network, Coverage y Performance complementan lo que PSI resume.

Datos de laboratorio vs datos de campo

Laboratorio: simulación controlada (dispositivo, red, ubicación del servidor de prueba). Reproducible. Perfecto para depurar tras un deploy.

Campo: mediciones anonimizadas de usuarios reales (Chrome User Experience Report). Refleja dispositivos, redes y caches reales. Es lo que Search Console usa para clasificar URLs en bueno / mejorable / malo.

Regla práctica: no celebres un 98 en Lighthouse si GSC sigue mostrando LCP malo en la misma plantilla. Repite la medición en móvil, en 4G simulado y en la URL exacta que rankea.

Pasos de la auditoría (workflow)

1. Elige 5–10 URLs: home, landing principal, artículo de blog con tráfico, plantilla de listado y una URL “problemática” que ya conozcas.
2. Define el dispositivo: empieza por móvil; desktop solo si tu negocio es B2B muy orientado a escritorio.
3. Ejecuta PSI para cada URL; captura pantalla o exporta oportunidades principales. Como atajo, prueba primero tu dominio en el simulador PageSpeed de la landing de SEO técnico.
4. Anota las tres CWV (campo si hay datos; si no, laboratorio) y el elemento LCP que PSI destaca.
5. Agrupa por plantilla: si diez productos fallan igual, el fix es la plantilla — no diez tickets sueltos.
6. Lista oportunidades en tres buckets: imágenes, JavaScript/CSS, servidor/red (TTFB, caché, CDN).
7. Implementa 1–2 cambios de alto impacto; vuelve a medir la misma URL en las mismas condiciones.
8. Documenta URL, fecha, puntuación/métricas y cambio aplicado — imprescindible si trabajas con agencia o dev externo.

Cómo leer LCP, INP y CLS en el informe

Si necesitas repasar qué significa cada métrica y los umbrales de Google, vuelve a Core Web Vitals: qué son y qué medir antes de interpretar oportunidades concretas en PSI.

LCP (carga)

PSI indica qué elemento fue el “contenido principal” (hero, imagen, bloque de texto). Pregunta: ¿es una imagen enorme? ¿Un slider? ¿El servidor tardó en responder? Las oportunidades “Mejorar entrega de imágenes” o “Reduce el tiempo de respuesta del servidor” suelen apuntar aquí.

INP (interactividad)

Relevante en menús, filtros, carritos y SPAs. Si INP falla con poco JavaScript visible, sospecha de scripts de terceros (chat, tags, A/B testing) que bloquean el hilo principal.

CLS (estabilidad)

Busca imágenes sin dimensiones, banners que se insertan tarde y fuentes que cambian el layout. PSI a veces lista “elementos que provocaron el mayor cambio de diseño”.

Lighthouse también muestra categorías (Performance, Accessibility, Best Practices, SEO). Para una auditoría PageSpeed orientada a negocio, Performance + CWV van primero; el resto ayuda pero no sustituye arreglar LCP en la landing que convierte.

Qué arreglar primero

Señal	Acciones típicas (sin entrar en stack concreto)
TTFB alto	Caché HTML, CDN, hosting más cercano al usuario, reducir trabajo en el origen
LCP = imagen hero	Compresión, tamaño responsive, preload prudente, evitar carruseles pesados above the fold
JS bloqueante	Retrasar scripts no críticos, dividir bundles, revisar plugins que inyectan scripts globales
CLS	Reservar espacio para media y anuncios; evitar insertar barras encima del contenido principal
INP	Reducir listeners pesados, optimizar handlers, limitar widgets de terceros en páginas clave

Orden sugerido en la mayoría de sitios corporativos y blogs: servidor/caché → imágenes LCP → scripts terceros → CLS → refinamiento INP. E-commerce y marketplaces a veces invierten INP y LCP por la complejidad del carrito. Cuando tengas la lista priorizada, valida el impacto con el simulador y auditoría SEO de Veloce Devs antes de abrir tickets de desarrollo.

Errores habituales

• Auditar solo la home mientras el tráfico orgánico entra por entradas de blog o categorías lentas.
• Optimizar desktop ignorando que Google evalúa mobile-first.
• Confundir puntaje Lighthouse con ranking — ayuda, pero no es un interruptor de posiciones.
• Instalar un plugin “PageSpeed” que minifica sin medir: a veces empeora INP o rompe funcionalidad.
• No repetir la medición tras el cambio, o hacerlo en condiciones distintas (otra red, otra extensión del navegador).
• Ignorar datos de campo cuando ya tienes volumen suficiente en GSC.

Preguntas frecuentes

¿Cuánto dura una auditoría PageSpeed básica?

Para 5–10 URLs y un informe priorizado, cuenta medio día de análisis y otra media jornada si incluyes reuniones con desarrollo. Implementar las mejoras depende del equipo — de horas a varias semanas.

¿PageSpeed Insights es gratis?

Sí. Lighthouse en Chrome también. Search Console es gratuita con verificación de dominio. Herramientas avanzadas de waterfall pueden ser de pago pero no son obligatorias para empezar.

¿Qué puntuación PageSpeed necesito para rankear?

No hay umbral público único. Google trabaja con rangos de Core Web Vitals y experiencia general. Apunta a “bueno” en campo en tus plantillas principales, no a un número redondo en laboratorio.

¿Auditoría PageSpeed en staging o solo producción?

Producción refleja CDN, caché real y terceros. Staging sirve para probar fixes antes de desplegar, pero compara siempre la URL pública final tras el release.

¿Con qué frecuencia repetirla?

Tras cada cambio grande de diseño, plugins o scripts. En operación normal, revisión mensual o trimestral de las mismas URLs “canario” más el informe CWV de Search Console.

Una auditoría SEO técnica responde una pregunta concreta: ¿Google puede encontrar, rastrear, entender e indexar tu web sin fricción? No sustituye a la estrategia de contenidos, pero evita que meses de trabajo editorial se pierdan por un robots.txt mal puesto, cadenas de redirecciones o una plantilla que duplica URLs.

Esta guía propone un orden lógico — de lo bloqueante a lo fino — para equipos de marketing y desarrollo que quieren un mapa claro antes de abrir tickets o contratar ayuda externa.

Índice

• Qué es una auditoría SEO técnica
• Cuándo hacerla
• Paso 1 — Rastreo e indexación
• Paso 2 — Arquitectura y URLs
• Paso 3 — On-page y contenido indexable
• Paso 4 — Rendimiento y Core Web Vitals
• Paso 5 — Enlaces internos y externos
• Paso 6 — Datos estructurados y SERP
• Cómo priorizar hallazgos
• Preguntas frecuentes

Qué es una auditoría SEO técnica

Es un diagnóstico sistemático de la capa técnica del sitio: no evalúa si tu copy convence, sino si la infraestructura permite que el buscador haga su trabajo. Incluye, entre otros:

• Estado de indexación y errores de rastreo.
• Canonicals, hreflang y duplicados.
• Velocidad, estabilidad visual e interactividad (Core Web Vitals).
• Sitemap, robots.txt y respuestas HTTP.
• Marcado schema y aspecto en resultados enriquecidos.

Se diferencia de una auditoría de contenidos (keywords, intención de búsqueda) y de una auditoría de autoridad (backlinks). Las tres se complementan; la técnica suele ir primero porque un sitio no indexado no compite por ninguna query.

Cuándo hacerla

Momento	Por qué
Antes de un rediseño o migración	Baseline de URLs indexadas, redirecciones y tráfico orgánico
Tras caída brusca de tráfico	Detectar bloqueos, 5xx, noindex accidental o canónicas agresivas
Lanzamiento de sección nueva	Blog, tienda, idiomas — validar arquitectura desde el día uno
Revisión trimestral	Plugins, temas y contenido nuevo degradan SEO sin avisar
Antes de invertir en link building	No envíes autoridad a páginas con fugas técnicas

Paso 1 — Rastreo e indexación

Empieza por Google Search Console (propiedad del dominio o prefijo correcto):

1. Páginas indexadas vs excluidas: ¿crece el número de URLs útiles? ¿hay picos de “Duplicada” o “Redirigida”?
2. Informe de páginas: filtra errores 404, 5xx, “Descubierta — sin indexar”.
3. Sitemaps: ¿el XML enviado coincide con las URLs públicas? ¿hay errores de procesamiento?
4. Inspección de URL: prueba home, categorías y 3–5 URLs money — canonical declarada vs seleccionada por Google.

Complementa con un rastreo de sitio (Screaming Frog, Sitebulb o similar) en modo “spider” para ver lo que ve un bot: códigos de respuesta, meta robots, canonicals en HTML y profundidad de clic.

Paso 2 — Arquitectura y URLs

• HTTPS en todas las versiones; una sola variante canónica (con o sin www, con barra final consistente).
• Redirecciones: cadenas cortas (idealmente un salto 301); evita bucles y 302 permanentes por error.
• Profundidad: páginas importantes a ≤ 3 clics desde la home.
• Multidioma: hreflang coherente ES/EN (o más) sin mezclar slugs entre idiomas.
• Parámetros y filtros: ¿generan duplicados indexables? Usa canonical o noindex donde toque.

Si gestionas blog y landings en rutas distintas, confirma que el sitemap y los enlaces internos apuntan a la versión pública (no a un CMS o subdominio de preview).

Paso 3 — On-page y contenido indexable

Para cada plantilla clave (home, servicio, artículo):

• Un solo <h1> claro; jerarquía H2/H3 lógica.
• Title y meta description únicos; title ≈ 50–60 caracteres útiles, description que invite al clic sin relleno.
• Canonical autorreferencial salvo casos de syndication.
• Contenido principal visible en HTML inicial (no solo tras interacción JS pesada).
• Imágenes con alt descriptivo; formatos modernos (WebP/AVIF) cuando sea posible.

Para profundizar en qué métricas mirar antes que el copy, revisa SEO para desarrolladores: qué medir primero y la guía de DevTools para SEO.

Paso 4 — Rendimiento y Core Web Vitals

Google usa señales de experiencia; los Core Web Vitals (LCP, INP, CLS) resumen carga, respuesta e estabilidad. En la auditoría:

1. Mide URLs reales en PageSpeed Insights o informes de campo en Search Console.
2. Prioriza plantillas con más tráfico orgánico o conversión.
3. Separar móvil y desktop — mobile-first sigue siendo el referente principal.
4. Documenta LCP element, scripts bloqueantes e imágenes sin dimensiones (CLS).

Contexto conceptual en Core Web Vitals: qué son, qué medir y por qué importan para el SEO. Para bajar del diagnóstico general a un workflow concreto de velocidad, sigue la guía práctica de auditoría PageSpeed. Si valoras externalizar el trabajo, revisa también cuánto cuesta el SEO técnico y qué modelos de contratación existen. Si prefieres una lista accionable para repasar con tu equipo, usa nuestra checklist de auditoría SEO para desarrolladores.

Paso 5 — Enlaces internos y externos

Internos

• ¿Las páginas nuevas reciben enlaces desde home, blog o landings?
• ¿Hay enlaces rotos (404) en menús, footers o contenido antiguo?
• ¿Anclas descriptivas o genéricas (“clic aquí”)?

Externos

• Perfil de backlinks tóxico o spikes sospechosos (herramientas tipo Ahrefs, Semrush).
• Enlaces salientes rotos en recursos citados.

Paso 6 — Datos estructurados y SERP

Valida JSON-LD o microdatos con la Prueba de resultados enriquecidos de Google:

• Organization / WebSite en home.
• Article o BlogPosting en entradas.
• FAQPage solo si las preguntas son visibles en la página.
• Product / LocalBusiness si aplica a tu negocio.

Errores de schema no suelen bloquear indexación, pero sí rich results — corrígelos cuando el tipo de página lo justifique.

Cómo priorizar hallazgos

Severidad	Ejemplos	Acción
Crítica	noindex en plantillas money, 5xx masivos, migración sin 301	Parar campañas; fix en horas o días
Alta	Canonical incorrecta, sitemap roto, CWV muy por debajo de umbral	Sprint actual
Media	Titles duplicados, imágenes pesadas, enlaces rotos secundarios	Backlog 2–4 semanas
Baja	Schema opcional, micro-optimizaciones de alt text	Cuando haya capacidad

Entrega un documento con: URL afectada, evidencia (captura o export), impacto estimado y responsable (dev, contenido, infra). Una auditoría SEO técnica que no termina en tickets accionables es solo un PDF decorativo.

Preguntas frecuentes

¿Cuánto tarda una auditoría SEO técnica?

Un sitio pequeño (decenas de URLs) puede revisarse en 1–2 días de análisis. Proyectos con e-commerce, multidioma o miles de URLs requieren rastreos más largos y validación con desarrollo — de una a tres semanas según profundidad.

¿Qué herramientas necesito como mínimo?

Google Search Console es obligatoria. Añade un rastreador desktop, PageSpeed Insights y las DevTools del navegador. Las suites de pago ayudan en enlaces y seguimiento, pero no son imprescindibles para la primera pasada.

¿Auditoría técnica vs auditoría de contenidos?

La técnica valida acceso e indexación; la de contenidos evalúa keywords, intención, calidad editorial y enlaces contextuales. Haz técnica primero si sospechas bloqueos; si el tráfico crece pero no convierte, balancea con contenido y UX.

¿Con qué frecuencia repetirla?

Trimestral para sitios activos; mensual durante migraciones o lanzamientos grandes. Search Console alerta sobre picos, pero no sustituye una revisión programada.

¿Puedo automatizar parte del proceso?

Sí: rastreos programados, alertas de uptime, informes CWV en CI. La interpretación y priorización siguen necesitando criterio humano — sobre todo en canonicals, hreflang y cambios de producto.

La pregunta Next.js vs WordPress clásico para SEO aparece en casi toda reunión de producto: ¿migrar, quedarse o mezclar? No hay una respuesta universal. Google no premia un framework en el ranking — premia páginas útiles, rápidas, bien enlazadas y técnicamente sanas. Lo que cambia es cuánto te cuesta llegar a ese estado con cada enfoque.

Esta guía compara ambos caminos desde SEO y operación: qué controlas, qué suele fallar y en qué escenarios tiene sentido cada uno. Si buscas la tercera vía (WordPress como CMS + frontend moderno), enlazamos al final con un artículo dedicado a WordPress headless con Next.js.

Índice

• Qué estás comparando en realidad
• SEO técnico: WordPress clásico vs Next.js
• Rendimiento y Core Web Vitals
• Contenido, plugins y coste de mantenimiento
• Cuándo elegir WordPress, Next.js o híbrido
• Checklist antes de cambiar de stack
• Mitos frecuentes
• Preguntas frecuentes

Qué estás comparando en realidad

WordPress clásico es un sistema completo: creas contenido en el panel y un tema (PHP) genera la web que ve el usuario y Google. Plugins añaden SEO, caché, formularios, tienda, etc.

Next.js es un framework para construir la capa web (páginas, rutas, interactividad). No trae un panel editorial de fábrica: el contenido puede venir de un CMS, de archivos, de una base de datos o de APIs. Para SEO, lo relevante es el HTML que entrega al crawler, no el nombre del framework.

En la práctica, la comparación nextjs vs wordpress seo suele mezclar tres escenarios distintos:

• WordPress con tema + Yoast (o similar) — el caso más común.
• Next.js con contenido estático o CMS headless — máximo control del frontend.
• WordPress headless + Next.js — editorial en WP, web pública optimizada.

Confundir «Next.js puro» con «headless» lleva a presupuestos y plazos irreales. Acláralo antes de pedir presupuestos.

SEO técnico: WordPress clásico vs Next.js

Factor SEO	WordPress clásico	Next.js (bien ejecutado)
Titles y meta descriptions	Plugins SEO maduros, UI familiar para marketing	Control total en plantillas; requiere disciplina o CMS con campos SEO
URLs y canonicals	Reglas habituales; riesgo de duplicados con plugins mal configurados	Defines rutas explícitas; menos sorpresas si la arquitectura está planificada
Sitemap y robots	Generación automática con plugins	Implementación manual o vía librerías; muy flexible
Datos estructurados	Plugins añaden JSON-LD; calidad variable	Schema a medida por plantilla; más trabajo inicial, más precisión
Multidioma	Plugins (Polylang, WPML) muy extendidos	Posible, pero hay que diseñar hreflang y rutas desde el inicio
Indexación de JS	Menos JS en temas ligeros; temas pesados complican	SSR/SSG entrega HTML completo; ideal para crawlers si no dependes solo del cliente

Ninguna columna «gana» en todo. WordPress acorta el camino para equipos que viven en el panel. Next.js premia a quien quiere un producto web a medida sin arrastrar el peso de un tema genérico.

Para priorizar qué medir antes de discutir frameworks, revisa SEO para desarrolladores: qué medir primero.

Rendimiento y Core Web Vitals

La velocidad no es el único factor de ranking, pero los Core Web Vitals reflejan experiencia real — sobre todo en móvil. Ahí suele aparecer la mayor fricción en WordPress clásico: temas multipropósito, page builders, veinte plugins activos y scripts que cargan en todas las páginas.

Next.js no es mágico: un frontend mal optimizado (imágenes enormes, fuentes sin control, hidratación excesiva) también suspende en PageSpeed. La ventaja es que puedes diseñar la página para cargar solo lo necesario, con renderizado en servidor o estático cuando conviene.

• LCP: WordPress mejora con hosting, caché e imágenes optimizadas; Next.js con imágenes responsivas, CDN y HTML prioritario.
• INP / interactividad: Menos JavaScript de terceros en el frontend dedicado suele ayudar.
• CLS: Temas bien hechos y builders descuidados pueden romper layout; en Next.js depende de componentes y reserva de espacio para medios.

Profundiza en qué significan y cómo interpretarlos en Core Web Vitals: qué son, qué medir y por qué importan para el SEO.

Contenido, plugins y coste de mantenimiento

El SEO no termina en el lanzamiento. Alguien publica entradas, actualiza landings, corrige enlaces rotos y revisa redirecciones cuando cambias URLs.

WordPress clásico

• Pros: curva editorial baja, ecosistema de plugins, contratar perfiles WordPress es relativamente fácil.
• Contras: actualizaciones de plugins/temas, conflictos, seguridad, rendimiento que se degrada con el tiempo si no hay dueño técnico.

Next.js

• Pros: base de código moderna, CI/CD, menos sorpresas de «plugin X rompe el SEO».
• Contras: necesitas desarrolladores para cambios estructurales; sin CMS acoplado, marketing depende de tickets para cosas simples.

El coste oculto del SEO suele ser mantenimiento, no la licencia del tema. Un WordPress bien gobernado puede durar años; un Next.js sin documentación se convierte en caja negra.

Cuándo elegir WordPress, Next.js o híbrido

Escenario	Orientación
Blog o web corporativa pequeña, pocas plantillas, equipo no técnico	WordPress clásico + tema ligero + SEO plugin + caché
Tienda WooCommerce estándar, muchas extensiones de pago/envío	WordPress clásico (headless aquí suele complicar sin beneficio claro)
Marketing agresivo en CWV, landings custom, herramientas interactivas	Next.js o headless con CMS conocido
Equipo editorial fuerte en WordPress pero web lenta por el tema	Híbrido headless — conservar panel, renovar frontend
Startup que aún valida producto y contenido	Evita sobre-ingeniería; WordPress sólido o landing Next.js mínima hasta tracción
SEO multidioma serio (ES/EN/+) con mismas URLs traducidas	Ambos valen; WordPress con plugin de idiomas es camino rápido; Next.js exige diseño hreflang desde el día uno

Si tu caso encaja en la fila «híbrido», el siguiente paso conceptual es leer la guía de WordPress headless con Next.js — no es la única forma de combinar ambos, pero es el patrón más habitual en 2026.

Checklist antes de cambiar de stack «por SEO»

1. Baseline: Search Console + PageSpeed en URLs que importan (home, categorías, posts top).
2. Diagnóstico honesto: ¿el problema es el CMS o un tema/plugin/caché mal configurados?
3. Mapa de URLs: redirecciones 301 planificadas; no lanzar sin equivalencias.
4. Contenido indexable: mismo valor (o mejor) en titles, H1, enlaces internos y schema.
5. Equipo: ¿quién publica, quién despliega, quién responde si cae el sitio?
6. Presupuesto 24 meses: hosting, licencias, horas dev, auditorías SEO periódicas.

Migrar de WordPress a Next.js (o al revés) solo por reputación técnica, sin checklist, es una de las formas más caras de perder tráfico estable.

Mitos frecuentes

«Google prefiere Next.js»

Google prefiere páginas rápidas, claras y enlazadas. El framework es transparente si el HTML y las señales técnicas son correctas.

«WordPress ya no sirve para SEO»

Un gran porcentaje de la web corre en WordPress y rankea bien. Lo que no sirve es un tema inflado sin mantenimiento.

«Con Next.js no necesito SEO técnico»

Necesitas igual: canonicals, sitemaps, redirecciones, datos estructurados y monitorización en Search Console.

«Headless es siempre el término medio perfecto»

Añade complejidad (dos sistemas, APIs, preview de contenido). Compensa cuando el cuello de botella es el frontend, no el panel.

Preguntas frecuentes

¿Next.js o WordPress para un blog que prioriza SEO?

Para la mayoría de equipos pequeños y medianos, WordPress con tema rápido, buen plugin SEO y disciplina editorial llega antes a resultados. Next.js compensa si el blog es parte de un producto web más grande o si el rendimiento es ventaja competitiva demostrable.

¿Puedo mejorar el SEO sin cambiar de WordPress?

Sí: tema más ligero, menos plugins, caché, imágenes WebP, CDN, arreglar enlaces rotos y mejorar contenido. Muchas webs «necesitan Next.js» cuando en realidad necesitan limpieza técnica.

¿Cuánto tarda en verse un impacto SEO tras migrar a Next.js?

Semanas a meses. Google debe recrawlar, procesar redirecciones y reevaluar señales. Planifica un periodo de vigilancia en Search Console; no esperes un salto el día del deploy.

¿WooCommerce y Next.js juntos tienen sentido?

Existen setups headless con Woo, pero son proyectos avanzados. Para SEO de catálogo estándar, Woo en WordPress clásico sigue siendo la opción más predecible.

¿Dónde encaja Veloce Devs en esta decisión?

Trabajamos webs orientadas a rendimiento y SEO técnico — a menudo combinando CMS familiar con frontends modernos cuando el negocio lo justifica. La landing principal resume servicios y enfoque; no hace falta que elijas stack antes de entender tu contexto.

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.