SEO per a productes esgotats: conservar o retirar

El SEO per a productes esgotats comença amb una decisió de catàleg: tornarà, encara es pot demanar, té substitut o ja s’ha retirat? La resposta HTTP i els senyals de cerca depenen d’això, no només del trànsit.

Si la falta d’estoc és temporal, mantén activa la URL útil del producte amb una resposta 200, una disponibilitat fidel a l’estoc i una opció útil. Si acceptes comandes pendents, conserva la pàgina i permet comprar només quan la data prevista de disponibilitat sigui real. Merchant Center exigeix out_of_stock quan un producte temporalment indisponible no es pot demanar, i backorder amb availability_date quan s’accepten comandes per servir-les més endavant (directrius de disponibilitat de Merchant Center). Quan un producte descatalogat té un successor autèntic, aplica una redirecció permanent al servidor. Si està retirat definitivament i no té substitut, retorna un 404 o un 410, tret que la pàgina antiga encara tingui una funció pròpia com a documentació o suport (directrius de Google per a pàgines eliminades o substituïdes).

Google indica que cal retornar 301 quan el contingut s’ha traslladat o té un substitut clar, i 404 o 410 quan desapareix sense alternativa semblant (Google Search Central). La dificultat és decidir què és un substitut i quan la fitxa encara resulta útil.

Matriu de decisió

Fes servir aquesta taula com a primera classificació. Després comprova els supòsits a les seccions següents.

Hi ha una excepció: la pàgina pot conservar el 200 si encara ofereix manuals, compatibilitat, avisos de seguretat, recanvis o altra consulta duradora. Ja no és una oferta, sinó un recurs explícit. Elimina els missatges de compra, marca el producte com a descatalogat i mou la pàgina a suport o a l’arxiu si correspon.

Falta d’estoc temporal: conserva la promesa, no el botó de compra

Un període curt sense unitats no esborra el producte ni la informació que el comprador buscava. Conservar la URL té sentit quan l’equip preveu reposar l’article i la pàgina encara respon a la consulta.

La pàgina ha de deixar clar què pot oferir la botiga ara mateix. Google Merchant Center defineix out_of_stock com l’estat en què el comerç no accepta comandes o el producte no està disponible per comprar. També estableix que el valor del feed ha de coincidir sempre amb el lloc web i avisa que un producte es pot rebutjar si la pàgina o el checkout indiquen que està esgotat mentre les dades de producte diuen in_stock (directrius de disponibilitat de Merchant Center). Desactiva el botó de compra en lloc d’oferir una comanda que la botiga no pot servir.

Conserva les parts de la fitxa que encara ajuden:

• el nom del producte, les imatges i les especificacions que el diferencien;
• la disponibilitat de cada variant, perquè una talla esgotada no faci semblar que ho estan totes;
• les restriccions d’enviament o territorials que encara influeixen en la decisió;
• un avís de reposició, si el negoci el pot gestionar i explica com utilitzarà l’adreça;
• alternatives properes, presentades segons la diferència que importa i no com una tria aleatòria d’articles populars.

No inventis una data de retorn. «Previst per al setembre» només ajuda si compres o subministrament ho avalen. Sense una data fiable, indica que la reposició no està confirmada i ofereix un avís o una alternativa.

La canònica autoreferencial normalment no s’ha de tocar. La falta d’estoc no converteix el producte en un duplicat de la seva categoria ni d’un article proper. La documentació de Google descriu rel="canonical" com una manera d’identificar la URL representativa entre pàgines duplicades o molt semblants; no és una instrucció per gestionar estats temporals d’inventari (documentació de Google sobre canòniques). Fer canònica una fitxa esgotada cap a la categoria barreja dues intencions diferents i es pot ignorar perquè les pàgines no són equivalents.

