Autor: admin

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.