Què és el SEO tècnic i què inclou

Tenim tendència a estructurar aquestes tasques com una llista de comprovació. L'inconvenient és que una llista presenta quaranta punts com si pesessin igual, i a la pràctica dos d'ells decideixen el resultat i els trenta-vuit restants són soroll fins que aquests dos estan resolts. Aquest article s'organitza per ordre de diagnòstic.

Un cercador ha de poder fer tres coses amb una pàgina abans que el seu contingut entri en joc: arribar-hi, desar-la al seu índex i entendre de què tracta. El SEO tècnic s'ocupa que aquestes tres coses passin sense fricció.

La frontera amb les altres disciplines és útil encara que no sigui exacta. El SEO de continguts decideix què es diu i per a quina consulta. El SEO extern treballa el que altres llocs diuen del teu. El tècnic treballa sobre el vehicle: si el vehicle no arrenca, la destinació és igual.

Això explica la característica que més el distingeix. El treball de continguts produeix millores acumulatives i visibles. El tècnic produeix sobretot l'absència de problemes, que ningú no percep. Un lloc amb el SEO tècnic resolt no destaca per res en particular; un lloc amb una fallada tècnica seriosa pot perdre mesos de feina de contingut sense que ningú sàpiga per què

L'ordre importa perquè els problemes s'anul·len entre si. Optimitzar el rendiment d'una pàgina que està bloquejada per robots.txt no produeix cap efecte, i tanmateix apareix en qualsevol informe automàtic com una recomanació vàlida.

La seqüència que té sentit:

1. Els rastrejadors hi poden accedir? Bloquejos a robots.txt, restriccions del servidor, tallafocs que responen amb error als agents de cercador, zones protegides amb contrasenya.
2. Les pàgines estan indexades? Etiquetes noindex heretades d'un entorn de proves, canòniques que apunten a una altra URL, pàgines òrfenes sense cap enllaç entrant.
3. El contingut arriba a l'HTML? Si la resposta només apareix després d'executar codi al navegador, part del procés de rastreig es complica i altres sistemes directament no la veuen.
4. Les redireccions funcionen com a redireccions? Aquí és on apareixen les fallades més cares i menys visibles.
5. L'arquitectura és coherent? Estructura d'URL, jerarquia, enllaçat intern, duplicitats.
6. El rendiment acompanya? Mesurat amb dades d'usuaris reals, a més de les de laboratori.
7. Les entitats estan declarades? Dades estructurades, autoria, coherència entre versions d'idioma.

Els tres primers passos són binaris: es compleixen o no. Els quatre següents admeten graus. Qualsevol informe que comenci pel punt sis sense haver verificat els tres primers està optimitzant una cosa que potser no s'està mirant.

És el bloc on una fallada costa més i es detecta més tard, perquè el lloc continua funcionant amb normalitat per a les persones.

Accés

L'arxiu robots.txt governa què pot demanar cada agent. Convé revisar-lo sencer després de cada desplegament: un Disallow: / heretat d'un entorn de proves és l'error clàssic i poden passar setmanes sense que ningú no ho noti. Els tallafocs i els mòduls de seguretat del servidor són la segona font: bloquegen per comportament i poden estar responent amb error a rastrejadors legítims sense deixar rastre a l'aplicació.

Indexació

L'etiqueta noindex i la canònica fan coses diferents i sovint es confonen. La primera demana que la pàgina no entri a l'índex. La segona declara quina és la versió preferida quan hi ha diverses URL amb contingut equivalent. Una canònica que apunta a una altra pàgina equival a demanar que la pròpia no s'indexi, i és un error freqüent en llocs amb diversos idiomes o amb paràmetres de filtratge.

Redireccions

Una redirecció ha de ser una resposta del servidor amb codi 301 o 302. Quan en lloc d'això se serveix una pàgina que carrega i després redirigeix per instrucció del navegador (una etiqueta meta refresh o un salt per codi), el resultat per a la persona és idèntic: acaba a la destinació correcta. Per al cercador no ho és. Aquest tipus de salt transmet malament els senyals acumulats, o directament no els transmet, i les URL antigues poden quedar a l'índex competint amb les noves.

Un cas real: redireccions que el servidor retornava com a 200

En un projecte recent vam migrar un lloc de WordPress a Strapi com a gestor i Nuxt 4 a la capa visible. Es va aprofitar per redissenyar-lo d'acord amb la seva identitat i per refer l'arquitectura completa, que era el problema de fons, i es va eliminar el contingut que no estava alineat amb el negoci i només atreia consultes sense valor.

