Enviament d'URL amb IndexNow: configuració i errors

IndexNow avisa els cercadors participants que s’ha afegit, modificat o eliminat una URL. Bing el recomana per automatitzar les notificacions entre els cercadors participants. La guia d’enviament de Bing diferencia aquesta opció dels mecanismes d’enviament exclusius de Bing.

A un equip SEO li interessa saber si un canvi publicat ha generat l’avís correcte i què ha passat després. Un indicador verd a la integració no resol aquestes preguntes per si sol. El desenvolupador ha de poder seguir l’esdeveniment, verificar el host i consultar la petició i la resposta. El responsable SEO necessita proves sobre la pàgina que el cercador ha trobat posteriorment.

Pensem en un negoci hipotètic de Barcelona que publica pàgines de serveis en castellà, català i anglès. L’editor corregeix la descripció d’un servei, retira una oferta antiga i publica una pàgina traduïda. Cada canvi demana comprovacions posteriors diferents, encara que tots passin pel mateix mecanisme d’enviament. L’objectiu és mantenir un registre fiable de les URL públiques modificades sense obligar l’editor a recordar una tasca addicional cada vegada que publica.

Defineix què comprovaràs abans de connectar l’API

Segons la documentació del protocol, HTTP 200 confirma la recepció; HTTP 202 indica recepció amb la validació de la clau pendent. Cap dels dos estats informa de la inclusió a l’índex. L’especificació de respostes d’IndexNow és el contracte que ha de seguir el registre d’enviaments.

Separa les fites del procés: canvi visible a producció, notificació rebuda, rastreig observat i estat d’indexació comprovat. Assigna un responsable a les incidències entre aquests passos. Si el desplegament ha acabat bé però no hi ha notificació, investiga la integració amb el sistema de publicació. Si el servei ha rebut la URL, continua la investigació amb el descobriment i la pàgina mateixa. Repetir una petició que ja ha arribat no aporta les proves que falten.

Bing afirma explícitament que IndexNow no garanteix ni el rastreig ni la indexació. La guia de configuració estableix aquest límit. Tracta també les posicions, el trànsit orgànic i les citacions en respostes d’IA com a resultats separats; cap d’aquests és un criteri d’acceptació adequat per a una petició de notificació.

Els enviaments es comparteixen entre els cercadors participants. Google no apareix a la llista de punts d’accés de les preguntes freqüents oficials d’IndexNow. No presentis una confirmació de recepció d’IndexNow com un enviament a Google. Mantén les comprovacions de Google Search Console dins del seu procés habitual i actualitza per separat l’inventari de sitemaps XML.

Assigna un responsable a l’enviament

Comprova primer si el CMS, algun connector o el servei d’allotjament ja envia notificacions. El directori de configuració de Bing enumera integracions compatibles i recomana comprovar l’activitat existent a Webmaster Tools. Prioritza una integració existent si pots verificar-ne els esdeveniments i diagnosticar-ne els errors. Desenvolupa un sistema d’enviament propi quan necessitis un control que la integració no ofereixi. És una decisió de manteniment: implica-hi la persona que haurà de reparar el sistema si un desplegament falla.

Demana a qui manté la integració que et mostri un canvi recent. Quina URL pública va enviar? L’avís es va generar en desar un esborrany, en prémer Publica o en completar un desplegament? Es poden consultar les eliminacions? Qui rep l’alerta quan fallen les peticions? Aquestes preguntes aporten més informació que comparar captures de pantalla dels connectors.

En un web estàtic, pren com a punt de partida el desplegament completat a producció. Un fitxer desat al repositori encara és només un canvi previst. Les compilacions fallides, les cancel·lacions i els retards de desplegament queden abans de la notificació. Envia els avisos quan el contingut o la resposta esperats ja estiguin disponibles al host públic.

Designa una persona responsable del manteniment i anota el sistema d’enviament triat a la documentació operativa de l’equip. Abans d’afegir un altre connector o una acció al desplegament, revisa el procés actual. Si no pots evitar sistemes que se solapen, documenta quins esdeveniments gestiona cadascun i com contrastaràs els registres. Un augment inexplicat del volum de peticions és motiu per investigar-lo.

Verifica el host i la ubicació de la clau

Per a una configuració manual, les preguntes freqüents especifiquen una clau de 8–128 caràcters formada per lletres, xifres o guionets. Les instruccions de la clau també exigeixen accés públic sense iniciar sessió. Genera un valor per al teu web; les cadenes següents són valors ficticis d’exemple.

