Observabilitat SEO tècnica per a releases CI/CD | Ighenatt

Les regressions SEO més silencioses acostumen a sortir en desplegaments que han anat bé. El build passa. L’aplicació carrega. El tracking d’ingressos sembla normal. I dues setmanes més tard Search Console comença a mostrar URLs excloses, canònics equivocats o un grup de pàgines descobertes però no indexades.

En aquell moment, el commit ja no és fresc al cap de ningú.

L’observabilitat SEO tècnica és la pràctica d’acostar aquests errors al moment en què s’introdueixen. En lloc d’esperar que Googlebot, els logs o una auditoria manual revelin el problema, el pipeline CI/CD comprova si la release continua preservant rastrejabilitat, indexabilitat i consistència de senyals.

Això no va de prometre rànquings. Un pipeline SEO en verd no fa que una pàgina mereixi la primera posició. Només respon una pregunta més estreta i més útil: aquesta release ha preservat les condicions tècniques que permeten als sistemes de cerca avaluar correctament la pàgina?

Per a responsables de SEO tècnic que treballen amb equips d’enginyeria, sobretot en llocs multilingües de Barcelona, Catalunya o mercats europeus més amplis, aquesta pregunta més estreta és on hi ha la palanca.

Per què les regressions SEO han d’entrar al pipeline de release

La majoria d’equips ja prova si un desplegament trenca JavaScript, TypeScript, bases d’accessibilitat o comportament a nivell d’unitat. El comportament crític per al SEO sovint queda fora d’aquest bucle, encara que sigui igual de comprovable.

Els codis d’estat HTTP en són un bon exemple. MDN agrupa les respostes en cinc classes: informatives 1xx, correctes 2xx, redireccions 3xx, errors de client 4xx i errors de servidor 5xx. La documentació de rastrejadors de Google explica després com aquestes classes afecten el rastreig i la indexació. Una resposta 2xx es pot processar per a indexació, però Google assenyala explícitament que un estat correcte no garanteix la indexació. Les respostes 4xx no s’indexen i les URLs indexades prèviament es poden eliminar amb el temps. Els errors 5xx i 429 poden fer que els rastrejadors de Google alenteixin temporalment el rastreig.

Això es pot provar en una release.

Si una plantilla de producte que històricament retornava 200 comença a retornar 404, el pipeline ho pot detectar. Si una migració converteix redireccions permanents en redireccions temporals, el pipeline ho pot detectar. Si una ruta localitzada comença a retornar 500 només en català, el pipeline ho pot detectar abans que Googlebot.

La part incòmoda: moltes auditories SEO encara tracten aquests problemes com a neteja periòdica. Els rastrejos trimestrals són útils, però arriben tard. Els checks de CI converteixen el mateix coneixement en un contracte de release.

Una auditoria tècnica continua sent necessària per al diagnòstic ampli; consulta la guia d’auditories SEO tècniques per a la metodologia completa. L’observabilitat CI/CD gestiona el problema més petit però més afilat: evitar que classes conegudes de regressions es despleguin repetidament.

El contracte SEO mínim de release

Un contracte de release és una llista de condicions SEO que han de continuar sent certes després de cada desplegament. Ha de ser prou curt perquè enginyeria el pugui mantenir i prou específic perquè els responsables SEO hi puguin confiar.

Per a la majoria de llocs, la primera versió hauria de cobrir cinc àrees.

1. Les URLs representatives han de retornar els codis d’estat HTTP esperats.
2. Les redireccions han d’usar la permanència prevista.
3. Les etiquetes canòniques han d’apuntar a la URL absoluta esperada.
4. Les directives robots no han de bloquejar la indexació de manera inesperada.
5. Les anotacions hreflang han de continuar sent recíproques i completament qualificades.

