Arquitectura web i SEO: estructura que posiciona | Ighenatt

Què és l’arquitectura web i per què Google la necessita

Imagina que el teu lloc web és un edifici d’apartaments. Googlebot és el carter que ha de lliurar correu a cada un dels pisos. Si l’edifici no té ascensor, la senyalització és incompleta i alguns passadissos no connecten amb els altres, el carter perdrà molt de temps — o directament no arribarà a algunes portes. L’arquitectura web és exactament això: el plànol de l’edifici que determina com es mou Google pel teu lloc.

I el problema amb molts llocs és que ningú va pensar en el plànol abans de construir. Es van anar afegint pàgines, seccions i categories sense una lògica de conjunt, fins que l’estructura resultant és un laberint.

Adrien Menard, CEO de Botify, ho va quantificar el 2019 amb una dada que encara circula en els debats de SEO tècnic professional: més del 50% de les pàgines en llocs enterprise directament no són rastrejades pels cercadors. La causa principal no és la velocitat ni el contingut — és l’arquitectura.

L’arquitectura web comprèn tres coses concretes:

• Com s’organitzen les pàgines en jerarquies (pàgina d’inici → categories → subcategories → pàgines de detall)
• Com s’enllacen entre si (quines pàgines apunten a quines altres)
• Com es reflecteixen aquestes decisions en l’estructura d’URLs

Aquestes tres variables determinen dues coses que a Google li importen molt: quantes pàgines pot rastrejar en cada visita (el pressupost de rastreig) i quanta autoritat distribueixen aquelles pàgines entre elles a través de l’enllaçat intern.

Estructura plana vs. profunda: quan usar cada una

La profunditat d’un lloc es mesura en clics des de la pàgina d’inici. Una pàgina a 1 clic està al menú principal. A 2 clics, en una categoria. A 5 clics, enterrada en una subcategoria d’una subcategoria d’una categoria.

Hi ha dos models extrems i molts punts intermedis entre ells.

Arquitectura plana

Totes les pàgines estan a pocs clics de la pàgina d’inici. Per a un restaurant de Barcelona amb 15 pàgines (carta, reserves, història, equip, contacte…), l’arquitectura plana és el natural: menú principal amb 6-7 seccions, cadascuna apuntant directament a la pàgina corresponent.

Avantatges concretes:

• Googlebot arriba a totes les pàgines en poques visites
• L’autoritat de la pàgina d’inici es distribueix directament a pàgines estratègiques
• L’usuari també navega sense fricció

Arquitectura profunda

Com més pàgines té un lloc, més difícil resulta mantenir-les totes a pocs clics. Una botiga en línia amb 3.000 productes necessita categories, subcategories i filtres que inevitablement afegeixen profunditat. El risc aquí és que els productes importants quedin a 5-6 clics de la pàgina d’inici i Google els rastreggi amb poca freqüència.

La documentació oficial de Google Search Central és clara al respecte: les pàgines importants han de ser accessibles en pocs clics des de la pàgina d’inici. No especifica quants exactament, però la recomanació pràctica del sector és no superar els 3-4 clics per a cap pàgina que vulguis que Google rastreggi activament.

Per a un ecommerce de moda amb 500 referències actives, l’estructura òptima seria:

Pàgina d'inici (0 clics)
  → /roba-dona/ (1 clic)
    → /roba-dona/vestits/ (2 clics)
      → /roba-dona/vestits/vestit-lli-blau/ (3 clics)

Quatre nivells per a qualsevol producte. Manejable. Si la mateixa botiga afegeix filtres de talla, color i ocasió com a URLs indexables, pot acabar amb pàgines a 6-7 clics que Google mai veu.

La regla pràctica

Per a llocs de menys de 1.000 pàgines: arquitectura plana, màxim 3-4 clics per a qualsevol pàgina. Per a llocs de més de 10.000 pàgines (ecommerce gran, portals de contingut, marketplaces): accepta la profunditat però assegura que les categories principals estiguin a 1-2 clics i els productes o articles a 3-4. Més enllà de 4 clics, cada pàgina afegida té rendiments decreixents en termes de rastreig.

Disseny d’URLs SEO-friendly: principis i errors

