Indexar a Google el 2026: claus de la Search Central Live

Google ens va convidar a Search Central Live Deep Dive Europe 2026, el congrés que organitza per a professionals del SEO i que aquest any es va celebrar a Barcelona. El primer dia estava dedicat a com Google rastreja la web. El segon, a com l'interpreta i decideix què emmagatzemar a l'índex. Aquest article cobreix aquell segon dia, organitzat amb un fil conductor: entendre com processa Google el contingut del nostre lloc web per saber què fer per indexar-lo.

És el format més tècnic de Search Central Live: llargues sessions amb l'equip de Google Search i espai per fer preguntes. Per a una agència que treballa amb SEO i desenvolupament, és una oportunitat per escoltar de primera mà com funcionen els seus sistemes i contrastar-ho amb el que veiem cada dia en projectes de clients.

La indexació ja no és una formalitat. Google només guarda una petita part del que troba, i el context ha canviat: hi ha cada cop més llocs web i aplicacions construïts amb JavaScript, molts ja generats amb IA; la pàgina de resultats incorpora resums i mòduls que no fan que tot sigui un enllaç blau (ho tractem en SEO el 2026), i els assistents d'IA llegeixen el lloc web amb capacitats diferents de les de Google. Si la pàgina no arriba bé a l'índex, la resta del treball de SEO és inútil.

L'article segueix el viatge que fa una pàgina des de quan Google la troba fins que decideix si la desa. En cada pas, expliquem què fa Google, on els llocs web solen fallar i què s'hauria de comprovar. Aquests són els nostres apunts de classe, no la documentació oficial de Google: per a més detalls, la documentació de Search Central continua sent la referència. Si algun concepte no et sona, el nostre Diccionari SEO els llista.

El viatge des d'una pàgina fins a l'índex

Des que Google troba una URL fins que decideix desar-la, hi ha sis passos:

1. Google decideix quines URL visites i a quin ritme, i les descarrega.
2. Anàlisi d'HTML. Llegeix el codi, separa el contingut principal de la resta, mira el cap i extreu els enllaços i les etiquetes meta robot.
3. Si la pàgina depèn de JavaScript i CSS, passa per una segona cua on s'executa i sembla que un usuari la veuria.
4. Deduplicació. Agrupa pàgines amb el mateix contingut o molt similar i tria la més representativa.
5. Extracció de característiques i senyals. Dades estructurades, imatges, vídeo, idioma, país, frescor i qualitat.
6. Selecció per a la taula de continguts. Amb tot l'anterior, decideix si la pàgina entra.

Un problema en un pas condiciona el següent. Una pàgina que Google no pot renderitzar no arribarà ben interpretada en la deduplicació, ni en senyals, ni en l'índex. Per això el més útil és saber en quin pas es perd cada pàgina.

Seguiment: Accés i pressupost

Google no rastreja tota la web ni sempre al mateix ritme. El que visites depèn del que trobi i de com respongui el servidor, i aquest és el pressupost de rastreig. El primer dia del congrés vam parlar més d'això, i les respostes del servidor són les que més l'afecten:

Respuesta	Qué pasa	Qué hacer
5xx (500, 502, 503) i 429	Googlebot alenteix el ritme. Si persisteixen, pot deixar d'indexar les URL	En manteniment temporal, serveix el 503
Temps de resposta lents o temps d'espera	Com més temps triga el servidor, menys URLs rastreja	Millorar el rendiment
5xx a la robots.txt	Google pot deixar de rastrejar tota la web fins que es recuperi	Disponibilitat de fitxers de monitoratge
3xx	Cada salt és una petició extra. Les cadenes són especialment dolentes	Enllaç a l'URL final
Soft 404 (200 amb contingut "no trobat")	Google continua seguint-los	Retorna un 404 o 410 real
404 / 410	No deixen de rastrejar-se, però Google els torna a revisar. El 410 s'elimina una mica més ràpid	Fes servir el 410 si no tornen
200 amb contingut duplicat o pobre (paràmetres, filtres, paginacions infinites)	Consumeix pressupost sense afegir valor	Controla'l amb robots.txt, canònic i enllaçat
304 No Modificat (amb ETag o Últimament Modificat)	Google no ha de tornar a descarregar la pàgina	Implementa aquestes capçaleres

Per veure aquestes respostes en la pràctica, tenim la guia de Google Search Console i una publicació sobre com corregir errors 5xx i 4xx.

