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 proyectos Next.js y WordPress headless:

Errores 5xx

Una respuesta del servidor (timeout, error de GraphQL, 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 puedes definirlo en src/app/robots.ts con tipado estricto.

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 con Next.js, cada página debe tener su propio canonical apuntando a su versión con locale:

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

<!-- incorrecto: apunta al CMS headless -->
<link rel="canonical" href="https://api.velocedevs.com/es/servicio-seo/" />

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://velocedevs.com/en/seo/" />
<link rel="alternate" hreflang="es" href="https://velocedevs.com/es/seo/" />

Si los pares Polylang están bien vinculados en WordPress y Next.js lee las traducciones vía WPGraphQL, esto se genera automáticamente en generateMetadata.

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 GraphQL lentas o ausencia de ISR (revalidate).

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 son las herramientas que usamos en Veloce Devs para cubrir las cuatro capas de la pirámide:

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í
OpenSEO	Keywords, rankings, auditoría recurrente automatizada	Vía Veloce SEO Suite

Integrarlo en tu flujo de trabajo

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

En cada pull request

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

Semanal

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

Mensual

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

Preguntas frecuentes

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

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

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

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

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

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

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

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

Si eres desarrollador, el SEO no debería ser un misterio que delegas por completo al equipo de marketing. Muchos problemas de posicionamiento nacen en el código: JavaScript que bloquea el rastreo, canonicals mal configurados, Core Web Vitals fuera de rango o sitemaps que no reflejan la arquitectura real del sitio. Las devtools para SEO existen precisamente para cerrar esa brecha entre ingeniería y visibilidad orgánica.

En esta guía reunimos el stack que usamos en Veloce Devs en proyectos Next.js, WordPress headless y WooCommerce: desde el navegador hasta CI/CD, con enlaces a recursos oficiales y un flujo que puedes aplicar hoy en tu repositorio.

Índice

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

Por qué el SEO es responsabilidad del desarrollador

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

Los equipos que mejor posicionan suelen compartir un patrón: el desarrollador valida SEO técnico en cada pull request y marketing se concentra en intención de búsqueda y contenido. No necesitas convertirte en consultor SEO; necesitas saber qué medir y dónde mirar.

DevTools del navegador (Chrome y Edge)

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

1. Lighthouse

Genera un informe de rendimiento, accesibilidad, buenas prácticas y SEO básico sobre la URL cargada. Úsalo en ventana de incógnito y con extensiones desactivadas para evitar falsos positivos.

2. Network (Red)

Filtra por Doc, JS y CSS. Busca:

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

3. Coverage (Cobertura de JavaScript y CSS)

Muestra qué porcentaje del JS/CSS descargado no se ejecuta en la vista actual. Ideal para detectar bundles hinchados en landings que deberían ser ligeras.

4. Elements + buscar meta tags

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

• Un solo <title> y una <meta name="description"> por página.
• <link rel="canonical"> apuntando a la URL canónica (sin www duplicado si tu política es apex).
• hreflang coherente en sitios multidioma (en, es, x-default si aplica).
• noindex accidental en producción.

Lighthouse y PageSpeed Insights

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

En nuestra landing de SEO técnico puedes probar tu dominio con un simulador PageSpeed integrado. Si los scores están en rojo, el problema suele ser LCP (imagen hero sin prioridad, fuentes bloqueantes) o INP (demasiado JavaScript en el hilo principal).

Objetivos orientativos:

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

Google Search Console

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

• Pages → Indexing: errores 5xx, 404, «Rastreada, sin indexar» y redirecciones innecesarias.
• Sitemaps: envía https://tudominio.com/sitemap.xml y confirma que las URLs canónicas coinciden con las del sitemap.
• Core Web Vitals: URLs en rojo/ambar que necesitan cambios de código, no solo de copy.
• URL Inspection: prueba una URL recién desplegada y solicita indexación tras corregir canonicals o hreflang.

Rastreo, logs y CLI

Cuando el sitio crece, el navegador no escala. Añade herramientas de línea de comandos al flujo:

Herramienta	Para qué sirve
curl -I URL	Ver status HTTP, Location, cabeceras de caché y canonical vía redirect chain.
Screaming Frog (free tier)	Rastreo de enlaces rotos, titles duplicados, meta vacías y profundidad de clic.
npx lighthouse URL --view	Auditorías repetibles en CI o scripts locales.
Validadores de schema	Probar JSON-LD (Organization, FAQPage, BlogPosting) antes de publicar.

Integrar una auditoría Lighthouse en GitHub Actions o en tu pipeline de Hostinger/Vercel evita regresiones cuando alguien añade un script de terceros «solo por probar».

Stack recomendado en proyectos headless (Next.js + WordPress)

En arquitecturas headless, el SEO se reparte así:

• Next.js (frontend): generateMetadata, sitemap, robots.txt, HTML semántico, ISR/SSR.
• WordPress (CMS): contenido, Yoast, Polylang, campos ACF expuestos a WPGraphQL.
• Cloudflare / CDN: HTTPS, compresión, reglas de caché sin romper HTML dinámico.
• Panel SEO (keywords + rankings): para no depender solo de hojas de cálculo cuando el catálogo de URLs crece.

Para investigación de keywords, seguimiento de rankings y auditorías recurrentes usamos OpenSEO, integrado en nuestra oferta en la sección Veloce SEO Suite. Es la capa que complementa Lighthouse (rendimiento puntual) con datos SERP continuos.

Checklist pre-deploy para desarrolladores

Copia esta lista en tu PR template o wiki del repo:

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

Si prefieres que un equipo revise tu stack completo, solicita una auditoría SEO técnica con roadmap priorizado por impacto.

Preguntas frecuentes

¿Lighthouse basta para SEO?

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

¿Qué es «dev SEO» en la práctica?

Es aplicar prácticas de SEO técnico desde el ciclo de desarrollo: metadata en server components, URLs limpias, rendimiento, schema y monitorización post-deploy, en lugar de parchear problemas después del lanzamiento.

¿Debo usar plugins SEO en WordPress headless?

Sí en el CMS (Yoast + WPGraphQL SEO) para que el frontend consuma títulos y descripciones, pero el HTML final lo genera Next.js: valida siempre el output público.

¿Cuánto tarda Google en indexar cambios técnicos?

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