Guia SEO per a webs amb base JavaScript

Com a agència SEO, cada cop rebem més projectes construïts amb React, Vue, Angular, Next.js o Nuxt. Són webs ràpides i amb una experiència d'aplicació excel·lent, però plantegen un repte molt concret: el cercador no veu les pàgines igual que un usuari. El SEO per a webs amb base JavaScript no és un món a part amb regles pròpies; són els mateixos principis de sempre condicionats per com i quan es renderitza el contingut. Si l'HTML arriba buit i el contingut apareix només després d'executar JavaScript al navegador, t'ho jugues amb la indexació. La bona notícia és que això es resol amb una estratègia de renderitzat deliberada. En aquesta guia expliquem com abordar el SEO per a webs amb base JavaScript sense sorpreses a Google.

SEO per a webs amb base JavaScript:

• Com rastreja i indexa Google el JavaScript
• Models de renderitzat: CSR, SSR, SSG i ISR
• La hidratació i el seu impacte en el SEO
• Errors freqüents que arruïnen la indexació
• Enllaçat intern i navegació
• Metadades, canonical i dades estructurades
• Core Web Vitals i INP
• Prerendering i renderitzat dinàmic
• Com comprovar què veu Google
• Conclusió: decisions d'arquitectura

Com rastreja i indexa Google el JavaScript

Google processa les webs amb JavaScript en dues fases. Primer rastreja l'HTML inicial i n'extreu el que hi troba. Després, la pàgina entra en una cua de renderitzat on el Web Rendering Service executa el JavaScript i analitza el DOM final. Entre una fase i l'altra pot passar temps, i si el codi és complex o falla, el contingut pot quedar invisible o indexar-se en el seu estat esquelet. Aquesta és la clau de tot el SEO per a webs amb base JavaScript: com més depengui el teu contingut d'executar-se al client, més marge hi ha perquè alguna cosa es perdi pel camí. Altres cercadors i molts crawlers d'IA renderitzen JavaScript pitjor que Google, així que jugar-s'ho tot al renderitzat en client és arriscat.

Models de renderitzat: CSR, SSR, SSG i ISR

La decisió més important és el model de renderitzat. El renderitzat en client (CSR) envia un HTML gairebé buit més un bundle de JavaScript que construeix la pàgina al navegador; dona una gran experiència després de la primera càrrega, però alenteix i complica la indexació. El renderitzat al servidor (SSR) genera l'HTML complet a cada petició, de manera que el cercador rep el contingut a punt sense executar res; millora el SEO i la velocitat percebuda a canvi de més càrrega de servidor. La generació estàtica (SSG) i la regeneració incremental (ISR) preconstrueixen les pàgines al build i les refresquen segons convingui: càrregues molt ràpides i SEO sòlid per a contingut que no canvia a cada segon.

La nostra regla pràctica: fes servir SSR o SSG/ISR per a tot el que hagi de posicionar (pàgines de màrqueting, fitxes, articles) i reserva el CSR per a zones privades que no necessiten indexar-se, com panells o àrees d'usuari. Quan dubtis, lliura HTML amb sentit d'entrada. Frameworks com Next.js, Nuxt o SvelteKit estan pensats per a això des del disseny, cosa que dona avantatge a una web a mida davant de solucions que ho afegeixen a posteriori.

La hidratació i el seu impacte en el SEO

L'enfocament híbrid més estès combina SSR amb interactivitat en client mitjançant la hidratació: el servidor lliura l'HTML i després el JavaScript "reconnecta" els components per fer-los interactius. Sona ideal, però és on molts projectes perden posicions. Si l'HTML del servidor no coincideix amb el que el client espera, el framework pot llençar el DOM i reconstruir-lo, duplicant el cost de renderitzat. I una hidratació pesada bloqueja el fil principal, empitjora la interactivitat i penalitza els Core Web Vitals. Les solucions passen per dividir el codi (code splitting), carregar de manera diferida els components que no són a pantalla i aplicar tècniques com la hidratació selectiva o parcial per enviar menys JavaScript. Menys codi a la càrrega inicial és gairebé sempre millor SEO.

Errors freqüents que arruïnen la indexació