Mantén la URL al sitemap XML si l’empresa encara vol que aquella pàgina sigui candidata a aparèixer a la cerca orgànica. Google indica que els sitemaps han d’incloure les URL canòniques que el lloc vol veure als resultats de cerca (documentació de Google sobre sitemaps). Conserva els enllaços interns quan siguin útils per comprar, però adapta l’etiqueta i l’ordre de les targetes perquè els articles no disponibles no desplacin els que sí que es poden comprar.

Això no garanteix la visibilitat anterior. L’objectiu és conservar una pàgina exacta mentre la interrupció comercial sigui temporal.

Què vol dir backorder, exactament

Un producte en comanda pendent es pot comprar ara i servir més endavant. Aquest fet operatiu el separa d’una falta d’estoc ordinària. Si el checkout no accepta la comanda, el producte està esgotat, encara que l’etiqueta comercial digui una altra cosa.

L’especificació de Google Merchant Center exigeix availability_date quan la disponibilitat és backorder, i aquesta data també s’ha de veure a la pàgina de destinació. Reserva preorder per a un producte nou que encara no s’ha llançat; si un article ja existent tornarà a tenir estoc i mentrestant se n’accepten comandes, cal utilitzar backorder (directrius de disponibilitat de Merchant Center).

Abans del botó de compra, la fitxa hauria de respondre quatre preguntes pràctiques:

1. El pagament es cobra ara o quan s’envia el producte?
2. En quina data es preveu enviar-lo o tornar-lo a tenir disponible?
3. El client pot cancel·lar la comanda si la data canvia?
4. Una cistella mixta espera l’article pendent o s’envia en diversos lliuraments?

Les condicions varien per botiga i jurisdicció. La pàgina ha d’explicar la política real i mostrar l’estat operatiu sense contradiccions.

A la capa de dades, publica el valor BackOrder corresponent al marcatge Offer del producte mentre l’oferta continuï sent vàlida, i envia backorder amb la mateixa availability_date al feed. Els requisits de pàgina de destinació de Merchant Center estableixen que les dades de producte, la pàgina i l’estat de la comanda han de coincidir; en prevenda o comanda pendent, la data prevista també s’ha de mostrar a la pàgina (requisits de pàgina de destinació de Merchant Center). Comprova la variant seleccionada, l’HTML inicial i l’estat renderitzat, no només el registre de producte per defecte.

Producte descatalogat amb substitut: comprova l’equivalència

Una redirecció permanent és adequada quan el successor resol pràcticament la mateixa necessitat i el producte antic no tornarà. Pensa en un model nou que reemplaça l’anterior dins la gamma del fabricant, amb un ús compatible, el mateix tipus de producte i una via de canvi clara. Tenir un preu semblant o compartir categoria no és suficient.

Google recomana redireccions permanents al servidor quan una pàgina s’ha traslladat i indica que 301 i 308 expressen un moviment permanent. Aquestes redireccions són senyals perquè la destinació esdevingui canònica (documentació sobre redireccions). La destinació ha de ser la pàgina final, no un selector ni una cadena de models antics.

Abans d’aprovar la redirecció, pregunta’t:

• Un comprador que busca el producte antic reconeixeria la destinació com el seu successor?
• El successor conserva el cas d’ús principal, la compatibilitat i el mercat?
• La destinació pot explicar les diferències importants sense amagar-les?
• L’equip d’atenció al client també enviaria el comprador a aquesta pàgina?

Si la justificació és només que “tots dos són de la mateixa categoria”, encara no redirigeixis. A les hores d’oficina SEO de Google d’agost de 2024, John Mueller va posar exemples de productes per delimitar la decisió: es pot redirigir cap a un producte que sigui un substitut genuí, però no cap a una pàgina merament semblant. També va desaconsellar redirigir a cegues URL de productes antics cap a un article similar, una categoria o la pàgina d’inici (hores d’oficina de Google Search Central).

Si el successor supera la prova, aplica una redirecció directa, actualitza els enllaços, retira l’URL antiga del sitemap i comprova la canònica del successor. Elimina l’oferta antiga de Merchant Center: el producte nou necessita identificadors, URL i dades pròpies.

