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
404o 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 (sinwwwduplicado si tu política es apex).hreflangcoherente en sitios multidioma (en,es,x-defaultsi aplica).noindexaccidental 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.xmly 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:
- ¿La URL canónica y hreflang están en el HTML servido (View Source, no solo en React devtools)?
- ¿El sitemap incluye solo URLs indexables (sin borradores, sin
noindex)? - ¿Hay un solo H1 por vista y jerarquía H2/H3 lógica?
- ¿Imágenes con
altdescriptivo y formatos modernos (WebP/AVIF)? - ¿Lighthouse móvil ≥ 90 en rendimiento y SEO en plantilla afectada?
- ¿Redirects
301para URLs legacy y rutas sin locale? - ¿Search Console sin nuevos errores
5xxo404tras el deploy? - ¿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.
¿Quieres un diagnóstico en tu dominio?
Prueba el simulador PageSpeed gratuito o habla con un ingeniero de Veloce Devs para un plan SEO técnico accionable.
Deja una respuesta