SEO tècnic en Next.js: què revisar abans de publicar

Next.js facilita moltes parts del SEO tècnic.

Té una API de metadata, generació de sitemap i robots, Server Components, optimització d'imatges i diverses maneres de renderitzar una pàgina.

Però pots fer servir tot això i publicar igualment una web amb canonicals contradictòries, idiomes mal connectats, pàgines inexistents que responen amb un 200 o contingut que Google amb prou feines pot descobrir.

El framework et dona eines.

La implementació continua sent cosa teva.

Aquesta és la llista que revisaria abans de publicar un projecte amb App Router.

Metadata: cada pàgina s'ha de descriure bé

Next.js permet definir metadata estàtica amb metadata o generar-la a partir de dades amb generateMetadata.

Revisaria:

• un title propi i descriptiu a les pàgines importants;
• una description coherent amb el contingut real;
• metadataBase ben configurat si fas servir URL relatives a la metadata;
• una canonical correcta;
• Open Graph quan importa com es comparteix la pàgina.

No faria servir generateMetadata només perquè existeix.

Si la informació és estàtica, metadata és més senzill.

A les pàgines dinàmiques —un producte, un projecte o un article— generateMetadata permet construir aquestes dades a partir del contingut.

En les versions actuals de Next.js, una part de la metadata dinàmica es pot enviar en streaming. Next.js documenta que Googlebot interpreta aquesta metadata després del render i manté un tractament diferent per als bots que l'han de trobar directament al <head>.

No ho faria servir com a excusa per deixar de comprovar què acaba generant realment cada URL.

Canonicals: coherència, no un pedaç per a qualsevol URL

Una canonical indica quina URL prefereixes dins d'un conjunt de pàgines duplicades o molt semblants.

En una web normal comprovaria que:

• les pàgines principals tenen una canonical coherent;
• el sitemap, els enllaços interns i la canonical no es contradiuen;
• les variants realment duplicades apunten a la destinació correcta;
• els enllaços interns fan servir directament la URL que vols conservar.

No faria servir les canonicals com a substitut de qualsevol problema d'indexació.

Un filtre, una combinació de paràmetres i una paginació no són automàticament el mateix cas.

De fet, Google recomana no fer servir la primera pàgina d'una seqüència paginada com a canonical de les altres, sinó donar a cada pàgina la seva pròpia URL canònica.

Abans de posar una canonical cap a una altra URL, la pregunta és:

aquestes dues pàgines representen realment el mateix contingut o un de molt semblant?

Hreflang: connectar les versions que existeixen de debò

En una web multilingüe revisaria:

• que cada idioma declari les altres versions corresponents;
• que els enllaços siguin recíprocs;
• que cada pàgina també s'inclogui a si mateixa;
• que els codis d'idioma i regió siguin vàlids;
• que les URL declarades siguin completes, amb el domini;
• que cap URL declarada acabi en un 404 o una redirecció;
• i que un slug traduït apunti al seu equivalent real, no simplement al mateix path amb un altre prefix.

Next.js permet fer-ho amb alternates.languages.

També pot incloure els alternates dins del sitemap.

No cal fer servir tots els mètodes alhora: per a Google són equivalents.

L'important és que la família d'URL sigui correcta i fàcil de mantenir.

Si fas servir una versió per defecte per als idiomes que no tens, també pots declarar x-default.

Sitemap, robots i indexabilitat són coses diferents

Un sitemap hauria de representar les URL que realment vols presentar als cercadors.

No hi posaria:

• redireccions;
• 404;
• esborranys;
• pàgines que porten noindex a propòsit;
• variants duplicades que no vols conservar.

Next.js permet generar sitemap.ts i robots.ts, però que aquests fitxers existeixin no vol dir que estiguin ben configurats.

També convé separar conceptes.

robots.txt controla sobretot el rastreig.

noindex indica que una pàgina no ha d'aparèixer als resultats.

I una zona realment privada necessita autenticació o control d'accés: noindex no converteix una URL pública en privada.

Redireccions i errors: que la resposta HTTP digui la veritat

Quan una URL canvia, l'antiga hauria de portar directament a la nova.

Sense A → B → C.

Millor A → C.

Amb les redireccions permanents de next.config (permanent: true), Next.js fa servir actualment un 308. Si en algun cas necessites un altre codi, es pot indicar amb statusCode.