Altres decisions que es van aclarir:

• Mapes de lloc HTML. No cal fer-los, i si estan mal implementats poden ser perjudicials.
• Sitemap a la robots.txt. És preferible, però està obert a tothom, fins i tot a aquells que no hi estan interessats. Si només volem que Google el trobi, només cal enviar-lo des de la Consola de Cerca.
• El robots.txt no és un sistema de desindexació. Si bloquegem una URL per robots, Google encara la pot indexar, però sense contingut. Per eliminar una pàgina de la cerca necessites noindex, i perquè Google la llegeixi l'URL ha de ser rastrejable. Ho expliquem a la publicació com desindexar una URL de Google.
• Productes esgotats. Depèn del cas. Si el producte és important, exclusiu, difícil de trobar i l'usuari pot esperar, el més segur és mantenir els 200 amb la precomanda o una acció que no generi frustració. Si torna aviat, 200 amb l'estoc indicat a les dades estructurades; no hi ha 404 ni redirecció.

HTML: què llegeix Google i en quin ordre

Quan Google arriba a una pàgina, analitza l'HTML seguint els elements del DOM. Primer, separa el que considera el contingut principal de la resta. Després llegeix el capçal (canònic, hreflang, títol), extreu els enllaços i consulta les etiquetes meta robot.

Els enllaços

Els enllaços són la manera que té Google de descobrir noves pàgines, i han de ser . Qualsevol altra solució és un risc.

En webs fetes amb frameworks JavaScript, és una de les primeres coses a tenir en compte: si el menú o els productes s'obren amb un onclick o un routerLink, Google no els veu com a enllaços.

Metaetiquetes robots

Al cap, pots indicar regles per a tots els robots o per a un específic. Les que has de saber:

Directiva	Què fa
noindex	No indexa la pàgina
nofollow	No segueix enllaços. A nivell de pàgina té poc sentit; s'aplica més enllaç per enllaç
none	És igual a noindex més nofollow
nosnippet	Indexa la pàgina, però sense fragments ni resums a AI Overviews
data-nosnippet	Atribut HTML (no meta etiqueta) que només exclou una part del contingut dels resultats
max-snippet	Limita la longitud del fragment, normalment amb un nombre de caràcters; -1 és il·limitat
max-image-preview	Configura la mida de la imatge: cap, estàndard o gran. Gran  pot ajudar-te a obtenir visibilitat a Discover
max-video-preview	Estableix la durada màxima de previsualització
notranslate	Evita la traducció als resultats i a Chrome. Ús inusual
noimageindex	Indexa el contingut, però no les imatges. Cas poc habitual

Les directrius de limitació són una decisió empresarial: si donem la resposta completa a la pàgina de resultats, l'usuari no té motiu per clicar. Tot i així, per a la majoria de llocs web l'objectiu és la màxima visibilitat, i la combinació recomanada per la presentació és aquesta:

max-image-preview:large, max-snippet:-1

Dues aclariments més. La robots.txt regles: si bloqueja l'accés a recursos que després volem millorar amb etiquetes meta de robots, són inútils. I les etiquetes meta de robot es poden incloure amb JavaScript, però és inestable, especialment davant dels canvis. Millor evitar-ho.

JavaScript, el camí llarg

Google ha millorat molt la rastreig i indexació del contingut en JavaScript, però encara no és perfecte. El que vol és entendre què veu una persona per saber si la pàgina respon, i no sempre ho aconsegueix. La primera vegada, gairebé mai.

Una pàgina amb JS passa per dues cues: la cua HTML i després la cua de renderització. El camí és una mica més llarg, però si el contingut està ben servit, Google acaba recollint-lo. El que has de deixar clar és que CSS i JS canvien l'aspecte de la pàgina, i el resultat pot ser molt diferent de l'HTML pur. Si Google no sap renderitzar bé, la majoria d'enllaços i menús no els detecten.

Tant si el teu lloc web està creat amb React, Vue o Next.js, la nostra guia de SEO basat en JavaScript entra  en més detall.

Què cal vigilar

• Envia atributs bàsics de SEO com el títol i la meta descripció de JS. A la presentació, es va mostrar un cas real on eren diferents tant en l'HTML en brut com en el renderitzat.
• Actualitza la informació amb JS (dades, preus), que pot alterar el que Google indexa.
• Injecta text des dels camps de la base de dades.
• Renderitzant temps morts.
• Violacions de Política de Seguretat de Contingut (CSP).
• Recursos bloquejats per JS o per robots.txt.
• Un excés de JS extern que no controlem i que difícilment podrem oferir en HTML.