Això és deliberadament menys ambiciós que un rastreig complet. L’objectiu és provar les plantilles i famílies de rutes amb més probabilitat d’afectar la visibilitat orgànica: pàgina inicial, pàgines de servei, articles de blog, pàgines de categoria, versions localitzades, vistes paginades i qualsevol patró d’URL programàtic d’alt valor.

Per a una agència SEO de Barcelona que publica contingut en castellà, anglès i català, el conjunt de proves hauria d’incloure almenys una URL per idioma i plantilla. Si /en/blog/robots-txt-configuration-errors-seo/ passa però l’equivalent català falla perquè ha canviat el generador de rutes localitzades, una mostra d’un sol idioma ha donat una falsa tranquil·litat.

El contracte de release també ha de classificar les fallades per severitat.

Un canònic trencat en una pàgina d’esborrany pot ser un avís. Una capçalera noindex a la plantilla principal de serveis hauria de bloquejar el desplegament. Una etiqueta hreflang de retorn absent en un article amb poc trànsit es pot posar a la cua de reparació; etiquetes de retorn absents a totes les pàgines en anglès haurien d’aturar la release.

El pipeline no s’ha de comportar com una eina SEO genèrica que informa de 300 avisos. S’ha de comportar com un guardià dels invariants de producció acordats.

Checks de codis d’estat HTTP i redireccions

Comença pels codis d’estat perquè són fàcils de provar i difícils d’excusar.

La documentació de rastrejadors de Google diu que les respostes 2xx passen al pas següent de processament, mentre que el contingut 4xx s’ignora i Google Search no indexa aquestes URLs. Per a 5xx i 429, Google pot alentir temporalment el rastreig, i els errors de servidor persistents poden acabar fent que URLs indexades caiguin. Això converteix les regressions de codis d’estat en una de les candidates més netes per a CI.

Un check pràctic es pot executar contra un desplegament de preview:

curl -I https://preview.example.com/en/blog/example-post/

Però els checks crus amb curl no escalen gaire bé. Un patró millor és mantenir un petit fixture YAML o JSON:

[
  {
    "url": "/en/blog/technical-seo-audits-guide/",
    "expectedStatus": 200,
    "template": "blogPost",
    "locale": "en"
  },
  {
    "url": "/old-services/seo/",
    "expectedStatus": 301,
    "expectedLocation": "/en/services/seo/",
    "template": "redirect"
  }
]

El test runner resol cada path contra el domini de preview, demana les capçaleres, segueix redireccions només quan toca i falla quan l’estat o la ubicació canvien de manera inesperada.

El tipus de redirecció mereix el seu propi check. Google tracta 301 i 308 com a senyals forts que s’hauria de processar la destinació de la redirecció, mentre que 302 i 307 són senyals més febles. Per a routing temporal de campanya, un 302 pot ser correcte. Per a una URL de servei retirada, canviar 301 a 302 durant una migració de framework normalment no ho és.

Aquí és on l’enllaç sobre redireccions 301 i 302 es torna operatiu en lloc de teòric. Les regles de redirecció no són només documentació de migració; són fixtures de test.

El mateix check hauria de marcar cadenes de redirecció. La documentació de rastrejadors de Google diu que Googlebot generalment segueix fins a 10 salts de redirecció, però això no és permís per tolerar el creixement de cadenes. Una release que converteix /old-a/ -> /new-a/ en /old-a/ -> /middle-a/ -> /new-a/ ha augmentat el cost de rastreig i ha afegit superfície de fallada. CI hauria d’informar de la longitud de la cadena i de la destinació final.

Els checks canònics necessiten més que presència

Hi ha una etiqueta canònica. Aquest és el test més feble possible.

Google admet la canonicalització mitjançant rel="canonical" en HTML, capçaleres HTTP i senyals de sitemap. La seva documentació també adverteix contra senyals canònics contradictoris, l’ús de robots.txt per a canonicalització i l’especificació de canònics diferents mitjançant tècniques diferents. Es recomanen URLs canòniques absolutes perquè els paths relatius poden crear problemes a llarg termini, sobretot si els entorns de prova arriben a ser rastrejables.