Si el recurs simplement no existeix i no té substitut, tornar un 404 real és correcte.

A les rutes dinàmiques, notFound() permet gestionar aquest cas sense acabar mostrant una pàgina d'error amb un 200.

També revisaria que cap enllaç intern continuï passant per redireccions un cop acabada una migració.

Google pot executar JavaScript. Això no vol dir que tot sigui igual

Googlebot renderitza JavaScript.

Per això una web no deixa de ser indexable només perquè tingui Client Components o contingut generat amb JS.

Tot i així, Google continua considerant el renderitzat al servidor (SSR) i el prerenderitzat bones opcions, perquè milloren l'experiència per als usuaris i els crawlers, i no tots els bots executen JavaScript.

La revisió pràctica és més senzilla:

el contingut que vols indexar acaba sent accessible sense dependre d'una acció humana que el crawler no farà?

Un acordió no és cap problema si el contingut forma part de la pàgina.

En canvi, si l'única manera d'obtenir informació important és prémer un botó que llança una petició després, no donaria per fet que un crawler farà aquest recorregut. Google ho diu explícitament: els seus rastrejadors no fan clic en botons ni acostumen a executar funcions que requereixen una acció de l'usuari.

El mateix passa amb els enllaços.

Si una URL importa, s'hauria de poder descobrir amb un enllaç real amb href, no només amb un gestor de clic.

Dades estructurades: només quan descriuen el que hi ha de debò

No totes les pàgines necessiten un schema diferent.

Faria servir JSON-LD quan hi ha un tipus útil per representar el contingut visible:

• Organization o LocalBusiness;
• BlogPosting;
• BreadcrumbList;
• Product;
• o altres tipus que realment hi corresponguin.

El marcatge ha de coincidir amb el que veu una persona.

I que passi el Rich Results Test vol dir que la implementació és vàlida per a aquesta comprovació, no que Google hagi de mostrar necessàriament un resultat enriquit.

Next.js recomana incloure el JSON-LD amb un <script type="application/ld+json"> normal.

Si l'objecte incorpora contingut extern o generat pels usuaris, també cal tractar aquests valors de manera segura abans de serialitzar-los.

Imatges i rendiment

next/image resol molt bé molts casos habituals:

• mides responsives;
• lazy loading per defecte;
• reserva d'espai;
• optimització de formats i dimensions.

Però tampoc no és una norma del tipus "totes les imatges han de fer servir next/image".

Per a les imatges que formen part del contingut, sí que sol tenir molt de sentit.

A les imatges principals revisaria sobretot que no estiguis endarrerint l'element que acaba sent el LCP.

A Next.js 16, priority ha quedat obsolet. Hi ha preload, loading="eager" i fetchPriority, i triar-ne un depèn del cas; la mateixa documentació recomana normalment eager o fetchPriority="high" abans que precarregar sense necessitat.

També revisaria:

• un alt útil a les imatges amb contingut;
• alt="" a les purament decoratives;
• dimensions o proporcions correctes;
• sizes quan una imatge responsive ho necessita;
• els scripts de tercers;
• les fonts;
• i les Core Web Vitals reals.

No per aconseguir un 100.

Sinó per evitar que una decisió tècnica converteixi una pàgina senzilla en una cosa innecessàriament pesada.

Si vols entrar en les mètriques, ho expliquem a part a Core Web Vitals.

Després de publicar

Abans de donar una web per acabada comprovaria:

1. Search Console configurat.
2. Sitemap accessible i enviat.
3. Les pàgines importants són rastrejables i indexables.
4. La canonical i el hreflang surten com esperàvem.
5. Les redireccions i els 404 responen amb l'estat correcte.
6. No queden enllaços interns trencats o que passin per redireccions sense necessitat.
7. Les dades estructurades importants validen.
8. La web funciona igual de bé al mòbil i a l'ordinador.

Després comença la part que cap checklist no pot resoldre: si hem construït les pàgines que realment necessitàvem.

Pots tenir una implementació tècnica impecable i una arquitectura que no respon cap cerca útil.

Per això el SEO tècnic és una base, no l'estratègia sencera.

Si necessites treballar totes dues parts des del principi, és el que plantegem a Web + SEO.