La guia de redireccions explica amb més detall els codis d’estat, les cadenes i les proves de migració. Consulta-la quan la decisió ja estigui presa: redireccions 301 i 302 per a SEO.

Retirat definitivament i sense substitut: 404 o 410

Quan el producte ha desaparegut i cap destinació resol la mateixa necessitat, una resposta d’error és honesta. Una pàgina personalitzada encara pot ajudar el visitant a arribar a una categoria, cercar al catàleg o contactar amb suport, però l’estat HTTP ha de continuar sent d’error. Retornar un 200 amb un missatge de “producte no disponible” i poc més es pot interpretar com un 404 tou; la guia de resolució d’errors de Google explica que les pàgines amb aparença d’error que retornen 200 poden quedar excloses de la Cerca (documentació de Google sobre errors de rastreig).

La tria entre 404 i 410 depèn del que sap el servidor, no d’un truc SEO. L’RFC 9110 estableix que 404 Not Found vol dir que l’origen no té cap representació actual del recurs o no vol revelar-ne cap, sense concretar si la situació és temporal o permanent. També diu que 410 Gone és preferible quan el servidor d’origen sap que probablement és una situació permanent (RFC 9110, seccions 15.5.5 i 15.5.11).

Tria 410 quan el sistema de cicle de vida té un estat fiable i deliberat de “retirat definitivament” i no hi ha cap adreça de reenviament. El 404 encaixa quan falta la pàgina però el sistema no pot determinar si serà permanent, o quan una mateixa plantilla d’error gestiona tots els registres absents del catàleg. Google accepta tots dos codis per a contingut eliminat sense substitut. No cal afegir noindex: una resposta 404 o 410 ja indica a Google que la pàgina no existeix i no s’ha d’indexar (documentació de Google sobre contingut eliminat).

Neteja totes les superfícies de descoberta que controles:

• retira la URL eliminada dels sitemaps XML;
• elimina les targetes de producte i els enllaços interns contextuals que prometen que l’article està disponible;
• substitueix els enllaços per un successor només si supera la prova d’equivalència;
• retira l’article descatalogat de les dades de producte de Merchant Center;
• mantén útil la navegació general de la pàgina d’error sense fer veure que el producte antic encara existeix.

Els enllaços externs i Search Console poden continuar mostrant l’URL fins que Google la torni a rastrejar. Això no invalida l’error. Revisa els enllaços valuosos per si hi ha un substitut real, però no en forcis cap per conservar senyals antics.

Quan una fitxa antiga encara té feina

Alguns productes continuen sent útils després de la venda. Els propietaris poden necessitar manuals, avisos, compatibilitat, firmware, recanvis o especificacions. Una pàgina 200 pot satisfer-ho si té contingut substancial i deixa clar que l’oferta ha acabat.

Separa la consulta de la plantilla comercial: desactiva la compra, indica la retirada, concreta el suport i presenta el successor com a alternativa. Si conserves Product, la disponibilitat ha de coincidir amb l’estat visible. Sense oferta vàlida, no inventis una Offer ni mantinguis un preu obsolet.

L’excepció necessita proves; les visites històriques no mostren si la pàgina encara resol res. Revisa consultes, cerques internes, suport, descàrregues i documentació. Si l’única demanda restant és comprar i la resposta sempre serà negativa, retira la pàgina.

Alternatives visibles que ajudin a decidir

Les alternatives ajuden, però no han d’amagar l’estat. Respon primer sobre el producte demanat i presenta després poques opcions amb les diferències clares.

Les etiquetes útils poden dir:

• “mateix connector i mateixa potència, però amb el cable més curt”;
• “successor actual, incompatible amb la base de primera generació”;
• “disponible en un paquet més gran”;
• “mateixa mida, material diferent i altres requisits de manteniment”.