El pipeline ha de provar la intenció canònica, no només la sintaxi.

Per a una pàgina que s’espera que sigui canònica de si mateixa, comprova:

<link rel="canonical" href="https://www.example.com/en/blog/example-post/">

Per a vistes duplicades o amb paràmetres, comprova la destinació aprovada:

{
  "url": "/en/blog/example-post/?utm_source=test",
  "expectedCanonical": "https://www.example.com/en/blog/example-post/"
}

El check hauria de normalitzar diferències inofensives, com la política de barra final si el lloc té un únic estàndard definit, però hauria de fallar si hi ha fuites d’entorn. Un canònic que apunta a https://staging.example.com/... no és un bug cosmètic. Diu als motors de cerca que la pàgina de producció prefereix una URL que no és de producció.

La mateixa lògica aplica a pàgines entre idiomes. Les etiquetes canòniques normalment haurien d’apuntar a la URL canònica de la mateixa versió lingüística, mentre que hreflang declara alternatives. Google assenyala que les anotacions canòniques amb atributs hreflang, lang, media o type no s’usen per a canonicalització; les alternatives pertanyen a les anotacions alternatives. Barrejar aquestes feines és una font recurrent d’errors SEO multilingües.

Un test CI útil compara tres coses per a cada pàgina de mostra:

• la URL sol·licitada
• el canònic declarat
• la URL del sitemap, si hi és

Si totes tres discrepen, la release hauria de fallar. Els sistemes de cerca poden gestionar una mica d’ambigüitat, però els equips d’enginyeria no l’haurien de desplegar conscientment.

Checks de robots meta i X-Robots-Tag

Les directives robots són perilloses perquè es poden introduir fora de l’HTML visible.

Google documenta dos mecanismes a nivell de pàgina: l’etiqueta robots meta dins del head HTML i la capçalera HTTP X-Robots-Tag. Qualsevol regla disponible en una etiqueta robots meta també es pot especificar com a X-Robots-Tag. Google també diu que, quan les regles entren en conflicte, s’aplica la regla més restrictiva.

Aquesta última frase és un requisit de CI.

Una pàgina amb aquest HTML pot semblar indexable:

<meta name="robots" content="index,follow">

Però la capçalera de resposta encara la pot treure de la cerca:

X-Robots-Tag: noindex

Una captura de navegador no revelarà el problema. Un editor de contingut no el veurà. Un pipeline de desplegament sí.

El check hauria de recuperar tant l’HTML renderitzat com les capçaleres de resposta, i després avaluar la directiva combinada. Per a plantilles indexables, hauria de fallar davant noindex, none, nosnippet inesperat si els snippets formen part de la presentació de cerca prevista, o directives específiques per user-agent com googlebot: noindex.

La interacció amb robots.txt també importa. Google assenyala que la configuració robots meta només es pot llegir si els rastrejadors tenen permís per accedir a la pàgina. Si una URL està bloquejada a robots.txt, Google pot no rastrejar-la per llegir un noindex. Això converteix “bloquejada a robots.txt més noindex” en una mala estratègia d’eliminació i en un patró que val la pena marcar.

Per a context sobre bloquejos de rastreig, consulta la guia d’errors de configuració de robots.txt. En CI, la regla pràctica és simple: no deixis que els equips introdueixin controls de rastreig i indexació contradictoris sense una aprovació explícita.

Observabilitat hreflang per a llocs multilingües

Les fallades hreflang són ideals per a l’automatització perquè les regles són precises.

Google indica que, en una implementació completa, cada versió lingüística s’hauria de llistar a si mateixa i llistar les altres versions disponibles. Les URLs alternatives haurien d’estar completament qualificades, incloent-hi el protocol. Si dues pàgines no apunten l’una a l’altra, Google pot ignorar les etiquetes per a aquest parell.