Aquí arriba el punt contraintuïtiu que molts SEOs no esperen: l’estructura de carpetes a la URL importa considerablement menys del que es creu.

John Mueller, Search Advocate de Google, ho va explicar amb precisió en un Webmaster Hangout de març del 2022:

“Per a nosaltres, no ens importa tant l’estructura de carpetes, ens centrem essencialment en l’enllaçat intern. És realment com des de la pàgina d’inici o des de la pàgina principal — quant ràpid podem arribar a aquella pàgina específica?”

Això té una implicació directa: la URL /auditoria-seo/ no posiciona pitjor que /serveis/seo/tecnic/auditoria/ per ser “més curta” o tenir “menys jerarquia”. El que determina la importància de la pàgina per a Google és quants clics la separen de la pàgina d’inici a través d’enllaços interns, no quants directoris té la URL.

El que sí importa a les URLs:

Llegibilitat i consistència. Les URLs han de descriure el contingut que contenen, usant paraules (no IDs o paràmetres) i separadors de guionet (-), no guió baix. /que-es-el-seo/ és millor que /que_es_el_seo/ o /p?id=347.

Sense paràmetres innecessaris. Els filtres de cerca, les sessions d’usuari i els paràmetres de campanya afegits directament a la URL creen versions duplicades del mateix contingut. Google pot acabar rastrejant /productes/?color=blau&talla=M&ordre=preu com una URL independent, multiplicant el nombre de pàgines que ha de visitar sense que cap d’elles aporti valor.

Canonical i deduplicació. Quan la mateixa pàgina és accessible des de diverses URLs (amb i sense www, amb paràmetres de sessió), cal establir la URL canònica per evitar que Google distribueixi el pressupost de rastreig entre versions duplicades del mateix contingut.

Evitar canvis freqüents. Cada vegada que canvia la URL d’una pàgina, si no hi ha una redirecció 301 correcta, Google perd l’historial de rastreig d’aquella URL. Una migració web mal executada pot causar pèrdues de trànsit que triguen mesos a recuperar-se.

Models d’arquitectura: silo, hub-and-spoke, flat

Més enllà de “plana vs. profunda”, en SEO es treballa amb tres models d’organització que tenen implicacions distintes per a l’enllaçat intern.

Model silo

El contingut s’organitza en grups temàtics aïllats. L’enllaçat intern flueix preferentment dins del mateix silo: la pàgina de categoria enllaça a les de subcategoria, les de subcategoria enllacen a les de detall, i l’enllaçat entre silos distints es manté mínim.

La lògica darrere del model silo és la consolidació de rellevància temàtica. Si un despatx d’advocats té una secció de dret penal i una altra de dret laboral, mantenir-les com a silos separats amb enllaçat intern propi pot ajudar Google a entendre que el despatx té autoritat diferenciada en cada àrea.

La limitació pràctica és la rigidesa. Els silos purs són difícils de mantenir quan el contingut té connexions naturals entre àrees temàtiques. Forçar aquesta separació pot resultar en una experiència d’usuari artificial.

Model hub-and-spoke

Hi ha pàgines “hub” (nucli) que funcionen com a centres temàtics i pàgines “spoke” (radi) que desenvolupen subtemes relacionats i enllacen de tornada al hub. És el model darrere de les estratègies de contingut pilar o topic clusters.

Un hub podria ser una guia completa sobre “SEO per a ecommerce”. Els spokes serien articles específics sobre velocitat de càrrega, estructura d’URLs de producte, schema de producte, gestió de variants… Tots enllacen al hub i el hub hi enllaça a tots ells.

Aquest model funciona bé per a llocs de contingut (blocs, portals de recursos) perquè reforça la rellevància temàtica sense imposar la rigidesa del silo.

Arquitectura plana (flat)

Per a la majoria de PIMES amb llocs de 20-100 pàgines, l’arquitectura plana és l’opció més pràctica i suficient. Menú principal que dona directament a les pàgines més importants. Poques categories intermèdies. Màxima accessibilitat des de la pàgina d’inici.

Un restaurant no necessita un silo de “carta d’hivern vs carta d’estiu”. Una clínica dental no necessita un hub-and-spoke d’implantologia. La complexitat d’arquitectura ha d’estar justificada pel volum de contingut, no per l’aspiració de semblar un lloc més sofisticat.