Aquestes etiquetes expliquen per què els productes es poden comparar i en què divergeixen; un carrusel genèric no. En un producte amb variants, mostra si hi ha un altre color o una altra talla disponibles sense canviar automàticament la variant seleccionada ni la URL. Merchant Center exigeix que la disponibilitat de cada variant a les dades de producte coincideixi amb la variant corresponent de la pàgina de destinació (directrius de disponibilitat de Merchant Center).

Els clics no converteixen una alternativa en substitut. Un enllaç deixa triar; una redirecció tria per l’usuari i declara que la destinació substitueix l’origen.

Les dades estructurades han de descriure l’estat real

La documentació Product de Google admet els valors OutOfStock, BackOrder i Discontinued per a Offer.availability, a més d’altres valors ItemAvailability de Schema.org (documentació de Google sobre dades estructurades Product). Tria un únic valor que coincideixi amb l’oferta visible i la variant seleccionada.

En una falta temporal, conserva Product i Offer si encara descriuen el producte i canvia la disponibilitat a OutOfStock. Per a una comanda pendent, utilitza BackOrder amb preu, moneda i condicions coherents. En una fitxa descatalogada, usa Discontinued només si la pàgina i l’oferta ho sostenen; si no, elimina l’Offer caducada.

Les dades estructurades no decideixen la resposta HTTP. En un 301, 404 o 410 no hi ha cap fitxa activa on conservar JSON-LD obsolet. Valida el render després de canvis de plantilla, sobretot si JavaScript actualitza variant, preu o disponibilitat.

Per als requisits, les variants i la validació, consulta la guia de dades estructurades de producte per a ecommerce.

Les pàgines orgàniques i Merchant Center són controls diferents

Una pàgina orgànica pot continuar sent útil mentre la seva oferta no està disponible temporalment a les destinacions de Merchant Center. A la inversa, eliminar un producte de Merchant Center no retira per si sol la URL orgànica. Google indica que participar a Merchant Center és obligatori per a algunes superfícies, com ara la pestanya Shopping, mentre que les pàgines de producte també es poden descobrir i interpretar mitjançant el rastreig web i les dades estructurades (documentació de Google sobre dades de producte).

Aquesta diferència obliga a prendre dues decisions:

1. Què ha de passar quan una persona o un rastrejador demana la URL? Tria entre 200, una redirecció permanent, 404 o 410 segons la funció que conserva la pàgina i l’existència d’un substitut.
2. Aquesta oferta ha de participar en les destinacions de Merchant Center? Publica una disponibilitat exacta per als estats temporals o retira del feed el producte descatalogat.

Les directrius de Google Merchant Center diuen expressament que no s’ha d’utilitzar out_of_stock per a un producte que el comerç ja no ven; els productes descatalogats s’han de retirar de les dades de producte. També recomanen no eliminar un article només perquè les comandes s’han aturat temporalment, ja que tornar-lo a afegir pot endarrerir-ne el retorn a la visibilitat (directrius de disponibilitat de Merchant Center).

Els feeds es poden actualitzar amb una freqüència controlada, però el rastreig no té un termini de processament garantit. Google recomana combinar les dades estructurades de la pàgina amb les de Merchant Center i assenyala que hi pot haver conflictes de disponibilitat quan el web canvia abans que el feed. Les actualitzacions automàtiques d’articles poden reduir els desajustos, però el feed igualment s’ha d’actualitzar amb regularitat (documentació de Google sobre dades de producte). Considera l’automatització una protecció, no la font de veritat del catàleg.

Una sola regla de cicle de vida per a totes les superfícies

El sistema es trenca quan CMS, feed, sitemap i navegació interpreten pel seu compte «no disponible». Una fitxa pot dir «esgotat», continuar in_stock al feed i apuntar la canònica a una categoria: senyals plausibles per separat, però contradictoris.

Crea un registre de cicle de vida del producte amb entrades explícites:

• es pot vendre ara;
• s’accepten comandes per servir més endavant;
• hi ha una data de disponibilitat confirmada;
• s’espera que torni;
• està descatalogat definitivament;
• té un ID de producte successor, si ja s’ha aprovat;
• conserva una funció de suport o consulta.