Per a un lloc amb versions en anglès, castellà i català, una pàgina anglesa de mostra hauria de declarar-se a si mateixa i també les seves alternatives en castellà i català. Les pàgines en castellà i català haurien d’apuntar de tornada. Això es pot provar des d’un build de preview abans de la release.

Un check CI d’hreflang hauria de verificar:

• cada alternativa llistada retorna un 2xx indexable
• cada URL alternativa és absoluta
• cada pàgina inclou una autoreferència
• cada parell alternatiu és bidireccional
• canònic i hreflang no es contradiuen
• els codis d’idioma i regió segueixen patrons vàlids

L’últim punt sembla petit fins que algú publica en-UK en lloc de en-GB, o fa servir un path relatiu que funciona a staging però es resol malament a producció. La guia d’implementació de hreflang cobreix la sintaxi; CI hauria d’aplicar el subconjunt que el teu lloc utilitza realment.

També hi ha una qüestió de priorització. Si un lloc té centenars de milers d’URLs localitzades, comprovar cada clúster hreflang en cada pull request pot ser massa lent. Mostreja per plantilla en pull requests i executa una validació completa del graf hreflang cada nit. Les portes ràpides protegeixen releases. Els rastrejos lents protegeixen cobertura.

Connectar senyals CI amb Search Console i logs

Els checks CI/CD eviten estats dolents coneguts. No substitueixen l’observabilitat de producció.

Google Search Console continua sent el millor lloc per veure com Google està processant realment el lloc: pàgines indexades, problemes de rastreig, eleccions canòniques i rendiment als resultats de cerca. La guia pràctica de Google Search Console és útil perquè CI et diu què has desplegat, mentre que Search Console et diu què ha observat Google després.

Els logs de servidor afegeixen una segona capa. Mostren si Googlebot ha sol·licitat les URLs que t’importen, quins codis d’estat ha rebut i si la freqüència de rastreig ha canviat després d’una release. Per a llocs grans, aquesta és la diferència entre “els nostres tests han passat” i “Googlebot encara malgasta peticions en URLs de paràmetres obsoletes”.

El model net és un sistema de tres capes.

Els checks CI comproven URLs de preview abans del desplegament. Els rastrejos nocturns proven una mostra de producció més gran després del desplegament. Search Console i els logs validen el comportament del rastrejador al llarg del temps.

Quan les tres capes discrepen, confia primer en l’evidència en viu. Si CI diu que una pàgina és indexable però Search Console informa “Exclosa per noindex”, inspecciona capçaleres, HTML renderitzat i diferències de desplegament. Els entorns de preview sovint no inclouen capçaleres a nivell de CDN, redireccions edge o middleware del framework que només s’activa a producció.

Per això el pipeline hauria d’arxivar evidència de les fallades: URL sol·licitada, URL final, cadena d’estats, canònic, directives robots, conjunt hreflang i marca temporal. Sense evidència, les regressions SEO es converteixen en arqueologia de reunions.

Un patró pràctic d’implementació

Comença amb la versió més petita que sigui útil.

Crea un fitxer amb un nom com seo-release-contract.json. Inclou entre 20 i 50 URLs representatives, no tot el lloc. Cobreix cada plantilla i cada idioma. Afegeix expectatives explícites per a estat, canònic, robots i hreflang.

Després escriu un test runner en el llenguatge que el teu equip d’enginyeria ja utilitza. Playwright funciona bé quan importa l’HTML renderitzat. Un script de Node més lleuger amb fetch i un parser HTML és suficient per a checks de capçalera, estat i canònic. Per a rastrejos grans, fes servir Screaming Frog, Sitebulb o un crawler propi sense bloquejar el pull request.

Un bon primer contracte per a un lloc d’agència multilingüe podria incloure:

{
  "url": "/en/blog/technical-seo-audits-guide/",
  "expectedStatus": 200,
  "indexable": true,
  "canonical": "https://ighenatt.es/en/blog/technical-seo-audits-guide/",
  "hreflang": ["es", "en", "ca"]
}