El fitxer de verificació a l’arrel és un text UTF-8 que es diu com la clau, amb el sufix .txt, i conté la mateixa clau. IndexNow documenta la verificació de titularitat mitjançant aquest fitxer. Per a un host d’exemple, la configuració proposada seria:

Host: www.example.com
Key: 61af7490d82b4e718093a420f96cbe25
File URL: https://www.example.com/61af7490d82b4e718093a420f96cbe25.txt
File content: 61af7490d82b4e718093a420f96cbe25

Comprova directament el fitxer desplegat amb un client HTTP. Inspecciona tant el contingut com el codi d’estat: una resposta alternativa de l’aplicació pot retornar una pàgina HTML amb la marca del web on esperaves text pla. Fes la prova sense cap sessió d’administrador i confirma que una comprovació del tallafoc o una pantalla d’inici de sessió no substitueix la resposta. Desa les proves al costat de la configuració de la integració.

Una ubicació alternativa del fitxer requereix keyLocation. Un fitxer sota /catalog/ autoritza aquest prefix d’URL, però no pàgines alienes sota /services/. Les regles d’ubicació del protocol fan que l’arrel sigui l’opció més senzilla per a un sistema que envia avisos de tot el web.

En webs multilingües, cal prestar atenció a aquest abast. Situar la clau dins de la carpeta anglesa perquè és on treballa el desenvolupador és un error de configuració evitable. Planifica l’abast de la verificació abans de triar un directori còmode. La condició d’un únic host també obliga a configurar expressament el domini sense subdomini i el host amb www, sense donar per fet que un fitxer cobreix tots dos.

Els subdominis necessiten fitxers de verificació propis, segons les preguntes freqüents d’IndexNow. Mantén una fitxa de configuració per a cada host que gestiones. Inclou-hi el host de producció, l’identificador de la clau, la URL del fitxer, l’equip responsable i la data de l’última verificació. És normal que el fitxer de verificació sigui públic; les credencials de desplegament no hi tenen cabuda.

Quan canviïs la clau, coordina el fitxer desplegat i la configuració d’enviament dins d’una mateixa versió. Prova el fitxer nou abans d’utilitzar-lo en peticions de producció. Conserva prou informació de la configuració anterior per entendre qualsevol intent antic que encara sigui a la cua i comprova que el procés d’enviament utilitza la configuració prevista quan ho torna a provar.

Prova una petició representativa abans d’enviar un lot

L’API admet una sola URL mitjançant GET i un conjunt mitjançant POST amb JSON, amb un màxim de 10.000 URL per POST. La documentació d’enviament defineix aquestes modalitats. Per provar el funcionament, comença amb una URL pública real que s’hagi modificat fa poc; evita començar amb una exportació de tot el web.

Aquest cos de petició POST és un exemple dels camps documentats. Substitueix el host, la clau i les URL d’exemple per valors que controlis:

{
  "host": "www.example.com",
  "key": "61af7490d82b4e718093a420f96cbe25",
  "keyLocation": "https://www.example.com/61af7490d82b4e718093a420f96cbe25.txt",
  "urlList": [
    "https://www.example.com/en/services/",
    "https://www.example.com/ca/serveis/"
  ]
}

Fes servir https://api.indexnow.org/indexnow amb JSON i la capçalera Content-Type application/json; charset=utf-8. L’exemple de configuració manual de Bing mostra aquesta estructura. L’exemple anterior descriu el cos d’una petició; no és un script que hagi enviat aquestes pàgines.

Per a GET, codifica la URL de la pàgina com a paràmetre de consulta. El protocol exigeix escapar les URL. En un cos POST, utilitza el serialitzador JSON del client i conserva URL absolutes vàlides a la llista. Evita concatenar cadenes a mà, sobretot quan el camí inclou caràcters accentuats o la consulta conté un signe &.

A la prova inicial, registra la URL exacta enviada, el punt d’accés triat, la marca de temps, l’estat i les capçaleres de resposta. Compara la URL registrada amb l’adreça de la pàgina prevista al navegador. Conserva’n el prefix d’idioma, les majúscules i minúscules del camí i la convenció de barra final. No enviïs un host de previsualització només perquè apareix al missatge de desplegament correcte del proveïdor.

Passa als lots quan puguis reconstruir aquesta primera petició sense dubtes. Agrupa les URL per host verificat i fixa un límit explícit de mida del lot. El màxim de 10.000 URL és un límit del protocol, no una quantitat que hagis d’assolir abans d’enviar canvis. Tria lots més petits si faciliten la inspecció o el reenviament de peticions fallides.

Decideix quins esdeveniments mereixen un avís