Converteix les entrades en sortides amb regles de catàleg, no amb un full aïllat. La regla ha de decidir HTTP, canònica, disponibilitat, compra, Product, feed, sitemap, targetes i enllaços interns.

Crea cues d’excepcions, no valors silenciosos. No redirigeixis a un successor indisponible al mercat, no emetis backorder sense data confirmada i bloqueja l’exportació si una variant marcada com a venible no es pot comprar.

Supervisa els canvis a totes les superfícies

Agrupa la supervisió per estats del cicle de vida. Un informe diari o lligat a cada desplegament pot comparar l’estat del catàleg amb cada superfície publicada:

Després del desplegament, mostra cada estat. Comprova HTTP sense JavaScript, render, JSON-LD, feed i sitemap. Prova també la compra per mercat i variant: BackOrder no serveix si el checkout rebutja la comanda.

A Search Console, revisa Indexació i Inspecció d’URL; a Merchant Center, els desajustos i les destinacions. Separa els clics orgànics de Shopping i de les fitxes gratuïtes. Anota els canvis de cicle de vida per donar context a la visibilitat.

Preguntes freqüents

Cal mantenir indexada la pàgina d’un producte esgotat?

Normalment sí, si el producte tornarà i la pàgina encara dona una resposta exacta i útil. Mantén l’URL amb una resposta 200, indica que no hi ha estoc, conserva la canònica autoreferencial i ofereix alternatives realistes o un avís de reposició. La decisió canvia si el producte no tornarà o si la pàgina ha quedat buida de contingut útil.

Cal redirigir un producte descatalogat a la seva categoria?

Només si la categoria és de debò el millor substitut per a la necessitat concreta, una situació poc habitual en una fitxa individual. Un successor directe amb la mateixa funció és una destinació més sòlida. Google desaconsella redirigir sense criteri pàgines eliminades cap a productes semblants, categories o la pàgina d’inici. Si no hi ha cap substitut clar, retorna un 404 o un 410 i fes que la pàgina d’error sigui útil.

404 o 410: quin codi convé per a un producte retirat?

Tots dos indiquen als rastrejadors que la pàgina del producte no està disponible. L’RFC 9110 estableix que un 404 no concreta si l’estat és temporal o permanent, mentre que el 410 és preferible quan el servidor d’origen sap que probablement és permanent. Utilitza el codi que el catàleg pugui justificar. Si no hi ha cap substitut real, cap dels dos necessita una redirecció.

Cal mantenir el marcatge Product en una pàgina sense estoc?

Es pot mantenir el marcatge Product si continua sent una pàgina de producte real i coincideix amb el que veu el visitant. Google admet els valors OutOfStock, BackOrder i Discontinued. No deixis InStock al marcatge quan l’oferta ja no es pot comprar, ni inventis una Offer, un preu o una disponibilitat només per conservar l’elegibilitat per a resultats enriquits.

Cal mantenir un producte descatalogat a Google Merchant Center?

No. Les directrius de disponibilitat de Google indiquen que no s’ha d’utilitzar out_of_stock per a productes que el comerç ja no ven i que els productes descatalogats s’han de retirar de les dades de producte. Aquesta acció sobre el feed és independent del tractament de l’URL orgànica: la pàgina antiga es pot redirigir, retornar un 404 o un 410, o mantenir-se com a documentació no comercial útil, segons què necessiti ara el visitant.

Un pròxim pas concret

Exporta les URL que han canviat de disponibilitat en 90 dies i assigna’ls un estat. Prioritza els conflictes: 200 per a retirats, redireccions sense successor, errors al sitemap i disponibilitats diferents entre feed i pàgina.

Per a cada URL, registra les proves, el resultat esperat i qui confirma la reposició o retirada. Genera les sortides tècniques des d’aquest registre. Quan canviï l’estoc, la mateixa regla ha de produir HTTP, pàgina, feed i senyals de descoberta sense una altra neteja manual.