El problema que moltes empreses no veuen fins que ja és tard
Hi ha un escenari que es repeteix en les auditories SEO tècniques: una empresa inverteix mesos en desenvolupar una aplicació web moderna amb React, Angular o Vue, llança el lloc amb confiança, i setmanes després descobreix que Google no ha indexat la major part del seu contingut. Les pàgines existeixen, es carreguen correctament al navegador, però als resultats de cerca senzillament no apareixen.
Aquest escenari no és excepcional. És la conseqüència directa de construir un lloc que depèn de JavaScript per generar el seu contingut principal sense haver considerat les implicacions per al rastreig i la indexació. El problema no és usar JavaScript. El problema és assumir que els motors de cerca el processaran igual que l’HTML estàtic, quan la realitat és fonamentalment diferent.
Una sola dada il·lustra l’escala del repte: segons Conductor Academy, la renderització de pàgines JavaScript és aproximadament 100 vegades més costosa computacionalment per als motors de cerca que processar HTML estàtic equivalent. Aquesta diferència determina quantes pàgines pot rastrejar Google al teu lloc, quan apareixerà el teu contingut als resultats i, en última instància, quant tràfic orgànic captura la teva web.
Com funciona Googlebot amb JavaScript: el model de dues fases
Per entendre per què JavaScript crea problemes de SEO, cal comprendre com Googlebot el processa, perquè el seu comportament és radicalment diferent al d’un navegador.
Quan un usuari accedeix a una pàgina, el navegador descarrega l’HTML, executa el JavaScript de manera immediata i renderitza el contingut resultant en fraccions de segon. Tot ocorre en un únic procés continu.
Googlebot, en canvi, opera en dues fases completament separades. En la primera fase, el crawler descarrega l’HTML inicial de la URL i l’afegeix a l’índex de Google tal com és en aquell moment. Si aquest HTML és un esquelet buit amb només etiquetes <div> i referències a fitxers JS, això és tot el que Google processa en la primera fase. En la segona fase, Googlebot encua la pàgina per renderitzar-la amb Chromium, executar el JavaScript i processar el contingut final. Aquesta segona fase ocorre en una cua separada i pot demorar-se des d’hores fins a dies o setmanes.
“Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” — Google Search Central
Aquest model de dues fases genera una bretxa temporal d’indexació amb conseqüències directes en el posicionament. El contingut que només existeix després d’executar JavaScript no està disponible per a Google fins que es completi la renderització en la segona fase.
Els deu problemes principals de JavaScript SEO
1. Cua de renderització diferida
El problema central del JavaScript SEO és la separació entre el moment en què Googlebot descarrega una URL i el moment en què executa el seu JavaScript. Aquesta bretxa existeix perquè la renderització JS consumeix molts més recursos computacionals que el processament d’HTML, i Google els gestiona en cues separades amb diferents prioritats.
L’impacte pràctic és que el contingut generat dinàmicament per JavaScript pot trigar dies a aparèixer a l’índex de Google. Per a llocs de notícies, botigues amb catàleg dinàmic o plataformes que publiquen contingut freqüentment, aquest retard té un cost directe en visibilitat.
La solució més efectiva és assegurar-se que el contingut crític per al SEO — incloent text principal, encapçalaments, metadades i enllaços interns — estigui present a l’HTML inicial que retorna el servidor.
2. Fragments URL amb # no indexables
Les Single Page Applications (SPAs) que utilitzen hash-based routing generen URLs del tipus meweb.com/#/producte/123. El fragment # i tot el que va després és processat únicament pel navegador del client i mai s’envia al servidor. Googlebot no pot rastrejar ni distingir entre aquestes URLs.
El resultat és que tot el lloc apareix per a Google com si fos una única URL: meweb.com. Tota l’estructura de pàgines, categories i productes que l’usuari pot navegar és invisible per al motor de cerca.
La solució és migrar a l’ús de la History API, que permet crear SPAs amb URLs netes del tipus meweb.com/producte/123. React Router, Vue Router i Angular Router implementen la History API per defecte des de fa anys.
3. Soft 404 en aplicacions d’una sola pàgina
Un problema específic de les SPAs mal configurades són els “soft 404”. Ocorren quan un usuari accedeix a una URL inexistent en la SPA i l’aplicació renderitza una pàgina d’error però el servidor retorna un codi HTTP 200 OK en lloc del correcte 404.
Google veu el codi 200 i assumeix que la pàgina conté contingut vàlid. Procedeix a indexar-la. El resultat són pàgines d’error indexades que competeixen negativament amb el contingut real del lloc i dilueixen el crawl budget.
La correcció requereix implementar lògica al servidor per retornar els codis HTTP correctes: 404 per a pàgines no trobades, 301 per a redireccions permanents, 410 per a pàgines eliminades definitivament.
4. Lazy loading mal implementat
El lazy loading és una tècnica legítima i recomanada per millorar el rendiment, però si s’implementa incorrectament pot fer que contingut important sigui invisible per a Googlebot.
El problema específic és que Googlebot no fa scroll durant la renderització. Les implementacions de lazy loading que depenen d’events de scroll per carregar contingut mai mostraran aquell contingut al crawler.
La recomanació oficial de Google és usar la Intersection Observer API, que detecta quan un element entra al viewport independentment de com hi ha arribat. Addicionalment, l’atribut loading="lazy" en etiquetes <img> és natiu i segur per al SEO.
5. Scroll infinit sense URLs persistents
Els llocs amb scroll infinit que carreguen contingut addicional quan l’usuari arriba al final de la pàgina tenen un problema SEO clar: si el contingut addicional no té la seva pròpia URL indexable, Googlebot no pot accedir ni indexar-lo.
La solució recomanada per Google combina dos elements: cada “pàgina” del contingut paginat ha de tenir la seva pròpia URL accessible (per exemple, /blog/?page=2); i implementar una paginació HTML convencional addicional, accessible mitjançant etiquetes <a> a l’HTML, que permeti als crawlers seguir tots els continguts.
6. Bloqueig de recursos JavaScript a robots.txt
Un error clàssic però encara freqüent és bloquejar fitxers JavaScript crítics al fitxer robots.txt. Quan Googlebot no pot accedir als fitxers JS necessaris per renderitzar una pàgina, el resultat és que veu únicament l’HTML esquelet buit.
Aquest problema és especialment trampós perquè el lloc funciona perfectament per als usuaris (el seu navegador carrega els JS directament, sense passar per robots.txt) però és invisible per als crawlers.
La verificació és senzilla: usar la URL Inspection Tool de Google Search Console permet comparar com veu Google una URL enfront de com la veu el navegador.
7. Metadades i canonicals injectats per JavaScript
Quan el title, meta description, etiqueta canonical o altres meta etiquetes SEO s’injecten únicament mitjançant JavaScript, existeix el risc que Googlebot processi la versió sense renderitzar i usi els valors incorrectes o buits.
Aleyda Solís, consultora SEO internacional i fundadora d’Orainti, ha documentat aquest problema en múltiples auditories: “Clients using JavaScript for metadata and navigation elements experienced crawling, indexing, and speed performance issues that improved significantly after optimization.”
La pràctica correcta és incloure totes les metadades SEO crítiques directament a l’HTML que retorna el servidor.
8. Esgotament del crawl budget per JavaScript
El crawl budget és la quantitat d’URLs que Googlebot està disposat a rastrejar en un lloc durant un període de temps determinat. JavaScript intensifica el problema del crawl budget perquè cada pàgina que requereix renderització JS consumeix més recursos del crawler que una pàgina HTML estàtica equivalent.
El resultat pràctic és que Googlebot pot rastrejar un nombre significativament menor de pàgines en llocs amb JS intensiu. Per a llocs enterprise, això es tradueix en parts del catàleg sense indexar. Per aprofundir en aquest tema, consulta la nostra guia d’optimització del crawl budget.
9. Incompatibilitat amb crawlers de tercers
Google és el motor de cerca més sofisticat en el processament de JavaScript, però molts altres crawlers rellevants per als negocis no poden executar JS en absolut.
Els crawlers de xarxes socials — inclosos Facebook (Open Graph), LinkedIn i Twitter/X — no executen JavaScript. Això significa que els llocs amb Client-Side Rendering pur mostren targetes de vista prèvia buides o genèriques quan els usuaris comparteixen URLs en aquestes plataformes. El 100% de les vistes prèvies socials d’un lloc CSR pur es veu afectat.
La solució que elimina aquest problema per a tots els crawlers és implementar SSR o pre-rendering, que garanteix que cada URL retorni HTML complet independentment de quin crawler hi accedeixi.
10. Rehydration penalty i temps fins a la interactivitat
El Server-Side Rendering resol els problemes d’indexació, però introdueix un nou risc si no s’implementa correctament: el “rehydration penalty”.
En SSR, el servidor genera l’HTML complet i l’envia al navegador, que pot renderitzar-lo de manera immediata (millorant el LCP). No obstant això, la pàgina no és interactiva fins que el JavaScript del client es descarrega, parseja, executa i fa la “rehydration” dels components. En aplicacions JS pesants, aquest procés pot trigar diversos segons.
L’impacte empresarial és ben documentat: Vodafone va reportar que una millora del 31% en LCP va resultar en un increment del 8% en vendes. Rakuten 24, en optimitzar els seus Core Web Vitals, va aconseguir un augment del 53,37% en revenue per visitant i del 33,13% en taxa de conversió.
El cas Hulu: quan el CSR pur destrueix la indexació
Per il·lustrar l’impacte real d’aquests problemes, el cas documentat de Hulu.com és especialment revelador. Hulu, la plataforma de streaming americana, va desenvolupar el seu lloc web com una aplicació 100% JavaScript amb Client-Side Rendering. El resultat des del punt de vista SEO va ser que les cerques de contingut exclusiu de Hulu a Google pràcticament no retornaven resultats de hulu.com.
La raó era tècnicament simple però devastadora: si s’inspeccionava el codi font HTML de qualsevol pàgina de Hulu, només es trobaven contenidors buits. Etiquetes <div> sense contingut, referències a fitxers JavaScript, però cap text, títol de pel·lícula, descripció ni metadada accessible sense executar JS.
Barry Adams, consultor SEO tècnic de Polemic Digital, resumeix el problema estructural amb precisió: “JavaScript frameworks are great for building web apps with… However, web apps are not websites.”
La distinció importa. Una aplicació web està dissenyada per a usuaris autenticats que hi interactuen repetidament. Un lloc web orientat a la captació de tràfic orgànic necessita ser rastreable, indexable i visible per als motors de cerca des del primer moment en què s’accedeix a una URL.
Les solucions: mapa de decisió tècnica
Server-Side Rendering (SSR)
El SSR és la solució més robusta per als problemes de JavaScript SEO. El servidor executa el codi JavaScript i genera l’HTML complet abans d’enviar-lo als navegadors i crawlers. Cada URL retorna HTML amb tot el contingut, metadades i estructura ja renderitzats.
Els frameworks principals que implementen SSR per a cada ecosistema JS:
- React: Next.js (el més adoptat), Remix
- Vue.js: Nuxt.js
- Angular: Angular Universal
- Sense framework específic: Astro (amb sortida SSR), SvelteKit
El SSR elimina pràcticament tots els problemes descrits en aquest recurs: el contingut és a l’HTML inicial, les metadades són correctes des del primer crawl, el crawl budget es consumeix de manera eficient i tots els crawlers, inclosos els de xarxes socials, veuen el contingut complet.
Static Site Generation (SSG)
El SSG genera l’HTML de totes les pàgines en el moment del build, abans del desplegament. El resultat són fitxers HTML estàtics servits directament des d’un CDN. És l’opció amb millor rendiment SEO possible perquè els crawlers reben HTML pur instantàniament.
La limitació és que no és adequada per a contingut que canvia freqüentment o que depèn de l’usuari. Per a llocs amb contingut relativament estable — blocs, documentació, pàgines de producte — el SSG és l’opció òptima.
Dynamic Rendering com a solució transitòria
El dynamic rendering serveix HTML pre-renderitzat als crawlers i la versió JavaScript completa als navegadors, usant la detecció del User Agent per distingir-los.
“Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” — Google Search Central
Google la reconeix com a vàlida en la seva documentació oficial, però també la qualifica explícitament com un workaround. És útil en contextos de migració gradual des d’una arquitectura CSR pura quan refactoritzar tota l’aplicació a SSR no és immediatament viable.
Taula comparativa d’estratègies de renderització
| Estratègia | Indexabilitat | Rendiment | Complexitat | Cas d’ús |
|---|---|---|---|---|
| CSR pur | Baixa (requereix renderització JS) | Variable | Baixa | Apps sense necessitats SEO |
| SSR | Alta (HTML complet des del servidor) | Alta | Mitjana-alta | Llocs amb contingut dinàmic |
| SSG | Màxima (HTML estàtic) | Màxima | Mitjana | Contingut estàtic o semi-estàtic |
| ISR | Alta | Alta | Mitjana-alta | Catàlegs grans amb actualitzacions periòdiques |
| Dynamic rendering | Mitjana (workaround) | Variable | Alta | Migració gradual des de CSR |
Llista de verificació de JavaScript SEO
Abans de considerar resolts els problemes de JavaScript SEO en un lloc, cal verificar sistemàticament els punts següents:
- Contingut crític a l’HTML inicial: El text principal, els encapçalaments H1-H3 i les metadades estan presents a l’HTML que retorna el servidor, abans d’executar JS?
- Routing net: Les URLs de la SPA usen la History API i no el hash routing (#)?
- Codis d’estat HTTP correctes: Les pàgines no trobades retornen 404, no 200?
- Lazy loading compatible: Les imatges usen
loading="lazy"o Intersection Observer, no scroll events? - Paginació rastrejable: El contingut paginat té les seves pròpies URLs i enllaços
<a>a l’HTML? - Recursos JS desbloquejats: El robots.txt no bloqueja fitxers JS o CSS necessaris per a la renderització?
- Crawlers socials: Les etiquetes Open Graph estan presents a l’HTML del servidor?
- Core Web Vitals: LCP, INP i CLS estan dins dels rangs “Good” de Google?
Per a problemes d’indexació més amplis, la nostra guia sobre problemes d’indexació a Google ofereix un marc de diagnosi complementari.
Conclusió
Els problemes de JavaScript SEO no són inevitables. Són conseqüències de decisions d’arquitectura que es poden corregir. La clau és entendre que els motors de cerca, malgrat les millores significatives en la seva capacitat de processar JavaScript, segueixen tractant l’HTML estàtic de manera més eficient, més ràpida i amb menys cost de recursos.
L’objectiu no és eliminar JavaScript dels llocs web. L’objectiu és assegurar-se que el contingut crític per a la indexació estigui disponible a l’HTML que el servidor retorna, independentment del que faci el JavaScript del costat del client.
Els llocs que implementen SSR, SSG o, com a mínim, contingut crític a l’HTML inicial, no només milloren la seva indexabilitat. També milloren els seus Core Web Vitals, la qual cosa té un efecte positiu documentat en conversió, vendes i retenció d’usuaris.