Acorda amb l’equip editorial quins canvis generaran una notificació. Les recomanacions següents estan pensades per a un web d’empresa; adapta els exemples al contingut que publiques. Fes servir el resultat públic del canvi per decidir si un esdeveniment ha d’entrar a la cua.

IndexNow accepta URL redirigides i URL eliminades que retornen 404 o 410. Les preguntes freqüents recullen explícitament tots dos casos. No reutilitzis un filtre d’exportació de sitemaps que descarti totes les URL amb un estat diferent de 200: la política de notificacions ha de conservar les eliminacions intencionades.

Quan retiris una oferta, desa l’adreça antiga abans d’eliminar el registre del CMS. Si no ho fas, el sistema de publicació pot deixar el procés d’enviament sense cap adreça per notificar. Identifica l’esdeveniment d’eliminació al registre propi, encara que el cos enviat sigui una llista d’URL. Qui el revisi més endavant ha de poder entendre per què s’ha enviat expressament una pàgina que ja no existeix.

En un canvi d’adreça, verifica per separat la URL antiga i la destinació nova. Comprova a producció la resposta 301 prevista, o la redirecció que correspongui. Si la destinació també és nova o s’ha modificat, inclou-la com a esdeveniment propi. Una prova de redirecció no demostra que el cercador ja hagi consultat la destinació.

Defineix regles explícites per a les traduccions. En l’exemple hipotètic de Barcelona, canviar només el text castellà no demostra que hagi canviat la resposta catalana o anglesa. En canvi, una dada de servei compartida pot afectar tots els idiomes un cop desplegada. Obtén les URL afectades a partir del resultat publicat o de les relacions entre continguts i inspecciona’n una mostra. Mantén les comprovacions de canonical i hreflang dins de l’auditoria SEO tècnica del web; les notificacions no corregiran aquestes relacions.

Per a pàgines que canvien sovint, les preguntes freqüents oficials recomanen almenys 5 minuts entre notificacions repetides de canvis significatius. Les indicacions d’automatització prioritzen els canvis substancials per sobre dels cosmètics. Aplica aquesta separació després de decidir si el canvi mereix un avís. Una pàgina sense canvis no necessita un temporitzador.

Conserva una cua que puguis recuperar

En una integració pròpia, un disseny pràctic és una llista persistent de canvis de producció pendents. Desa la URL amb l’hora de l’esdeveniment, l’identificador de la versió desplegada i el resultat previst. Deixa que un procés en segon pla enviï aquesta llista independentment de l’acció de publicar de l’editor. És una recomanació d’implementació: l’equip ha de poder reintentar el lliurament sense demanar a l’editor que torni a publicar el contingut.

Agrupa els canvis molt seguits d’una mateixa URL abans d’enviar-los. Conserva l’últim estat públic significatiu i prou historial per diagnosticar què ha passat. Si una pàgina es publica i es retira abans que s’executi el procés, qui ho revisi ha d’entendre aquesta seqüència. Evita un indicador d’èxit que esborri el motiu de l’esdeveniment.

Si un lot no supera la validació, conserva’l amb les URL que en formen part per poder-lo inspeccionar. Reconstruir la llista a partir del contingut actual pot ometre les URL eliminades que van originar la notificació. Vincula els reintents als esdeveniments registrats i comprova si hi ha canvis posteriors que els substitueixen.

Documenta què passa quan el procés es reinicia. Després d’una fallada, quins registres continuen pendents? Si es reverteix un desplegament, quines URL necessiten ara un avís nou? Incorpora aquestes preguntes a les proves d’acceptació mentre la cua encara sigui petita. Recuperar un enviament fallit demostra millor que el sistema està preparat per operar que acumular moltes peticions de prova satisfactòries.

Gestiona els errors segons la causa

Els codis de resposta següents provenen de la referència de configuració d’IndexNow de Bing. Les accions suggerides són recomanacions operatives; no prometen una resposta concreta en l’intent següent.

Mantén diferenciats els estats 200 i 202 als registres. Un 202 demana seguiment de la verificació, no reenviar el mateix lot una vegada i una altra. Comprova l’accés públic al fitxer i la configuració abans d’atribuir una validació que continua pendent a un problema de contingut. Si el procés etiqueta totes dues respostes com a “indexat”, corregeix l’etiqueta abans que algú en faci un informe.

Davant d’un 429, respecta Retry-After si s’inclou a la resposta; cada cercador participant estableix els seus límits. Les indicacions oficials sobre límits de peticions no publiquen una quota diària universal. No calculis un suposat dret d’enviament diari multiplicant la mida màxima del lot per una freqüència de peticions imaginada.