Com planificar l’arquitectura abans de construir

L’arquitectura web es dissenya abans de desenvolupar, no després. Canviar-la a posteriori és possible però costós: requereix redireccions massives, actualitzacions de menús i enllaçat intern, i temps fins que Google processa els canvis.

Pas 1: inventari de contingut

Abans de dibuixar cap mapa del lloc, llista tot el contingut que tindrà el lloc. Per a cada pàgina, defineix:

• Quina paraula clau principal abordarà
• Quina audiència específica la necessitarà
• Si té relació amb altres pàgines de l’inventari

Aquest inventari revela automàticament les agrupacions naturals i la profunditat que necessitarà el lloc.

Pas 2: mapa de jerarquia

Amb l’inventari a mà, agrupa les pàgines en categories i defineix quants nivells necessites. La regla és: usa el mínim de nivells necessaris perquè l’estructura sigui comprensible. Cada nivell afegit és un clic més que Googlebot ha de fer i un pas més que l’usuari ha de navegar.

Eines com Whimsical, Miro o fins i tot un full de càlcul són suficients per a aquest exercici. No necessites programari especial — necessites claredat sobre la lògica d’agrupació.

Pas 3: definició de l’enllaçat intern

La jerarquia de pàgines determina l’enllaçat intern automàtic (menú, breadcrumbs, llistes de categoria). Però l’enllaçat intern també inclou els enllaços manuals dins del contingut, i aquests són els que més impacte tenen en la distribució d’autoritat.

Defineix quines pàgines són estratègiques (les que més vols que posicionin) i assegura’t que reben enllaços des de múltiples pàgines del lloc, no només des del menú principal. Una pàgina de servei que rep 10 enllaços interns des d’articles de bloc relacionats té més senyals d’importància per a Google que una que només apareix al menú.

Pas 4: gestió d’URLs tècniques de baix valor

Qualsevol lloc genera URLs que no aporten valor: pàgines de resultats de cerca interna, filtres d’ecommerce, paràmetres de sessió, pàgines de paginació sense contingut únic. Aquestes URLs consumeixen pressupost de rastreig sense aportar valor.

La decisió sobre cada tipus d’URL tècnica s’ha de prendre abans de llançar el lloc, no quan el problema ja és en producció:

Per a llocs ecommerce amb milers de productes i variants, aquesta gestió és la diferència entre que Google rastreggi el 5% o el 80% del catàleg real.

Arquitectura per a llocs multilingüe

Els llocs amb contingut en diverses llengües afegeixen una capa de complexitat a l’arquitectura: cada pàgina té potencialment tres o quatre versions (una per locale), i Google ha de saber quina versió mostrar a cada usuari segons la seva llengua i ubicació.

La implementació tècnica d’això són les etiquetes hreflang, però les etiquetes hreflang són només el mecanisme. L’arquitectura és la decisió prèvia.

Opcions d’estructura d’URL per a multilingüe

Subdirectoris per locale (la més habitual): ighenatt.es/en/, ighenatt.es/ca/. Tota l’autoritat de domini es concentra en un sol domini. Google les processa bé i és l’opció recomanada per la documentació oficial per a la majoria de casos.

Subdominis: en.ighenatt.es, ca.ighenatt.es. Tècnicament funciona però distribueix l’autoritat entre subdominis i requereix més feina de verificació a Search Console.

Dominis distints: ighenatt.com per a anglès, ighenatt.es per a castellà. Només té sentit quan hi ha una raó de negoci molt clara per mantenir presències de domini separades, ja que implica construir autoritat des de zero en cada domini.

Què fa que l’arquitectura multilingüe falli

L’error més habitual no és l’elecció d’estructura d’URL, sinó la inconsistència en l’enllaçat hreflang. Cada URL en un locale ha de tenir etiquetes hreflang que apuntin als seus equivalents en els altres locales, i aquests equivalents han de tenir etiquetes de retorn cap a la primera. Si una pàgina en anglès apunta a la seva versió en català però la versió catalana no apunta de tornada, Google pot ignorar la relació.

