SEO técnico para Next.js

El SEO técnico en una aplicación Next.js no es un plugin. Es una propiedad de cómo renderiza la aplicación, y falla de maneras invisibles desde el navegador: una etiqueta canónica que apunta al idioma equivocado, un clúster hreflang que anuncia traducciones que no existen, un sitemap generado a partir de una lista de rutas distinta de la que el router realmente sirve.

Nada de eso se ve en una página que parece correcta cuando la abres. Se ve meses después, como dos URLs repartiéndose el posicionamiento de una página, o como un idioma que nunca llegó a indexarse.

Qué auditamos

• Rastreo y render. Qué recibe el rastreador en el HTML inicial frente a lo que aparece tras la hidratación, y cuál de tus contenidos solo existe en lo segundo.
• Canonicalización. Barras finales, tratamiento de parámetros de consulta, paginación, y si cada ruta está de acuerdo consigo misma sobre su propia dirección.
• Enrutado internacional. El clúster hreflang completo, incluido x-default, validado contra las traducciones que existen de verdad y no contra las que estaban planificadas.
• Datos estructurados. Un @graph conectado con referencias @id estables, no cuatro bloques inconexos que redeclaran la organización cada uno.
• Sitemaps y robots. Generados desde la misma fuente de rutas desde la que renderiza la aplicación, para que no puedan divergir.

Los cinco fallos que más encontramos

Una etiqueta canonical que nunca se escribió. generateMetadata es opcional, así que una ruta sin ella no hereda nada y Google elige una dirección por ti, a menudo la que lleva un parámetro de seguimiento pegado.

Dos URLs que responden las dos. /about y /about/, o un idioma servido tanto en /es/about como en /about. Ambas devuelven 200, ambas se indexan, y la autoridad de la página se reparte entre ellas. La solución es una redirección, no un canonical, y la diferencia importa.

hreflang que anuncia una traducción que nadie escribió. Una lista de idiomas en un archivo de configuración genera los alternates, así que cada página reclama cuatro idiomas cuando solo existen dos. Google sigue la etiqueta, encuentra el idioma equivocado o un 404, y descuenta el clúster entero. Las reglas, en detalle.

Un sitemap construido desde una segunda lista de rutas. Mantenido a mano, o generado desde un escaneo de directorios que no conoce los route groups. Se desincroniza dentro del mismo sprint y a partir de ahí informa mal cada fecha sin que nadie se entere.

Datos estructurados que no describen nada. Cuatro bloques JSON-LD separados, cada uno declarando su propia Organization, ninguno refiriéndose a los demás. JSON válido, ningún grafo, y nada que un buscador pueda resolver como entidad. Cómo es un grafo conectado.

Cómo lo arreglamos

Haciendo imposible equivocarse. Las canónicas, las alternativas y los datos estructurados se generan desde un único helper tipado que toda ruta debe llamar. Una página no puede publicarse sin canónica, porque la función de metadatos no compila sin ella.

Este sitio está construido así, y la implementación es pública: el helper buildMetadata y el grafo JSON-LD de este repositorio son el mismo patrón que desplegamos para clientes.

Ese es todo el método, y conviene decirlo claro porque es lo contrario de cómo se entrega normalmente el SEO técnico. Un documento de hallazgos con cuarenta problemas recibe cuarenta correcciones, y después la página cuarenta y uno sale sin canonical porque la lista era una foto fija y nadie volvió a sacarla. Un canonical generado no se puede omitir en la página siguiente, porque no existe ningún camino de código que produzca una página sin él.

Lo mismo vale para el sitemap y el feed: ambos se derivan de la misma fuente de rutas desde la que renderiza la aplicación, así que una página nueva aparece en ellos porque existe, no porque alguien se acordó. Y el hreflang se genera a partir de las traducciones presentes en disco, de modo que borrar una traducción elimina su etiqueta en el siguiente build en lugar de dejar atrás una promesa.

Donde generar no es posible, la comprobación se traslada a CI. Esta web descarga cada URL de su propio sitemap en cada push y falla el build ante un canonical ausente, duplicado o discordante, ante una página que falta en su propio clúster hreflang, y ante una forma de URL duplicada que responde en lugar de redirigir. El razonamiento detrás de esa comprobación.

Multiidioma, que es donde suele romperse

Una web en un solo idioma tiene una forma de equivocarse con la canonicalización. Una en cuatro idiomas tiene el prefijo de idioma, el idioma por defecto servido sin él, el destino de x-default, la traducción que existe en dos idiomas y se reclama en cuatro, y un selector de idioma construido con un <select> que ningún rastreador puede seguir hasta ninguno de ellos.

Tratamos la lista de idiomas, la regla de prefijo y el inventario de traducciones como una sola fuente de la que leen los metadatos, el sitemap y el selector. La arquitectura que produce eso es la diferencia entre una web con cuatro idiomas y una web con un idioma y tres huérfanos.

Qué no hacemos

Ni estrategia de contenidos, ni investigación de palabras clave, ni construcción de enlaces. Esto es el suelo de ingeniería sobre el que se apoyan esas cosas, y un equipo que te vende las cuatro a la vez suele ser fuerte en una.

También te diremos cuándo el trabajo técnico no es tu limitación. Si tus páginas están correctamente indexadas, resuelven limpiamente y validan, y aun así el tráfico no llega, la respuesta está en el contenido y lo diremos en lugar de facturarte una segunda auditoría.

Cómo se desarrolla un encargo

Primero una lectura cerrada: rastreo, comparación de renderizado, validación de canonicals y hreflang en cada plantilla de ruta, validación de datos estructurados, y análisis de logs donde haya logs de servidor disponibles. Eso produce un documento de hallazgos ordenado por impacto, con cada punto rastreado hasta el código que lo causa.

Después las correcciones, como pull requests en tu repositorio, en ese orden. Y después las comprobaciones que las sostienen: generación donde el fallo era un valor ausente, aserciones en CI donde generar no es posible.

Si solo quieres la primera parte, el documento de hallazgos se sostiene solo y varios clientes lo han implementado ellos mismos. Es un resultado razonable, y la auditoría es el encargo pensado para eso.

El resultado medible

Indexación correcta de las rutas que quieres indexadas, y de nada más. Resultados enriquecidos allí donde el esquema los soporta. Un clúster hreflang que Search Console valida sin avisos. No son trucos de crecimiento; son el suelo sobre el que se apoya una estrategia de contenidos.

Qué recibes

Los hallazgos ordenados por lo que le cuestan, las correcciones como pull requests, y las comprobaciones que impiden que vuelvan. Canonical y sitemap derivados de una sola fuente, hreflang leído de los archivos en vez de una lista, y un rastreo en CI que falla ante un 404 enlazado.

Además, el antes y el después: páginas indexadas, las que Search Console rechazaba y el motivo que daba, y qué cambió cuando la corrección tuvo tiempo de ser rastreada de nuevo. Ese último número llega semanas después del trabajo y lo enviamos igualmente.