Cas mostrat a la presentació: el títol i la meta descripció de l'HTML en brut no coincideixen amb els del renderitzat.

Els errors més visibles

1. Contingut que no està en l'HTML renderitzat. Si no està al DOM final, Google no ho veu. Passa quan el JS no és accessible per a Googlebot o quan les APIs que cal carregar estan bloquejades o no responen. És comú en desplaçaments infinits, on Google només detecta la primera part.
2. Fragments (#) a l'URL quan el contingut canvia. Google no els processa. La solució és l'API d'Historial, amb URLs amb path o paràmetre: /path/products i /?path=productes funcionen, /#path=productes
3. Soft 404. L'aplicació mostra un "no trobat" però respon 200, o la pàgina arriba trencada. Abans eren pàgines buides o pobres; ara sovint són errors reals que es serveixen amb un 200 via JS. Has de revisar les respostes del servidor de les pàgines que Google rastreja i ajustar-les a la realitat.
4. Recursos bloquejats. Encara hi ha molts robots.txt que bloquegen els punts finals JS o API que la pàgina necessita per renderitzar.

Com depurar-lo

Mètode per trobar la sol·licitud darrere del contingut que falta.

1. 1. A Chrome, obre la pestanya de Xarxa, filtra per Fetch/XHR i torna a carregar la pàgina.
   2. Localitza la trucada que subministra el contingut perdut: S'ha executat? Ha retornat dades? Ha estat bloquejada?
   3. Si encara falta, cerca el text a tots els scripts carregats amb Cmd/Ctrl + Shift + F.
   4. A la Consola de Cerca, fes una inspecció d'URL, prova la URL publicada i mira la pàgina provada. Mira la captura de pantalla, els missatges HTML renderitzats i JavaScript de la consola. El Rich Results Test funciona igual de bé.
   5. Compara el codi font amb el DOM i revisa els recursos bloquejats.

Un detall a recordar: el servidor pot respondre 200 i el contingut JS està trencat, i després Google el tracta com un soft 404. Ho vam provar durant la sessió amb una pàgina al nostre web: l'URL estava disponible per a Google i només mostrava dues advertències a la consola per recursos preinstal·lats que no s'havien utilitzat.

JavaScript, IA i renderització al costat del servidor

Els sistemes de Google recullen contingut en JavaScript força bé, però altres assistents d'IA encara no ho fan. Per això és més segur servir-lo amb SSR, és a dir, renderitzat al servidor. També val la pena preguntar-se si els bots d'IA poden accedir a tot el contingut de la web, si vols.

El CMS sense cap és net i segur, però el resultat sovint no és gaire llegible per Google, fins i tot si l'usuari el percep bé. Això es pot compensar parcialment amb un bon marcatge de dades estructurades.

Per a les aplicacions generades per IA que després s'han de lliurar per ser indexades, la presentació presentava un replantejament amb fragments web, que serveixen com a fragments aïllats dins la pàgina. Encara és difícil trobar estàndards i encara queda molt camí per recórrer, així que és recomanable seguir-lo des de la distància. També va sortir WebMCP, que està guanyant importància en l'era de la gestió.

Com Google entén una pàgina

Google separa tres àrees quan arriba a una pàgina: capçalera, navegació i contingut principal. I dóna cada cop més pes a la tercera. Per això, moltes vegades, el títol i la descripció que mostra als resultats no són els que li hem donat a l'encapçalament.

La conseqüència és pràctica: tot el que és important ha d'anar al contingut principal, però amb criteris, sense carregar-lo de tot. A la presentació ho van il·lustrar amb una entrada d'un blog personal: el títol i el text del cos es consideren importants, mentre que les categories o el peu de pàgina pesen menys.

Contingut principal enfront de contingut secundari, amb un post del blog de John Mueller com a exemple.

El que Google guarda a l'índex tampoc és la pàgina com a text. Tokenitza el contingut: separa cada paraula, registra la seva posició i l'àrea de la pàgina on es troba (capçalera, centre de foc), i assigna cada paraula a les URL on apareix. Així és com intenta entendre de què tracta el contingut i en quin format està. Té problemes greus amb llengües que no separen les paraules amb espais.

Com es separen les paraules quan es desa una pàgina a la taula de continguts, i per què les llengües sense espais ho compliquen.

Aquest no és el fragment que fan els models d'IA. Google busca context i no necessita que el contingut es talli en fragments: no té sentit optimitzar-lo en blocs pensant en Google. Per a altres models d'IA sí que pot, de moment.

La tokenització que fan els models d'IA, que no és el que Google emmagatzema al seu índex.

Duplicats i canònics

Google creu que l'usuari no vol veure les mateixes pàgines, i la desduplicació també estalvia temps de rastreig per llegir noves pàgines. El procés té tres passos:

1. Entén els clústers de contingut, els relaciona i els diferencia dins del clúster.
2. Agrupa les pàgines, tria la més representativa i indexa-la.
3. Comprova senyals addicionals (enllaços, etc.) per obtenir més context.

Si les pàgines són iguals, es canonitza. Si són en idiomes diferents, consulta el hreflang i el respecta. També estalvia les marques: en un rebranding, intenta relacionar la marca antiga amb la nova, de manera que qui busqui l'antiga vegi la nova. I el mateix criteri s'aplica a les migracions de contingut.

On normalment apareixen duplicats

• Redireccions mal fetes. Han d'anar a contingut equivalent. Si no ho és, el SEO acumulat no es transfereix.
• El mateix lloc web servit amb i sense www, o amb http i https. Sembla increïble, però encara es troba sovint.
• Estructura d'URL poc clara. A la presentació ho van il·lustrar amb /buy/fax, /buy/typewriter i /office-equipment/ com a possibles duplicats, i amb /barcelona/services, /madrid/services i /valencia/services com a pàgines gairebé idèntiques. Si només canvia el nom de la ciutat, t'has de preguntar si val la pena fer un seguiment de tots.
• El mateix contingut per a diferents països, o redireccions automàtiques de geolocalització. Aquí has d'utilitzar hreflang.
• Bloquejadors de bots. Alguns també afecten l'rastreig de Google

Canonicals: bones pràctiques

Sempre has de posar el relel canònic, tot i que Google el comprova i no sempre segueix el que li diem. Les discrepàncies es comproven a la Consola de Cerca. Concretament:

• Agrupa les URL canonitzades per entendre els casos (paginació, paràmetres, idioma).
• Evita cadenes de canòniques i canòniques que apuntin a una URL que no respongui 200.
• Comprova que el canònic de l'HTML coincideixi amb el que es serveix després amb JavaScript. Quan no coincideixen, Google pot complicar-se, i és un fenomen nou.
• Fes sempre l'enllaç intern a l'URL canònica. Si enllaçem URLs no canòniques, Google acaba arribant a la bona, però perdem temps i pressupost.
• En la paginació i el filtratge, canonitzar-ho tot a la primera pàgina normalment no té sentit.

Quan el canònic que Google tria no és nostre, la causa sol ser una d'aquestes:

1. Un intent de segrestar: dominis duplicats, entorns d'escenaris oberts que no haurien d'existir, o robatori de contingut.
2. Problemes greus a la pàgina: velocitat de càrrega, seguretat, HTTPS.
3. Senyals incorrectes a la capçalera, mapa del lloc o robots.txt.

El primer que cal fer és comprovar que la pàgina que volem sigui indexable i que l'HTML i el renderitzat siguin correctes. Si res d'això ho explica, podem provar de redirigir l'URL indexada a la bona.

Amb hreflang hi ha una matisació: en pàgines amb el mateix idioma de molts països, Google acaba indexant una o poques URLs, per molt que les marquem totes. És recomanable decidir quina és l'URL principal i treballar perquè sigui la que triï Google.

La presentació va acabar amb set recomanacions: utilitzar redireccions en migracions, utilitzar codis de resposta HTTP i no bloquejar agents, revisar rels canònics, utilitzar hreflang per ajudar a localitzar, informar de canons estranys en fòrums, crear pàgines segures que funcionin i mantenir clars els senyals canònics.

Dades estructurades, imatges i vídeo

Quan Google ja té l'HTML, fa una extracció de funcionalitats: agafa l'HTML general, desa les imatges i vídeos per separat i extreu les dades estructurades. La pàgina de resultats actual està plena de mòduls que no són els deu enllaços blaus, i gairebé tots surten d'aquí.

Dades estructurades

És més fàcil, i més barat, per a Google llegir dades estructurades que no pas interpretar contingut visible, com fa la IA. A més, et permeten donar informació que no està a la pàgina i ajuden els bots a centrar-se en contingut rellevant. Fan que la pàgina sigui elegible per a resultats rics, per a funcions del lloc i de la pàgina (nom del lloc, enmigles de fons) i per a la visibilitat a Discover. Diversos estudis suggereixen que una bona implementació pot augmentar el trànsit orgànic.

Com utilitzar-los:

• Segueix schema.org estàndards.
• Format recomanat: JSON-LD. Hi ha altres opcions, però és més fàcil d'operar i dóna menys errors.
• Un excés no penalitza, però és recomanable no afegir elements secundaris i centrar-se en allò que és important.
• Google no utilitza tots per mostrar resultats. La galeria de cerca indica quins.
• Valida amb el Test de Resultats Rics.

Per al comerç electrònic hi ha noves funcionalitats: ara pots enviar el programa de fidelització, la política d'enviament i la categoria del producte.

Imatges

Les imatges són cada cop més presents a la cerca, el descobriment i altres superfícies. Google les extreu de l'HTML amb els elements i . Les que només es refereixen com  a imatges de fons CSS no estan indexades de manera fiable. Millor ; també les detecta, però és millor evitar-ho.

Dins de la imatge, Google utilitza:

1. SRC: Ha d'estar disponible i no bloquejat.
2. ALT: Has de descriure la imatge a algú que no la vegi, sense omplir-la amb paraules clau. Més detalls a la guia de text ALT.
3. Títol: pot proporcionar un context complementari a l'ALT.

La resta d'atributs s'ignoren. Sí que llegeix les paraules que envolten la imatge per obtenir context. Com a bona pràctica, és recomanable incloure-les als mapes del lloc, oferir diversos formats i mides, utilitzar AVIF i WebP sempre que sigui possible i buscar l'equilibri entre qualitat i compressió. Tenim més detalls a la publicació sobre SEO per a imatges.

Vídeo

Vídeo

El pes del vídeo depèn de la intenció de cerca. Apareix a Cerca, YouTube i Discover, ara amb previsualitzacions i moments clau. El marcatge de vídeo en HTML és molt important. Les millors pràctiques inclouen:

• Una URL per a cada vídeo.
• Títols i descripcions elaborats i miniatures atractives.
• Dades estructurades i vídeos en mapes del lloc.
• Format mp4 preferit.
• El vídeo, dins del contingut principal i a la part superior de la pàgina, amb el text que l'envolta, funcionava.
• Vigila el temps de càrrega de la pàgina.
• Plataformes com YouTube o Vimeo, que ja les distribueixen i les mouen a través d'altres canals com les xarxes socials, perquè generen senyals. Per a YouTube, tenim una publicació SEO a YouTube.

Les imatges i vídeos tenen els seus propis robots a Google, així que es poden bloquejar per separat amb el robots.txt o gestionar-los amb etiquetes meta de robots. Per a Discover, max-image-preview:large. I per al contingut generat per IA, la recomanació és revisar-lo abans de publicar-lo.

Idioma i mercat: SEO internacional

Google identifica l'idioma pel contingut de la pàgina, no per l'URL o el hreflang. Per això hauries d'evitar més d'un idioma a la mateixa URL. Per saber quin país apunta un lloc web, mira diversos factors:

1. Domini geogràfic de nivell superior (.es, .sg...). Aquest és el senyal més potent. Tenir el teu propi domini per país és el millor, però no sempre és viable; si no el tens, has de reforçar la resta.
2. Hreflang, en etiquetes, capçaleres o mapes del lloc.
3. Ubicació del servidor (adreça IP).
4. Altres signes: idioma, moneda, enllaços i perfil empresarial.

Google no varia la ubicació del rastrejador per detectar diferents versions de la mateixa pàgina, i ignora les metaetiquetes de localització geo.region.

El SEO multilingüe està guanyant importància en el context de la IA. Es pot traduir amb IA, però cal comprovar la qualitat de la traducció. I sovint traduir no és suficient: hi ha qüestions legals, contextuals i culturals. La moneda, les ofertes i promocions, les opinions i ressenyes, la reputació de la marca o la durabilitat del producte pesen de manera diferent segons el país. La presentació ho il·lustrava amb dades de Think with Google sobre què valoren els compradors als Estats Units i Europa, i amb les diferències entre països com Alemanya i França. Traduir amb IA pot quedar curt en aquests factors i dependrà dels recursos i riscos de cada projecte.

El SEO internacional  no es resol amb traduccions, ni tan sols amb un bon hreflang:

• El mateix catàleg, amb els mateixos preus i fotos, pot vendre molt en un país i res en un altre.
• Si hi ha diversos països amb la mateixa llengua i dialectes, s'ha d'adaptar: espanyol, anglès o francès en països diferents.
• Hem de valorar l'autoritat que tenim a cada país. Ens coneixen? Hem guanyat premis? Tenim botigues físiques? Fem promocions? Un bon hreflang no ho compensa.
• De vegades, les fotos, preus o promocions hauran de canviar per adaptar-se al mercat.

Per aprofundir, recomanem l'article d'Alizée Baudez sobre SEO internacional.

Sobre com estructurar el lloc web per mercats, tenim una entrada dedicada al SEO internacional: domini, subdomini o carpeta.

Senyals i selecció d'índex: què entra i què no

Google només indexa una part molt petita de les pàgines que troba. Intenta conservar les que donen més satisfacció als usuaris, i la selecció es fa al final, quan ja ha analitzat el contingut i els senyals. Per decidir això, cal saber si el contingut és fiable i rellevant.

L'essència no ha canviat: útil, original, ben estructurat, contingut ben escrit, amb bona metadada i esquema. El PageRank encara existeix, però s'ha refinat. Els signes que van destacar són quatre:

• País i llengua. Detecta la llengua i el país o regió objectiu. La indexació pot variar segons el domini, la presència o perquè hi ha menys recursos per a llengües minoritàries. És normal que un lloc web en espanyol i català indexi millor en espanyol.
• Sempre es té en compte, i encara més en cerques que requereixen resultats recents. Una pàgina es pot indexar però sense visibilitat, i a llarg termini es pot desindexar.
• Cerca segura. Sigues molt curós amb el contingut explícit.
• Google troba pàgines de correu brossa en massa i ho pren com a prioritat, especialment amb IA: contingut artificial, massiu, perillós o suplantacions. Tot i així, li costa detectar-ho.

També hi ha senyals negatius que prenen una pàgina de la cursa: noindex, contingut caducat (unavailable_after), soft 404, duplicats i senyals de correu brossa. Els senyals dels usuaris també compten.

Estat de la Consola de Cerca

Dos estats de l'informe d'indexació de pàgines tenen una lectura clara:

• Descobert, actualment no està indexat. Google sap que l'URL existeix però no l'ha rastrejat gens. Està a la cua, i s'ha gastat el pressupost de rastreig.
• Rastrejat, actualment no indexat. Google ja l'ha analitzat i no el considera elegible. Tornar-lo a enviar és inútil si no hi ha un canvi substancial. Normalment és contingut pobre, duplicat o desactualitzat.

Què passa a l'índex

Google tokenitza el contingut i etiqueta cada token amb l'àrea de la pàgina on es troba (per exemple, capçalera o element central). Després construeix una llista de publicacions: cada paraula s'associa amb les URLs on apareix, etiquetades per format. D'aquesta manera intenta entendre de què tracta el contingut i en quin format es troba.

Respostes ràpides a casos comuns

Situació	Recomanació
Elimina ràpidament les pàgines de la cerca	Sol·licitud d'eliminació a la Consola de Cerca
Paràmetres que no volem que es rastregin (variants, filtres de cerca)	Bloqueja'ls amb robots.txt. Els canònics ajuden bé a indexar, però no controlen el rastreig
Google reescriu títols i no ens agrada	Escriu-ne de millors. Normalment agafa el títol meta o H1; si són bons, no en prendran altres (o sí)
Producte esgotat que tornarà aviat	200 amb esquema esgotat d'estoc, sense 404 ni redireccionament. Indica a la pàgina que ara no ho és i, si és possible, ofereix la precomanda
Canonical autorreferencial	Sí, per si de cas
Disavow tool	No cal
Lloc web desindexat per error que volem recuperar ràpidament	Envia les teves URL principals a través de la Consola de Cerca

Si vols entendre per què Google reescriu els títols, el nostre article sobre com Google tria els títols de les pàgines ho detalla.

El contingut continua sent el rei, segons l'article, i té sentit: tot el sistema descrit fins ara existeix per decidir quin contingut val la pena guardar.

Per decidir quin contingut val la pena crear, una bona font és Google Trends, que també es va presentar a la presentació. Té dades des del 2004 fins fa pocs minuts, combina cerca de text, imatges i compres, i serveix tant tendències a llarg termini com temes actuals. És una bona eina per a estudis de màrqueting, per prendre decisions SEO o SEM i per presentar dades al client. No inclou Discover, perquè l'usuari no hi cerca.

Per on començar

Tot l'anterior es pot convertir en una revisió ordenada. Aquest és l'ordre que proposem, des de més ràpid i amb més impacte fins a més feina.

Revisions ràpides

1. txt. Que no bloquegi JS, CSS ni APIs necessàries per renderitzar, i que el mapa del site s'enviï a la Consola de Cerca.
2. Consola de cerca. Mira els soft 404s i els estats "Descobert" i "Rastrejat, actualment no indexat". No reenviïs URLs sense canvis. Aquesta ressenya forma part de qualsevol auditoria
3. Enllaços de navegació. Deixa'ls tots , també als menús i filtres.
4. Canònics. Autoreferencials, sense cadenes, cap a URLs que responen a 200, i amb enllaços interns sempre a la versió canònica. Comprova www i sense www, http i https.
5. Etiquetes meta de robots. PREVISUALITZACIÓ MÀXIMA: GRAN I FRAGMENT MÀXIM:-1, excepte quan hi ha motiu per limitar-ho.

Revisions amb més feina

1. Compara l'HTML en brut i el DOM renderitzat. El títol, la meta descripció, el canònic i els enllaços han d'estar en l'HTML inicial. En webs amb molta càrrega de JS, valora SSR. Per als equips de desenvolupament, tenim algunes directrius essencials de SEO.
2. Dades estructurades. JSON-LD validat amb el Rich Results Test, centrat en el que és important.
3. Imatges i vídeo. amb formats descriptius alt, WebP o AVIF, mapes de lloc i una URL i marcatge per a cada vídeo.
4. Landings de ciutat amb el mateix contingut, versions per país i hreflang.

En nous projectes

1. Migracions. Redireccions un a un a contingut equivalent. Més detalls sobre migració web i SEO.
2. Pàgines web multipaís. Adapta preus, moneda, promocions i ressenyes, i avalua l'autoritat local de cada mercat.
3. Aplicacions generades per IA. Pensa en com es lliurarà el contingut per disseny perquè Google l'indexi.

Documentación de Google

Les fonts oficials de cada tema, per contrastar el que hem explicat. Tota la documentació està en anglès.

• Rastreig: gestió del pressupost de rastreig en grans webs i introducció a la robots.txt.
• Metaetiquetas robots: robots meta tag, data-nosnippet y X-Robots-Tag.
• Bàsics de SEO per a JavaScript i com depurar problemes de JavaScript a la cerca.
• Canònics i duplicats: què és la canonització i consolidació d'URL duplicades amb canòniques.
• Dades estructurades: introducció, galeria de cerca i prova de resultats rics.
• Imatges i vídeo: bones pràctiques per a les imatges i bones pràctiques per al vídeo.
• SEO internacional: versions localitzades i hreflang.
• Consola de cerca: Eina d'indexació de pàgines, informes i inspecció d'URL.
• Tendències de cerca: Google Trends.

I dues referències tècniques esmentades a la presentació: l' API d'Història (MDN) per a URLs en aplicacions d'una sola pàgina i Web Fragments per a la distribució d'aplicacions generades per IA.

Cómo lo trabajamos en La Teva Web

La indexació és un tema en què s'han de parlar de SEO i desenvolupament. Moltes de les decisions que determinen si Google veu bé un lloc web (com es representa, com es generen enllaços, a què respon el servidor) són desenvolupament i es prenen abans que ningú pensi en SEO. A La Teva Web treballem amb el nostre propi equip, sense subcontractar, i això ens permet revisar aquests punts amb la persona que construeix el lloc web.

Si vols saber en quin pas del viatge es perden les pàgines del teu lloc web, escriu-nos i farem una revisió d'indexabilitat. Pots veure com treballem en SEO a la nostra agència de SEO a Barcelona i revisar els conceptes bàsics a la Guia de SEO.