La nova arquitectura va produir més de 800 URL reescrites en dos idiomes, més les redireccions de les URL eliminades. El mapa es va plantejar amb cura i les redireccions es van declarar a Nuxt. El lloc s'allotja en un servidor que no és purament de renderització al servidor, així que es va optar per prerenderitzar les pàgines per guanyar velocitat, amb tres capes apilades: Apache, Nginx com a proxy invers i Nitro.

Aquí va aparèixer el problema. Quan l'URL d'origen d'una redirecció també és a la llista de rutes a prerenderitzar, Nitro també la prerenderitza i genera un arxiu HTML d'uns cent bytes, sense contingut, que Nginx serveix amb codi 200. Per a un cercador això és un soft 404 i la pèrdua completa del senyal de redirecció, no un 301.

El més difícil va ser detectar-ho, perquè totes les comprovacions habituals ho donaven per bo:

• La compilació surt en verd. Nitro tracta la resposta 3xx com un èxit: la ruta figura com a prerenderitzada al registre, sense cap avís.
• curl -I retorna 200 amb content-type: text/html. Res no indica error.
• Al navegador funciona. L'etiqueta meta http-equiv="refresh" porta a la destinació en zero segons. Comprovat a mà, el redirect sembla correcte.
• Els rastrejadors d'auditoria també el segueixen. Les eines del sector porten activada per defecte l'opció de seguir el meta refresh, així que informen d'un 200 i després de la destinació. No apareix a l'informe de redireccions ni al d'errors.
• Només es veu mirant el fitxer (uns cent bytes, sense <body>) o setmanes després a la consola de cerca, quan aquestes URL figuren com a pàgina amb redirecció absent i pugen els soft 404 i els duplicats sense canònica.

El dany és acumulatiu i silenciós: l'URL antiga continua indexada, no consolida autoritat cap a la nova i hi competeix.

La solució va ser moure totes les redireccions a Nginx, que és la capa per sobre de Nitro. Així la petició es resol abans d'arribar a l'aplicació, el redirect apunta directament a la destinació i desapareix el soft 404.

D'aquest cas en surten dos criteris generals, aplicables fora d'aquest stack concret. El primer és que les redireccions es resolen a la capa més alta possible del servidor, no a l'aplicació, perquè cada capa per sota les pot reinterpretar. El segon és que una comprovació manual i una eina d'auditoria poden coincidir en un fals positiu: si totes dues segueixen el mateix tipus de salt, totes dues informen del mateix i cap no detecta res.

La comprovació és senzilla i convé automatitzar-la: demanar cada URL antiga sense seguir la redirecció i verificar que el servidor retorna 301 amb la capçalera de destinació correcta. Un llistat de diversos centenars de redireccions s'audita en minuts amb un script i no s'audita mai a mà.

Aquí hi ha una confusió que convé desfer abans de res, perquè afecta com es llegeix qualsevol informe.

Hi ha dos mesuraments diferents del mateix fenomen. Un és de laboratori: una eina carrega la pàgina una vegada, en condicions simulades, i retorna una puntuació. L'altre és de camp: recull el que han experimentat usuaris reals durant els darrers vint-i-vuit dies.

El que un cercador utilitza com a senyal són les dades de camp. La puntuació de laboratori és una eina de diagnòstic, no pas el senyal.

Totes dues poden discrepar de manera cridanera. Un lloc pot retornar una puntuació de laboratori de 90 sobre 100 i tenir l'avaluació de camp suspesa, amb un temps de càrrega de l'element principal de tres segons. No és contradictori: la primera va mesurar una càrrega en condicions controlades i la segona va recollir milers de visites reals amb connexions i dispositius pitjors.

D'aquí en surten dues conseqüències pràctiques:

• Una captura de pantalla amb quatre cercles verds no demostra que el rendiment estigui resolt. Demostra que una càrrega concreta ha anat bé.
• Un lloc sense prou trànsit no té dades de camp, així que el seu rendiment real està sense mesurar per definició. És normal en projectes nous i convé dir-ho en lloc de presentar la puntuació de laboratori com si fos equivalent.

Sobre el pes d'aquest senyal en el posicionament convé ser sobri: s'ha descrit de manera consistent com a criteri de desempat entre continguts de qualitat comparable, no pas com a palanca de pujada. Un lloc lent amb el millor contingut de la seva SERP no baixa per això; dos llocs equivalents s'ordenen per això.

El que sí que és indiscutible és l'efecte sobre la conversió, que és un motiu suficient per si sol i no depèn de cap interpretació sobre algoritmes.