En auditories ens trobem sempre els mateixos errors. Contingut important o enllaços que només apareixen després d'una interacció de l'usuari, i que el cercador no dispara mai. Meta tags i canonical injectats per JavaScript després de la càrrega, quan haurien de venir en l'HTML inicial. Enllaços interns implementats com a gestors d'esdeveniments (onclick) en lloc d'etiquetes <a href> reals, invisibles per al rastrejador. I bundles gegants que esgoten el pressupost de rastreig i deixen pàgines sense indexar. La prova definitiva és senzilla: desactiva JavaScript i mira si el contingut crític, els enllaços i les metadades continuen sent-hi.

Enllaçat intern i navegació

El rastrejador descobreix pàgines seguint enllaços, i només entén enllaços reals. Fes servir sempre <a href> amb URL rastrejables per a la navegació interna, mai una navegació governada exclusivament per estat de JavaScript. Cuida que les rutes de l'aplicació tinguin URL netes i úniques per contingut, no fragments gestionats només en client. Un bon enllaçat intern reparteix autoritat cap a les pàgines que vols posicionar i ajuda que el cercador arribi a tot el lloc en pocs clics. Aquest és un principi de SEO tècnic que no canvia per fer servir JavaScript, però que en una SPA cal vigilar de prop.

Metadades, canonical i dades estructurades

Els títols, meta descriptions, canonical i dades estructurades han de ser presents en l'HTML que rep el cercador, no afegir-se tard per JavaScript. Amb SSR o SSG això es resol de manera natural. Cada ruta ha de tenir el seu propi title i la seva meta description únics, el seu canonical correcte i, quan escaigui, el seu marcatge schema en JSON-LD dins de la resposta del servidor. En aplicacions d'una sola pàgina cal assegurar-se que aquests elements s'actualitzen per ruta i queden en l'HTML servit. Comprova amb "veure codi font" que tot és on ha de ser.

Core Web Vitals i INP

El rendiment és ranking, i el JavaScript és el principal enemic aquí. Des del 2024, l'INP (Interaction to Next Paint) va substituir l'FID com a mètrica d'interactivitat dins dels Core Web Vitals, i mesura com de ràpid respon la pàgina a les accions de l'usuari. Els bundles pesats i la hidratació lenta disparen l'INP, mentre que el CSR endarrereix l'LCP i facilita salts de layout que empitjoren el CLS. Les tres mètriques pateixen amb un renderitzat en client mal gestionat. Prioritza: lliurar contingut significatiu com més aviat millor, dividir i diferir el JavaScript no crític, reservar espai per evitar salts i vigilar les dades de camp a Search Console, no només les xifres de laboratori.

Prerendering i renderitzat dinàmic

Si no pots migrar a SSR o SSG de cop, el prerendering és una via intermèdia: serveis que generen una versió estàtica prerenderitzada de les teves pàgines per als cercadors mentre l'usuari continua rebent l'experiència dinàmica. El renderitzat dinàmic (servir HTML pla als bots i la versió JavaScript als usuaris) va ser una recomanació de Google en el seu moment, però avui es considera una solució temporal, no una arquitectura a llarg termini. Fes-lo servir com a pedaç puntual mentre redissenyes el model de renderitzat, no com a destinació final.

Com comprovar què veu Google

No donis res per fet: mesura. L'eina d'inspecció d'URL de Google Search Console mostra l'HTML renderitzat que veu Googlebot i revela quin contingut falta a la càrrega inicial. Completa-ho desactivant JavaScript per verificar què queda, revisant la consola del navegador a la cerca d'errors d'hidratació i fent servir eines de rastreig que executin JavaScript per simular el renderitzat. Les pàgines marcades com a "Rastrejada: actualment sense indexar" solen ser un símptoma de problemes de renderitzat o rendiment.

Conclusió: decisions d'arquitectura

El SEO per a webs amb base JavaScript es guanya o es perd en l'arquitectura, no en els retocs d'última hora. Triar bé el model de renderitzat, lliurar HTML amb sentit d'entrada, mantenir enllaços i metadades rastrejables i controlar el pes del JavaScript resol la immensa majoria dels problemes. Si estàs construint una web nova, decideix l'enfocament de renderitzat des del primer dia; si el teu projecte ja no rendeix als cercadors, una auditoria tècnica identificarà on s'està perdent el contingut. En projectes d'e-commerce a mida o webs complexes, aquesta planificació és la diferència entre indexar bé o no aparèixer. Des de la nostra agència podem ajudar-te a plantejar l'arquitectura correcta.