L’error més car en SEO: auditar malament
Fa sis mesos, un e-commerce amb 12.000 productes va contractar una auditoria SEO. L’informe tenia 47 pàgines. Llistava 312 errors. Incloïa captures de Screaming Frog, gràfics de PageSpeed i una matriu de priorització amb colors vermell, groc i verd. El problema: l’equip va implementar els 312 errors en ordre d’aparició, va dedicar tres mesos de desenvolupament a corregir warnings de baixa prioritat i no va tocar l’únic problema que realment importava: 4.200 pàgines de producte amb canonicals apuntant a URLs amb paràmetres de sessió que generaven contingut duplicat massiu. El trànsit orgànic va continuar caient.
Aquesta història es repeteix en empreses de totes les mides. L’auditoria SEO no falla per manca d’eines o per desconeixement tècnic. Falla per absència de metodologia. Executar Screaming Frog i exportar un CSV amb errors no és una auditoria; és un inventari. La diferència entre ambdues coses és exactament el que separa els llocs que milloren després d’una auditoria dels que continuen estancats.
Una auditoria SEO tècnica real segueix un procés de cinc fases on cada fase alimenta la següent. No es tracta de trobar tots els errors possibles, sinó de trobar els errors que importen, entendre el seu impacte en el negoci i prioritzar les correccions en funció d’un criteri que cap eina pot automatitzar: el judici sobre què afecta més al rendiment orgànic del lloc.
En aquesta guia recorrerem aquest procés fase per fase, amb les eines específiques que necessites a cada etapa, les dades que has d’extreure i com convertir troballes tècniques en un pla d’acció que el teu equip de desenvolupament pugui executar en ordre d’impacte.
Per què necessites una auditoria SEO tècnica (i quan fer-la)
La raó més habitual per posposar una auditoria és que “el lloc funciona bé.” I en molts casos és cert: les pàgines carreguen, Google les indexa i el trànsit orgànic no ha caigut dràsticament. Però la salut tècnica d’un lloc no és binària. No es passa de “funciona” a “no funciona” d’un dia per l’altre. Es deteriora progressivament, de forma silenciosa, fins que un canvi algorítmic o una acumulació de deute tècnic provoca un enfonsament que sembla sobtat però que portava mesos gestant-se.
Els símptomes que justifiquen una auditoria tècnica immediata són concrets. Si a Google Search Console tens més d’un 15% de les teves URLs en estat “Discovered - currently not indexed,” tens un problema de crawl budget o de qualitat percebuda. Si els teus Core Web Vitals en dades de camp (CrUX) mostren més del 25% d’experiències “pobres” en LCP o INP, estàs perdent posicions davant competidors que sí les optimitzen. Si després d’una migració de CMS o un redisseny has notat una caiguda de trànsit superior al 10% que no s’ha recuperat en 4 setmanes, hi ha errors tècnics en la migració que no es van detectar.
Segons dades d’Ahrefs publicades el 2025, el 66% dels llocs web tenen almenys un problema tècnic que impedeix la indexació correcta de part del seu contingut. L’estudi va analitzar més de 100.000 dominis i va trobar que els problemes més freqüents són: pàgines amb temps de resposta superior a 1 segon (42%), cadenes de redireccions amb més de 2 salts (38%), i pàgines òrfenes sense cap enllaç intern apuntant-hi (27%).
Però més enllà dels números, l’auditoria compleix una funció que cap monitoratge automatitzat pot substituir: ofereix una fotografia completa de l’estat tècnic del lloc en un moment donat, amb les relacions entre problemes visualitzades. Un error de canonical aïllat és menor. Aquell mateix error de canonical multiplicat per 4.000 pàgines de producte i combinat amb un sitemap que inclou les URLs no canòniques i un enllaçat intern que apunta a la versió sense trailing slash és un problema arquitectònic que només es veu quan creues les dades de les cinc fases de l’auditoria.
La freqüència recomanada és trimestral per a llocs amb publicació activa i semestral per a llocs més estàtics. Després de qualsevol migració, l’auditoria s’ha de fer la primera setmana, no quan apareguin els símptomes.
Les eines mínimes que necessites per auditar el teu web
Abans d’entrar en les fases de l’auditoria, un punt crític: no necessites totes les eines del mercat. Necessites les eines justes per a cada fase, i saber exactament quina dada extreure de cadascuna. La paràlisi per excés d’eines és tan perjudicial com la manca d’elles.
L’stack mínim viable per a una auditoria tècnica completa consta de tres capes. La primera capa és gratuïta i cobreix el 60% del diagnòstic: Google Search Console proporciona les dades reals d’indexació, cobertura, rendiment en cerca i Core Web Vitals des del camp. No hi ha substitut per a aquestes dades perquè provenen directament de Google. PageSpeed Insights complementa amb una anàlisi de rendiment pàgina per pàgina, tant amb dades de laboratori (Lighthouse) com dades de camp (Chrome User Experience Report).
La segona capa és el crawler, i aquí l’eina estàndard de facto és Screaming Frog SEO Spider. La seva versió gratuïta permet rastrejar fins a 500 URLs i és suficient per a llocs petits. La versió de pagament (209 lliures/any) elimina aquesta limitació i afegeix funcionalitats crítiques com la integració amb Google Analytics, l’extracció personalitzada i la validació de dades estructurades. Alternatives com Sitebulb ofereixen informes més visuals però amb menys control granular.
La tercera capa és opcional però valuosa per a llocs complexos: una plataforma d’anàlisi que integri dades de rastreig amb dades de posicionament. Semrush Site Audit, Ahrefs Site Audit o Moz Pro ofereixen aquesta combinació. El seu avantatge no està en el rastreig en si (Screaming Frog és superior per a auditoria manual) sinó en el monitoratge continu i les alertes automàtiques entre auditories.
Un error freqüent és usar només eines de monitoratge continu i prescindir del crawler manual. Les plataformes all-in-one rastregen a una profunditat i freqüència limitades per disseny. Per a una auditoria tècnica real, el rastreig controlat amb Screaming Frog —configurant user-agent, velocitat, regles d’exclusió i extracció personalitzada— és insubstituïble.
Per a una comparativa detallada d’aquestes eines, consulta el nostre recurs sobre eines d’auditoria SEO.
Fase 1: Rastreig complet del lloc (crawling)
El rastreig és la base sobre la qual es construeix tota l’auditoria. Sense un crawl complet i ben configurat, qualsevol anàlisi posterior parteix de dades incompletes. La fase de rastreig no és simplement “prémer Start a Screaming Frog”; requereix una configuració prèvia que determina la qualitat dels resultats.
Abans d’iniciar el rastreig, cal configurar el user-agent com a Googlebot Desktop (per detectar possibles problemes de cloaking o contingut condicional), establir una velocitat de rastreig que no sobrecarregui el servidor (2-5 URLs per segon per a servidors compartits, 10-20 per a dedicats) i definir les regles d’exclusió per a URLs que no aporten valor a l’anàlisi (paràmetres UTM, URLs de staging, fitxers estàtics).
El rastreig ha de produir un inventari complet d’URLs amb el seu codi de resposta HTTP, títol i meta description, capçaleres HTTP rellevants (canonical, hreflang, X-Robots-Tag), profunditat de rastreig (clics des de la portada), mida de l’HTML i temps de resposta del servidor (TTFB). Aquestes dades en brut són el material amb el qual treballaràs en les fases posteriors.
El crawl revela directament errors 4xx i 5xx, redireccions (301, 302) i cadenes de redireccions, pàgines amb respostes lentes (TTFB superior a 500 ms), URLs duplicades amb contingut idèntic o quasi idèntic, i la profunditat real del lloc (quants clics separen les pàgines més profundes de la portada). Segons Moz, el 90% dels problemes de rastreig es detecten en aquesta primera fase si el crawl està correctament configurat.
Si tens accés als logs del servidor, creua les URLs rastrejades per Screaming Frog amb les URLs que Googlebot ha visitat realment en els últims 90 dies. Aquest creuament revela dos tipus de problemes: pàgines que Screaming Frog troba però Googlebot no visita (possibles problemes de priorització) i pàgines que Googlebot visita repetidament sense que apareguin a la navegació principal (possible trampa de crawl per URLs parametritzades).
El resultat d’aquesta fase ha de ser un fitxer estructurat (Excel o CSV) amb totes les URLs, els seus codis de resposta i les mètriques clau. Aquest fitxer és la base de dades de tota l’auditoria i es referenciarà a cada fase posterior.
Fase 2: Anàlisi d’indexació i cobertura
Un cop completat el rastreig, la segona fase creua les dades del crawl amb les dades de Google Search Console per entendre què veu Google realment del teu lloc. La diferència entre el que el teu crawler troba i el que Google té indexat és, amb freqüència, on s’amaguen els problemes més greus.
L’informe de Cobertura de Google Search Console (ara anomenat “Pàgines”) classifica les teves URLs en quatre estats: vàlides indexades, vàlides no indexades, amb errors i excloses. Cada estat té subtipus que indiquen la raó específica. Els més rellevants per a l’auditoria són “Discovered - currently not indexed” (Google coneix la URL però no l’ha rastrejada), “Crawled - currently not indexed” (Google l’ha rastrejada però ha decidit no indexar-la) i “Duplicate without user-selected canonical” (Google ha detectat duplicats i ha triat el seu propi canonical).
Compara el total d’URLs rastrejades per Screaming Frog amb el total d’URLs indexades segons GSC. Si hi ha una diferència superior al 20%, investiga les URLs que són al teu crawl però no a l’índex. Filtra per tipus: pàgines de producte, de categoria, posts de blog. El patró t’indicarà si el problema és de crawl budget, de qualitat de contingut o de senyals tècniques contradictòries.
Els problemes de canonicals es fan visibles en aquesta fase. Exporta de Screaming Frog totes les URLs amb el seu canonical declarat i compara: la URL canònica coincideix amb la URL real? Hi ha pàgines amb canonical autoreferencial apuntant a una URL amb paràmetres? Hi ha canonicals apuntant a pàgines que retornen 404? Cada una d’aquestes discrepàncies genera confusió per a Googlebot i dilueix l’autoritat de la pàgina correcta.
Descarrega el teu sitemap XML i compara les seves URLs amb les del crawl i les de l’índex de Google. Un sitemap ben mantingut només ha d’incloure URLs que retornen 200, tenen canonical autoreferencial i vols que Google indexi. Les discrepàncies més comunes: URLs al sitemap que retornen 301 (s’han d’actualitzar a la destinació final), URLs al sitemap amb canonical apuntant a una altra pàgina (senyal contradictòria), i URLs indexades que no apareixen al sitemap (possibles pàgines òrfenes que Google va trobar per altres mitjans).
El resultat d’aquesta fase és un diagnòstic clar del gap entre el lloc que tens i el lloc que Google coneix, amb les causes identificades per a cada discrepància.
Fase 3: Avaluació de Core Web Vitals i rendiment
La tercera fase se centra en com experimenta l’usuari (i Google) la velocitat i estabilitat del lloc. Els Core Web Vitals són senyals de rànquing confirmades des del 2021, i les dades mostren que el seu impacte va més enllà del posicionament: segons Web.dev, millorar el LCP de 4 segons a menys de 2,5 segons pot incrementar les conversions en un 15-25%.
Cal distinguir entre dades de camp i dades de laboratori — moltes auditories ignoren aquesta diferència. Les dades de camp (Chrome User Experience Report, accessibles via GSC i PageSpeed Insights) reflecteixen l’experiència real d’usuaris amb connexions i dispositius reals. Les dades de laboratori (Lighthouse) són simulacions en condicions controlades. Per a l’auditoria, les dades de camp són les que Google usa per al rànquing; les de laboratori serveixen per diagnosticar causes específiques.
Per al LCP, analitza les pàgines amb pitjor puntuació en dades de camp. Les causes més comunes d’un LCP lent: imatges hero sense optimitzar (format, mida, lazy loading incorrecte de l’element LCP), fonts web que bloquegen el renderitzat (manca de font-display: swap o preload), CSS i JavaScript que bloquegen el renderitzat, i temps de resposta del servidor lent (TTFB elevat per consultes a base de dades sense caché).
Per a l’INP, que va reemplaçar el FID el març de 2024, els problemes solen originar-se en JavaScript pesat que bloqueja el fil principal: event handlers amb lògica complexa, hydration de frameworks JavaScript al client, i scripts de tercers (analytics, chat widgets, publicitat) que competeixen pel fil principal.
Per al CLS, les causes més freqüents són: imatges i vídeos sense dimensions explícites (width/height a l’HTML), anuncis o bàners que s’insereixen dinàmicament desplaçant el contingut, fonts web que provoquen un reflow quan substitueixen la font del sistema, i contingut injectat per JavaScript per sobre del viewport.
No totes les pàgines mereixen el mateix nivell d’optimització. Prioritza les que tenen més trànsit orgànic, més conversions o major potencial de posicionament. Una pàgina de producte amb 10.000 visites mensuals i un LCP de 5 segons té més urgència que una pàgina de política de privacitat amb un LCP de 4 segons.
Fase 4: Arquitectura, enllaços interns i estructura d’URLs
La quarta fase avalua l’estructura del lloc com a sistema interconnectat. Mentre les fases anteriors analitzen pàgines individuals o grups de pàgines, aquesta fase se centra en les relacions entre elles: com flueix l’enllaçat intern, com es distribueix l’autoritat i si l’estructura d’URLs és consistent.
Usant les dades del crawl de la Fase 1, analitza la distribució de profunditat de les teves pàgines. La regla general és que cap pàgina estratègica hauria d’estar a més de 3 clics de la portada. A la pràctica, els e-commerces amb múltiples nivells de categories solen tenir productes a 5-6 clics de profunditat, cosa que redueix significativament la probabilitat que Googlebot els rastregi amb freqüència i que acumulin PageRank intern.
Identifica les pàgines que no reben cap enllaç intern. Aquestes pàgines òrfenes només poden ser descobertes per Google a través del sitemap o d’enllaços externs, cosa que les fa vulnerables a problemes d’indexació. Screaming Frog permet filtrar les pàgines amb zero inlinks interns. Creua aquesta llista amb el rendiment a GSC: si una pàgina òrfena té impressions o clics, Google la troba per altres mitjans però seria més efectiva amb enllaçat intern.
Analitza quines pàgines reben més enllaços interns i si aquesta distribució s’alinea amb les teves prioritats de negoci. És habitual trobar que les pàgines legals (avís legal, política de privacitat) reben més enllaços interns que les pàgines de servei o producte perquè apareixen al footer de tot el lloc. Això no és necessàriament un problema, però indica que les pàgines estratègiques necessiten enllaçat intern addicional des del contingut rellevant.
La consistència d’URLs, que John Mueller de Google va descriure com “el factor més gran de l’SEO tècnic”, requereix comprovar que la mateixa URL apareix de forma idèntica en quatre ubicacions: enllaços interns, canonical declarat, sitemap XML i dades estructurades. Les discrepàncies més freqüents: trailing slash inconsistent (amb i sense /), protocol inconsistent (http vs https en enllaços interns residuals), i paràmetres afegits pel CMS o eines d’analytics.
Finalment, avalua si les URLs segueixen una convenció consistent, són descriptives i no contenen paràmetres innecessaris. Les URLs òptimes per a SEO són curtes, contenen les paraules clau del contingut, usen guions com a separadors i mantenen una jerarquia lògica que reflecteix l’arquitectura del lloc.
Com generar l’informe final amb errors prioritzats
La fase final és on l’auditoria es converteix en un document accionable. Un informe que llista 300 errors sense priorització és inútil. Un informe que identifica els 15 problemes que més impacten al trànsit orgànic i els ordena per relació esforç/impacte és el que permet a un equip de desenvolupament actuar amb eficàcia.
Cada troballa de l’auditoria s’ha de classificar en dos eixos: impacte en SEO (alt, mitjà, baix) i esforç d’implementació (alt, mitjà, baix). Els problemes d’alt impacte i baix esforç s’implementen primer. Els d’alt impacte i alt esforç es planifiquen per al proper sprint de desenvolupament. Els de baix impacte, independentment de l’esforç, es documenten però no es prioritzen.
L’impacte no es mesura per la gravetat teòrica de l’error sinó pel seu efecte real en el trànsit i les conversions. Un error de canonical que afecta 4.000 pàgines de producte amb trànsit orgànic actiu té més impacte que 200 errors 404 en URLs que mai van rebre trànsit. Per determinar l’impacte, creua les troballes tècniques amb les dades de rendiment de GSC i Google Analytics.
Un informe d’auditoria efectiu té cinc seccions: el resum executiu (1 pàgina) amb les 3-5 troballes més crítiques i el seu impacte estimat en trànsit; el diagnòstic detallat organitzat per fases, amb captures i dades que recolzin cada troballa; la matriu de priorització amb tots els errors classificats; el pla d’acció amb tasques concretes, responsable i termini; i els KPIs de seguiment: les mètriques que es mesuraran 30, 60 i 90 dies després d’implementar les correccions.
Si l’informe va dirigit a direcció o màrqueting, les troballes tècniques s’han de traduir a impacte de negoci. “4.200 pàgines amb canonical incorrecte” no comunica urgència. “4.200 pàgines de producte que competeixen entre elles a Google, diluint el trànsit orgànic de la categoria que genera el 40% dels ingressos” sí que ho fa. Segons Moz, les auditories que tradueixen troballes a impacte de negoci tenen un 3x més probabilitat que les seves recomanacions s’implementin.
L’auditoria no acaba amb l’informe. Cal establir un calendari de verificació per confirmar que les correccions implementades han tingut l’efecte esperat. Després de les correccions de canonicals, verifica a GSC que les URLs duplicades es redueixen progressivament. Després de les millores de rendiment, comprova a CrUX que els Core Web Vitals milloren en dades de camp. Després dels canvis d’arquitectura, monitoritza la distribució de profunditat al proper crawl complet.
La diferència entre una auditoria que genera resultats i una que es queda en un PDF arxivat no està en la sofisticació de l’anàlisi. Està en la claredat del pla d’acció i en el seguiment disciplinat de la seva implementació. Una auditoria mediocre ben executada supera sempre una auditoria brillant que ningú implementa.