Quan una fallada transitòria de xarxa, un temps d’espera exhaurit o un error del servidor deixin el lliurament incert, aplica una política de reintents limitada. Una opció raonable d’enginyeria és augmentar les esperes amb una variació aleatòria, fixar un màxim d’intents i emetre una alerta quan s’assoleixi. Són decisions de disseny, no garanties addicionals de l’API d’IndexNow. Conserva els detalls de la fallada perquè la persona següent pugui distingir un problema de connexió d’una petició rebutjada.

Abans de reenviar una cua acumulada, comprova que el sistema encara apunta al host de producció correcte i que el fitxer de la clau continua disponible. Repara primer els errors permanents. Reenviar milers de peticions malformades més de pressa només dificulta la investigació del problema original. Si la cua creix després d’un desplegament, compara el volum d’esdeveniments nous amb els lliuraments satisfactoris i inspecciona els errors repetits per causa.

Comprova què ha passat després de la recepció

Bing Webmaster Tools mostra l’origen i l’hora de l’enviament, a més de l’estat de rastreig i indexació d’una mostra d’URL. La pàgina d’ajuda indica que les hores d’enviament sense zona horària especificada fan servir UTC. La documentació dels informes d’IndexNow defineix aquests camps. Tingues-ho present quan comparis un registre de desplegament amb el rellotge d’un editor a Catalunya.

Tria un conjunt petit i estable d’esdeveniments rellevants per fer-ne seguiment. Inclou-hi una pàgina nova, una d’actualitzada i una eliminació intencionada si el desplegament conté aquests casos. Desa l’hora d’observació al costat de cada estat. Un informe capturat abans del rastreig següent no permet establir què ha fet el cercador amb el contingut més recent.

L’anunci d’Insights de Bing descriu informes d’URL enviades, rastrejades i indexades, amb detall dels últims 1.000 enviaments. Aquest anunci justifica utilitzar aquesta vista per diagnosticar incidències. Conserva un registre propi d’esdeveniments per disposar d’un historial durador, en lloc de tractar una mostra recent com si fos una exportació històrica completa.

Fes servir la inspecció d’URL de Bing per comparar la informació de l’índex amb una consulta en directe. Segons la documentació, la prova Live URL informa de les redireccions sense seguir-les automàticament; inspecciona la destinació per separat. Anota si cada observació prové de la vista de l’índex o de la prova en directe.

Si s’ha rebut la notificació d’una pàgina nova però la pàgina continua sense indexar-se, inspecciona l’accessibilitat, robots.txt, noindex i el canonical declarat. Després revisa si el contingut és útil i diferenciat. Mantén visible l’estat de la notificació mentre investigues la pàgina: són proves diferents. La nostra guia d’anàlisi de registres del servidor explica com comprovar l’activitat dels rastrejadors a partir dels registres.

En una eliminació intencionada, planteja la comprovació al revés: ha desaparegut el resultat obsolet després que el cercador hagi processat la resposta modificada? No classifiquis totes les URL enviades però no indexades com a errors. Un informe útil anota el resultat previst al costat de l’observat, de manera que una oferta eliminada no es barregi amb una pàgina de serveis acabada de publicar.

Desplega la integració amb un registre d’acceptació breu

Comença amb un sol host de producció i un esdeveniment de publicació controlat. Verifica el fitxer de la clau, captura la petició i classifica’n la resposta. Prova una fallada recuperable a l’entorn de proves de la integració o amb un punt d’accés simulat; evita saturar expressament l’API pública. Demostra que l’esdeveniment es conserva a la cua i que una petició corregida pot completar el lliurament.

Després comprova una actualització real i una eliminació real quan es produeixin. Registra què ha canviat l’editor, quan ha canviat la resposta pública, quina URL ha enviat el procés i quines proves de seguiment hi ha disponibles. Si no pots relacionar aquests fets, resol el punt que falta abans d’activar tots els tipus de contingut.

Descriu el desplegament amb precisió: la integració envia els canvis de producció que compleixen els criteris, registra els resultats de lliurament i permet investigar incidències. Afirmar que accelera la indexació requereix observacions separades i una comparació adequada. Les preguntes sobre la selecció posterior de fonts a Copilot corresponen a la guia de Bing AI Performance.

Per a la pròxima publicació, demana a l’equip que reconstrueixi tot el recorregut d’una URL. El resultat ha de ser comprensible per a l’editor, el desenvolupador que manté l’enviament i l’especialista SEO que comprova la pàgina. Aquesta és la prova que necessites abans d’ampliar el procés.