El marcatge declara de manera explícita el que el contingut diu de manera implícita: que això és un article, que el signa aquesta persona, que aquesta organització el publica, que aquest producte té aquest preu.

Té dues funcions que convé separar. La primera és habilitar resultats enriquits al cercador, que només existeixen per a certs tipus i amb requisits concrets. La segona, cada vegada més rellevant, és establir l'entitat sense ambigüitat per als sistemes que recuperen i citen contingut.

Els criteris que eviten les errades habituals:

• Marcar només el que és visible a la pàgina. Un bloc de preguntes freqüents declarat en el marcatge però absent del contingut incompleix les directrius.
• Referenciar per identificador en lloc de repetir l'objecte. L'organització es defineix una vegada al lloc i les altres pàgines la referencien. Repetir-la sencera a cada pàgina genera entitats que es poden contradir.
• Fer servir el tipus honest. Un article que parla d'un servei es marca com a article, i una pàgina de cas com a article o com a obra, segons el que sigui.
• No marcar ressenyes sobre un mateix. Un testimoni publicat al mateix lloc marcat com a valoració és autoreferencial i contravé les directrius.

Els rangs de preu es declaren com a preu mínim, no pas com a preu.

Un apunt sobre el volum: marcar més tipus no produeix un resultat millor. El que rendeix és un marcatge correcte i mínim, perquè un sol error invalida tot el bloc en què apareix.

L'arquitectura és la part del SEO tècnic més cara de corregir a posteriori, i per això la que més convé decidir abans de construir.

Estructura d'URL

Estable, llegible i amb una jerarquia que reflecteixi la del contingut. Qualsevol decisió aquí és reversible només a costa d'un pla de redireccions, així que el moment de prendre-la és el disseny del projecte.

Duplicacions

El mateix contingut accessible des de diverses adreces (amb i sense barra final, amb i sense www, amb paràmetres d'ordre o de filtre) reparteix senyals entre versions. Es resol amb canòniques coherents i amb una única forma servida pel servidor.

Enllaçat intern

És la part que més es descuida i la que més rendeix en llocs mitjans. Determina quines pàgines reben autoritat i com es descobreixen. Dues comprovacions que gairebé sempre retornen feina: pàgines sense cap enllaç entrant des del mateix lloc, i textos d'ancoratge que no diuen on porten.

Profunditat

Quants clics separen una pàgina de la portada. Una pàgina rellevant a cinc nivells de profunditat està mal col·locada, amb independència de la seva qualitat.

Una migració és l'únic moment en què un lloc pot perdre anys de feina en una tarda. Tant si és un canvi de domini, de tecnologia o d'arquitectura d'URL, el procediment és el mateix.

1. Inventari complet abans de tocar res. Totes les URL indexades, amb el seu trànsit, les seves posicions i els seus enllaços entrants. Sense aquesta foto prèvia no hi ha manera de saber després què s'ha perdut.
2. Mapa de correspondències un a un. Cada URL antiga al seu equivalent. Les que no tinguin equivalent exacte van a la pàgina més pròxima en intenció, mai a la portada de manera massiva.
3. Redireccions 301 servides pel servidor, verificades una a una abans del canvi.
4. Conservació dels senyals: títols, encapçalaments, dades estructurades i contingut de les pàgines que ja posicionaven. Una migració no és el moment de refer els textos.

Vigilància intensiva les primeres setmanes: cobertura d'indexació, errors de rastreig, evolució de posicions.

La caiguda temporal en les setmanes següents és esperable i se sol recuperar. El que no es recupera sol és una redirecció mal plantejada o un mapa incomplet.

L'excés de zel tècnic consumeix pressupost que rendeix més en un altre lloc.

1. Perseguir el 100 en una eina de laboratori. Els últims punts costen molt i no es tradueixen en dades de camp.
2. Corregir tots els avisos d'un rastrejador. Un informe d'auditoria retorna centenars de línies i bona part són informatives. Sense priorització, es treballa en allò fàcil d'arreglar en lloc d'allò que importa.
3. Marcar tipus de schema que no habiliten res ni aporten a l'entitat.
4. Optimitzar imatges quan el problema és el temps de resposta del servidor. El diagnòstic primer, l'optimització després.
5. Reescriure URL que ja funcionen per un criteri estètic. Tot canvi d'URL és una redirecció més i un risc afegit.

El criteri: una tasca tècnica es justifica quan resol un obstacle identificat, no quan apareix en una llista.