SEO para desarrolladores: qué medir primero

Escrito por

en

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.

Pirámide de prioridades SEO técnico para desarrolladores: rastreo, indexación, rendimiento y contenido
El SEO técnico tiene un orden de prioridad claro: primero resuelve lo que bloquea el rastreo, después lo que frena la indexación, luego el rendimiento.

Índice

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.

Panel de Core Web Vitals con métricas LCP, INP y CLS en verde
Core Web Vitals en verde: LCP bajo 2,5 s, INP bajo 200 ms y CLS bajo 0,1 son los objetivos mínimos antes de considerar otros factores de rendimiento.

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
PageSpeed Insights CWV de laboratorio + campo, auditoría Lighthouse
Screaming Frog (free tier) Rastreo masivo, redirects, canonicals, meta tags Sí (500 URLs)
curl / httpstatus Cadenas de redirect, headers HTTP, status codes
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?
Diagrama de flujo de trabajo SEO para desarrolladores: pull request, deploy, monitorización semanal
El SEO técnico sostenible se integra en el ciclo de desarrollo, no se aplica como parche después del lanzamiento.

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.

¿Cuánto tarda tu sitio en móvil?

Prueba el simulador PageSpeed gratuito de Veloce Devs o solicita una auditoría técnica con un plan accionable priorizado por impacto SEO.

Probar PageSpeed gratis Hablar con el equipo

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *