SEO para productos agotados: conservar o retirar

El SEO para productos agotados empieza en el catálogo: ¿el artículo volverá, admite pedidos, tiene sustituto o se retiró para siempre? La respuesta HTTP y las señales de búsqueda vienen después. Elegirlas solo porque la URL conserva tráfico crea contradicciones.

Si la falta de stock es temporal, mantén la ficha útil con una respuesta 200, una disponibilidad veraz y un siguiente paso útil para el comprador. Si se vende bajo pedido, permite comprar únicamente cuando la fecha prometida de envío sea real. Merchant Center exige out_of_stock cuando un producto no disponible temporalmente no admite pedidos, y backorder junto con availability_date cuando se aceptan pedidos para enviarlos más adelante (documentación de disponibilidad de Merchant Center). Si el producto se ha descatalogado y cuenta con un sucesor auténtico, utiliza una redirección permanente en el servidor. Cuando la retirada es definitiva y no hay reemplazo, devuelve 404 o 410, salvo que la ficha conserve una función independiente como documentación o soporte (orientación de Google para páginas retiradas o sustituidas).

Antes del tratamiento técnico, decide qué es un sustituto y cuándo la ficha todavía ayuda a comprar o consultar el producto.

Matriz de decisión para una URL de producto

Clasifica la URL y comprueba los supuestos en catálogo, página, feed y checkout.

La última fila admite una excepción: la página puede seguir en 200 si los clientes necesitan manuales, compatibilidad, avisos de seguridad o repuestos. Su tarea será de referencia, no conservar visibilidad. Retira los mensajes de compra falsos, indica que el producto está descatalogado y decide si pertenece a soporte o a un archivo.

Agotado temporalmente: conserva la ficha y retira la promesa de compra

Una rotura breve no borra especificaciones, reseñas ni compatibilidad. Mantener la URL suele tener sentido si compras y almacén prevén reponer y la ficha todavía responde a la búsqueda.

La ficha debe contar lo que el checkout puede cumplir hoy. Merchant Center define out_of_stock como el estado en el que no se aceptan pedidos o el artículo no está disponible para comprar. También exige que el valor del feed coincida con el sitio web y avisa de que puede rechazar un artículo si la página o el checkout indican agotado mientras los datos de producto dicen in_stock (especificación oficial de disponibilidad). Si la tienda no puede servir el pedido, desactiva la compra en lugar de aceptar una operación que el equipo no podrá atender.

Conserva lo que todavía ayuda a decidir:

• nombre, imágenes y especificaciones que distinguen el producto;
• disponibilidad por variante, para que una talla agotada no haga parecer que todas lo están;
• restricciones de entrega o de zona que sigan afectando a la compra;
• aviso de reposición, siempre que la empresa pueda gestionarlo y explique el uso del correo;
• alternativas cercanas, descritas por la diferencia importante y no como una colección aleatoria de superventas.

No inventes una fecha. “Disponible en septiembre” exige el respaldo de compras o del proveedor. Si no hay una previsión fiable, dilo y ofrece un aviso o una alternativa. Así evitas trasladar una promesa falsa a atención al cliente.

La canónica autorreferente debería mantenerse. Un producto agotado no se convierte por ello en un duplicado de la categoría ni de otra ficha. La documentación de Google presenta rel="canonical" como una forma de indicar la URL representativa entre páginas duplicadas o muy similares; no es un mecanismo para expresar estados temporales del inventario (guía oficial sobre URL canónicas). Canonicalizar la ficha hacia una categoría mezcla dos intenciones diferentes y Google puede ignorar la señal porque las páginas no son equivalentes.

Mantén la URL en el sitemap XML si la empresa quiere que la ficha siga siendo apta para aparecer en búsqueda orgánica. Google recomienda incluir en el sitemap las URL que se quieren ver en sus resultados orgánicos y, por lo general, muestra las canónicas (guía oficial de sitemaps). Conserva también los enlaces internos que ayuden a comprar, pero marca el producto como agotado y reordena las tarjetas para que los artículos disponibles no queden enterrados.

La URL no conservará necesariamente su visibilidad: influyen la demanda, la competencia, la utilidad y los sistemas de Google. El objetivo es informar bien mientras la interrupción sea temporal.

Bajo pedido no significa simplemente agotado

Un artículo bajo pedido se compra ahora y se entrega después. Si el checkout no acepta el pedido, está agotado, aunque el mensaje comercial diga otra cosa.

La especificación de Merchant Center exige availability_date cuando la disponibilidad es backorder, y esa fecha debe verse en la página de destino. preorder se reserva para productos nuevos que todavía no se han lanzado; si un artículo ya lanzado volverá a estar disponible y la tienda acepta pedidos, debe indicarse como backorder (documentación de disponibilidad de Merchant Center).

Antes del botón de compra, la ficha debería resolver cuatro dudas:

1. ¿Se cobra al confirmar o al enviar?
2. ¿Qué día se espera que el producto salga de almacén o vuelva a estar disponible?
3. ¿Puede el cliente cancelar si la fecha cambia?
4. ¿Un pedido mixto espera al artículo pendiente o se divide en varios envíos?

Las condiciones cambian por tienda y mercado. El contenido debe reflejar la política real para España y sus zonas de entrega. Aquí el SEO hace visible el estado operativo; no lo rebautiza.

En la capa de datos, publica BackOrder en Offer cuando la oferta siga siendo válida y envía backorder con la misma availability_date en el feed. Los requisitos de las páginas de destino de Merchant Center establecen que los datos de producto, la página y el estado de compra deben coincidir; en las reservas y los pedidos pendientes, la fecha prevista también debe aparecer en la página (requisitos oficiales para páginas de destino). Comprueba la variante seleccionada, el HTML inicial y el estado renderizado, no te limites al registro de producto por defecto.

Descatalogado con sustituto: comprueba antes de redirigir

Una redirección permanente encaja si el modelo no volverá y su sucesor satisface casi la misma necesidad: mantiene el uso, suficiente compatibilidad y una diferencia explicable. Compartir categoría o precio no basta.

Google recomienda redirecciones permanentes de servidor cuando una página se ha trasladado y explica que 301 y 308 indican un cambio permanente de ubicación. Esas redirecciones señalan que el destino debería convertirse en canónico (documentación de Google sobre redirecciones). Por eso el destino ha de ser la URL que el comercio quiere que utilicen compradores y buscadores, no un selector provisional ni una cadena que atraviese modelos antiguos.

Antes de aprobar el mapeo, pregunta:

• ¿Alguien que busque el producto antiguo reconocería el destino como su sucesor?
• ¿El nuevo conserva el uso principal, la compatibilidad y el mercado?
• ¿La página de destino explica las diferencias importantes sin esconderlas?
• ¿Atención al cliente enviaría a esa misma ficha a una persona interesada en el modelo anterior?

Si la única defensa es “los dos pertenecen a la misma categoría”, no redirijas todavía. En el consultorio SEO de Google de agosto de 2024, John Mueller trazó ese límite con productos: puede redirigirse un artículo hacia su reemplazo auténtico, pero no hacia otro que solo se le parezca. También desaconsejó redirigir a ciegas las URL antiguas a un producto similar, una categoría o la página de inicio (consultorio de Google Search Central).

Si el mapeo supera la prueba, crea una redirección permanente directa. Actualiza los enlaces internos, retira la URL antigua del sitemap y confirma la canónica autorreferente del sucesor. Quita la oferta antigua de Merchant Center: el nuevo modelo necesita identificadores, URL y datos propios.

La guía de redirecciones 301 y 302 para SEO explica la implementación de códigos, cadenas y pruebas de migración. Úsala cuando ya esté resuelta la decisión de catálogo.

Retirado sin sustituto: cuándo usar 404 o 410

Si el producto desapareció y ninguna otra URL resuelve la misma necesidad, una respuesta de error es honesta. La plantilla puede ayudar a volver a la categoría, buscar en el catálogo o contactar con soporte, pero el estado HTTP debe seguir siendo un error. Devolver 200 con un aviso de “producto no disponible” y poco contenido puede tratarse como un soft 404; la documentación de Google señala que las páginas que parecen errores y responden 200 pueden excluirse de la Búsqueda (guía de Google sobre errores de rastreo).

La elección entre 404 y 410 depende de la información que tenga el servidor, no de un truco SEO. RFC 9110 establece que 404 Not Found significa que el origen no encontró una representación actual o no quiere revelar que exista, sin precisar si la situación es temporal o permanente. La norma prefiere 410 Gone cuando el servidor de origen sabe que probablemente la retirada sea definitiva (RFC 9110, apartados 15.5.5 y 15.5.11).

Usa 410 si el sistema de ciclo de vida tiene un estado fiable y deliberado de “retirado definitivamente” y no hay una nueva dirección. Devuelve 404 cuando el registro falta, pero el sistema no puede establecer si será permanente, o cuando una misma plantilla gestiona todos los productos ausentes. Google acepta 404 y 410 para contenido retirado sin sustitución (guía de Google sobre páginas retiradas). No añadas noindex para hacer más definitiva la baja: la respuesta que no es de éxito ya comunica que la URL no está disponible.

Limpia las superficies que controla la tienda:

• retira la URL del sitemap XML;
• elimina las tarjetas y los enlaces contextuales que prometan que el artículo sigue a la venta;
• sustituye enlaces por el sucesor solo si este supera la prueba de equivalencia;
• quita el producto descatalogado de Merchant Center;
• conserva una navegación general útil en el error sin fingir que la ficha anterior sigue viva.

Los enlaces externos y Search Console pueden seguir mostrando la URL hasta que Google la rastree de nuevo. Revisa los enlaces valiosos por si existe una sustitución real, pero no fuerces una relación para capturar señales antiguas.

Cuando la ficha antigua todavía tiene trabajo

Algunos productos siguen siendo útiles tras su venta: sus propietarios pueden necesitar manuales, avisos, compatibilidad, firmware, repuestos o especificaciones. Una URL en 200 puede atender esa necesidad si tiene contenido suficiente y deja claro que ya no hay oferta activa.

Separa la consulta de soporte de la antigua plantilla comercial. Retira o desactiva la compra, etiqueta el artículo como descatalogado, indica hasta cuándo se ofrece soporte y presenta el sucesor explicando sus diferencias. Si mantienes el marcado Product, su disponibilidad debe coincidir con la que se muestra en la página (documentación de disponibilidad de Merchant Center). Cuando ya no exista una oferta válida, elimina el Offer obsoleto en vez de inventar precio o disponibilidad para conservar una apariencia de producto en búsqueda.

Esta excepción necesita pruebas. El tráfico histórico no demuestra utilidad. Revisa consultas, búsquedas internas, soporte, descargas y documentación sostenible. Si la demanda restante es “comprar este producto” y la respuesta es no, retirar la URL puede ser lo más útil.

Las alternativas deben explicar la diferencia

Las alternativas ayudan, pero no deben esconder el estado. Responde primero sobre el producto solicitado y muestra después pocas opciones con sus diferencias.

Etiquetas útiles podrían ser:

• “mismo conector y potencia, con un cable más corto”;
• “sucesor actual, pero incompatible con la base de primera generación”;
• “disponible en un paquete de mayor tamaño”;
• “misma talla, otro material y cuidados distintos”.

Esas etiquetas aclaran por qué los productos son comparables y qué se sacrifica al elegir cada opción. Un carrusel genérico de “También te puede gustar” no resuelve esa decisión. Si hay variantes, muestra las tallas o colores disponibles sin cambiar automáticamente la selección ni la URL. Merchant Center exige que la disponibilidad de cada variante en los datos de producto coincida con la variante correspondiente de la página de destino (documentación oficial de disponibilidad).

Los clics no convierten una alternativa en destino de redirección. El enlace permite elegir; la redirección decide por el usuario y señala que una URL sustituyó a otra.

Los datos estructurados describen el estado, no lo arreglan

La documentación de Product de Google admite OutOfStock, BackOrder y Discontinued en Offer.availability, además de otros valores de Schema.org ItemAvailability (documentación de datos estructurados de producto). Elige el valor que coincida con la oferta visible y con la variante seleccionada.

En una rotura temporal, conserva Product y Offer si la ficha y los datos comerciales siguen siendo ciertos, pero cambia la disponibilidad a OutOfStock. Para pedidos pendientes usa BackOrder con precio, moneda y condiciones coherentes. En una ficha retirada, utiliza Discontinued solo si la oferta y el contenido lo respaldan; sin oferta, elimina Offer.

El marcado no decide la respuesta HTTP. Una 301, 404 o 410 no contiene una ficha activa donde conservar JSON-LD obsoleto. Valida el HTML final, sobre todo si JavaScript actualiza variante, precio o disponibilidad.

Para revisar requisitos, variantes y pruebas, consulta la guía de datos estructurados de producto para ecommerce.

La URL orgánica y Merchant Center son controles distintos

Una página orgánica puede conservar utilidad aunque su oferta esté temporalmente ausente de algunos destinos de Merchant Center. Del mismo modo, borrar un producto de Merchant Center no retira por sí solo la URL orgánica. Google explica que participar en Merchant Center es obligatorio en ciertas superficies, como la pestaña Google Shopping, mientras que el rastreo web y los datos estructurados también permiten descubrir y entender fichas de producto (guía de Google para compartir datos de productos).

Por eso conviene tomar dos decisiones por separado:

1. ¿Qué ocurre cuando una persona o un rastreador solicita la URL? Elige 200, redirección permanente, 404 o 410 según la función que conserve la página y la existencia de un sucesor.
2. ¿Debe participar la oferta en los destinos de Merchant Center? Comunica la disponibilidad exacta para los estados temporales y retira del feed el artículo descatalogado.

La documentación de Merchant Center indica expresamente que out_of_stock no debe usarse para un producto que el comercio ya no vende; hay que quitar los artículos descatalogados de los datos de producto. También desaconseja eliminar una ficha solo porque los pedidos estén detenidos temporalmente, ya que volver a añadirla puede retrasar su regreso a las superficies de Google (documentación oficial de disponibilidad).

Los feeds pueden actualizarse a intervalos definidos, pero el rastreo no tiene un tiempo de procesamiento garantizado. Google recomienda combinar datos estructurados en página con datos de Merchant Center y advierte de posibles diferencias si la web cambia antes que el feed. Las actualizaciones automáticas de artículos pueden reducir esos desajustes, aunque el feed sigue necesitando actualizaciones periódicas (guía de Google sobre datos de producto). Usa esa automatización como protección, no como fuente de verdad del catálogo.

Una regla de ciclo de vida para todas las superficies

Los problemas aparecen cuando CMS, feeds, sitemaps y navegación interpretan por separado “no disponible”. Una ficha puede decir agotado, seguir in_stock, desaparecer de los enlaces, permanecer en el sitemap y canonicalizar hacia una categoría. El conjunto se contradice.

Crea un registro de ciclo de vida con entradas explícitas:

• se puede vender ahora;
• admite pedidos para servir más adelante;
• cuenta con una fecha de disponibilidad exacta o una estimación respaldada;
• se espera que vuelva;
• se ha descatalogado definitivamente;
• tiene un ID de sucesor aprobado;
• conserva una finalidad de soporte o referencia.

Convierte esas entradas en reglas del catálogo o del código. El mapeo debe resolver HTTP, canónica, disponibilidad visible y estructurada, compra, feed, sitemap, tarjetas y enlaces internos.

Añade colas de excepción en vez de aceptar valores por defecto silenciosos. Un producto retirado con sucesor no debe redirigir si ese sucesor tampoco está disponible en España. Si no hay una fecha exacta, Merchant Center permite indicar una estimada y exige que la fecha de disponibilidad sea visible en la página (documentación oficial de disponibilidad). No publiques backorder hasta que el equipo de compras o el proveedor pueda respaldar una fecha, exacta o estimada, que vaya a mostrarse en la página. Un producto marcado como comprable cuya variante seleccionada no puede añadirse a la cesta debe fallar la comprobación de coherencia antes de la siguiente exportación.

Monitoriza la transición completa

Agrupa el seguimiento por estado del ciclo de vida. Un informe diario o asociado a cada despliegue puede comparar el catálogo con las superficies publicadas:

Tras publicar, prueba URL de cada fila: respuesta sin JavaScript, renderizado, JSON-LD, feed y sitemap. Termina con una compra para el mercado y la variante seleccionados. Un BackOrder correcto falla si el checkout rechaza el pedido.

En Search Console, revisa Indexación e Inspección de URLs; en Merchant Center, las discrepancias y el destino. Separa los clics orgánicos de Shopping y fichas gratuitas. Registra el cambio de catálogo para compararlo con la visibilidad, no con la edición SEO más cercana.

Preguntas frecuentes

¿Conviene mantener indexable la página de un producto agotado?

Normalmente sí, cuando se espera reponer el producto y la ficha todavía da al comprador una respuesta precisa y útil. Mantén la URL con una respuesta 200, indica que está agotado, conserva su canónica autorreferente y ofrece alternativas realistas o un aviso de reposición. La decisión cambia si el producto no volverá o la página se ha quedado vacía.

¿Debe un producto descatalogado redirigir a su categoría?

Solo si la categoría es de verdad el mejor sustituto para la necesidad concreta, algo poco habitual en una ficha individual. Un sucesor directo que cumpla la misma función es un destino más sólido. Google desaconseja redirigir a ciegas las URL retiradas hacia productos parecidos, categorías o la página de inicio. Si no hay un sustituto claro, devuelve 404 o 410 y haz que la página de error sea útil.

¿Es mejor 404 o 410 para un producto retirado definitivamente?

Ambos códigos indican a los rastreadores que la ficha no está disponible. RFC 9110 establece que 404 no aclara si la situación es temporal o permanente, mientras que 410 es preferible cuando el servidor de origen sabe que probablemente sea permanente. Usa el código que tu catálogo pueda sostener con datos reales. Ninguno exige una redirección si no hay un sustituto auténtico.

¿Se pueden mantener los datos estructurados de tipo Product en una ficha agotada?

Pueden mantenerse si la URL sigue siendo una ficha de producto real y el marcado coincide con lo que ve el visitante. Google admite los valores OutOfStock, BackOrder y Discontinued. No dejes InStock cuando el producto ya no se pueda comprar ni inventes un Offer, un precio o una disponibilidad para conservar la opción de obtener un resultado enriquecido.

¿Debe seguir en Google Merchant Center un producto descatalogado?

No. La documentación de disponibilidad de Google indica que no debe usarse out_of_stock para artículos que el comercio ya no vende y que los productos descatalogados deben retirarse de los datos de producto. Esa acción en el feed es independiente de la URL orgánica: la antigua ficha puede redirigir, devolver 404 o 410 o conservarse como documentación no comercial útil, según lo que ayude ahora al visitante.

Próximo paso: clasifica los cambios recientes

Exporta las URL con cambios de disponibilidad en los últimos 90 días y clasifícalas con la matriz. Prioriza conflictos: 200 retirados, redirecciones sin sucesor, errores en sitemaps y discrepancias entre feed y página.

Registra por URL la evidencia, el resultado para el comprador y quién confirma reposición o retirada. Genera desde ahí las salidas técnicas. El próximo cambio de stock debería producir respuesta, página, feed y descubrimiento coherentes sin otra limpieza manual.