El segon error freqüent és traduir el contingut sense adaptar les URLs. Una URL com /serveis/seo-barcelona/ té sentit en català. El seu equivalent en anglès hauria de ser /en/services/barcelona-seo/, no /en/serveis/seo-barcelona/. Google usa la URL com a senyal de locale, i una URL en català dins d’una secció en anglès genera senyals contradictòries.

Auditoria d’arquitectura: eines i mètriques

Un cop el lloc és en producció, l’arquitectura s’audita mesurant exactament què rastreja Google i comparant-ho amb el que hauria de rastrejar.

La dada que ho canvia tot: el cas d’estudi del marketplace de vehicles

Botify va documentar el cas d’un marketplace de vehicles en línia dels EUA amb 10 milions de pàgines al servidor. La situació inicial era la següent: Google només rastrejava 50.000 d’aquelles 10 milions d’URLs — el 0,5%. El 98% del pressupost de rastreig es consumia en URLs sense valor: filtres de refinament amb paràmetres infinits, permutacions d’URL que duplicaven el mateix llistat de cotxes amb ordenacions distintes, pàgines de paginació que Google visitava repetidament sense descobrir contingut nou.

Les intervencions van ser tres:

1. Actualització del robots.txt per bloquejar les URLs de refinament sense valor
2. Reducció del 50% del total d’URLs conegudes per Google mitjançant canonical i noindex
3. Millora de l’enllaçat intern perquè Google arribés més fàcilment a les fitxes de vehicles rellevants

Resultat en tres mesos: el rastreig va passar del 0,5% al 9,5% (+19x), i el trànsit orgànic es va duplicar de 40.000 a 80.000 visites setmanals. Les primeres millores van ser visibles en sis setmanes.

Aquest cas il·lustra alguna cosa que val la pena subratllar: el problema no era la manca de pàgines, sinó l’excés de pàgines sense valor que impedien a Google arribar a les que sí importaven.

Mètriques d’auditoria d’arquitectura

Profunditat de clic des de la pàgina d’inici. Eines com Screaming Frog o Sitebulb rastregen el lloc simulant el comportament de Googlebot i mostren a quants clics està cada URL des de la pàgina d’inici. Una distribució saludable té la majoria de pàgines estratègiques a 1-3 clics.

URLs rastrejades vs. URLs enviades al sitemap. Google Search Console mostra quantes URLs ha rastreig Google vs. quantes URLs apareixen al teu sitemap. Si hi ha una diferència gran, hi ha pàgines que Google no està assolint.

Pàgines rastrejades sense valor. Un rastreig complet amb Screaming Frog identifica quantes URLs del lloc són paràmetres, duplicats, pàgines de filtre o paginació que Google rastreja innecessàriament. Aquesta xifra dividida pel total d’URLs rastrejades dona la proporció de “malbaratament” del pressupost de rastreig.

Distribució d’enllaços interns. Eines com Ahrefs, Screaming Frog o Sitebulb mostren quants enllaços interns rep cada URL. Les pàgines estratègiques han de rebre més enllaços interns que les pàgines de suport. Si les pàgines millor enllaçades internament són la política de privacitat i l’avís legal, hi ha un problema de distribució d’autoritat.

Gary Illyes i el rastreig més intel·ligent

A LinkedIn a l’abril del 2024, Gary Illyes (analista de Google) va compartir una observació rellevant sobre com ha evolucionat el comportament del rastreig:

“Rastregem aproximadament el mateix que abans, però la programació s’ha tornat més intel·ligent i ens centrem més en URLs que tenen una probabilitat més alta de merèixer el rastreig.”

La implicació pràctica és directa: si el teu lloc té moltes URLs de baix valor, Google les prioritzarà menys, la qual cosa significa menys visites a les URLs estratègiques. Optimitzar l’arquitectura no només ajuda que Google arribi a més pàgines — també influeix en la freqüència amb què hi torna.

Una arquitectura ben dissenyada no es veu, però sí es nota en el rastreig. Si vols saber quin percentatge del teu lloc s’està rastrejant i quina estructura té més sentit per al teu cas, a Ighenatt ho avaluem en qualsevol auditoria SEO inicial. Explica’ns el teu cas.