El test hauria de fallar de manera sorollosa quan aparegui una condició d’alt risc:

• status canvia de 200 a 404, 410, 500 o 503
• una redirecció permanent es torna temporal sense aprovació
• el domini canònic canvia a staging, preview o un altre domini
• les plantilles indexables reben noindex
• X-Robots-Tag entra en conflicte amb robots HTML
• les alternatives hreflang deixen de ser recíproques
• les URLs del sitemap retornen respostes no indexables

Els avisos poden cobrir qüestions més suaus: x-default opcional absent, cadenes de redirecció més llargues, canvis de title fora dels rangs acceptats o normalització canònica inesperada.

Aquí també importa una governança sòbria. Un responsable SEO hauria de poder aprovar una release amb noindex intencional per a una pàgina d’arxiu prima. El pipeline hauria d’admetre excepcions, però les excepcions han de ser explícites, datades i revisades. Si no, el fitxer d’excepcions es converteix en un cementiri.

Què no automatitzar massa aviat

L’error habitual és intentar automatitzar una auditoria SEO completa el primer dia. Això acostuma a produir tests lents, fallades sorolloses i enginyers frustrats.

No bloquegis cada desplegament perquè una meta description supera en cinc caràcters el rang preferit. No facis fallar builds per avisos de baixa prioritat d’exports de crawlers. No converteixis CI en un tauler de totes les recomanacions SEO possibles.

Automatitza fallades objectives, d’alt risc i lligades a canvis de codi.

La indexabilitat és objectiva. Els codis d’estat són objectius. Les destinacions canòniques són objectives. Els enllaços de retorn hreflang són objectius. La permanència de les redireccions és prou objectiva quan el comportament esperat està documentat.

La qualitat del contingut, l’encaix amb la intenció de cerca, l’autoritat temàtica i el moviment de rànquings necessiten altres workflows. CI pot dir-te si una pàgina és elegible per ser rastrejada i indexada. No pot dir-te si la pàgina mereix trànsit.

Aquesta distinció ajuda els equips SEO a treballar millor amb enginyeria. Els enginyers estan més disposats a assumir tests quan la condició és precisa. “Aquesta ruta no ha d’emetre noindex” és un requisit de release. “Aquesta pàgina hauria de posicionar millor” no ho és.

Els primers 30 dies

Durant el primer mes, mantén el desplegament del sistema ben acotat.

Setmana u: recull les plantilles principals, rutes localitzades i patrons històrics de fallada. Revisa incidents recents: canònics de staging, noindex accidental, canvis de redirecció, alternatives trencades, deriva del sitemap. Converteix-los en casos de test.

Setmana dos: implementa checks d’estat, redirecció i canònic contra desplegaments de preview. Executa’ls en mode no bloquejant. L’objectiu és mesurar soroll abans d’aplicar cap política.

Setmana tres: afegeix checks de robots meta, X-Robots-Tag i hreflang. Comença a fer fallar builds només en casos de risc màxim: plantilles de servei no indexables, canònics de producció que apunten a staging o respostes 5xx en URLs de mostra.

Setmana quatre: connecta les fallades amb propietat. Un test fallit hauria d’apuntar a la ruta, el valor esperat, el valor rebut i el possible responsable. Si una fallada requereix una decisió del responsable SEO, dirigeix-la allí. Si és una regressió de codi, dirigeix-la a l’equip que ha canviat la plantilla.

Després de 30 dies, revisa què han capturat els checks i què han deixat escapar. Afegeix només els tests que haurien evitat un problema real o un problema plausible d’alt cost.

Aquesta és la disciplina. L’observabilitat SEO tècnica no és més tooling perquè sí. És la pràctica de fer visibles rastrejabilitat, indexabilitat i consistència de senyals just en el moment en què encara es poden arreglar amb poc cost.