Productos agotados o descatalogados: decisiones SEO sin receta única

Respuesta breve

No hay una respuesta única para un producto agotado o descatalogado porque no es un solo caso, sino al menos tres: vuelve, no vuelve pero existe un equivalente, y no vuelve ni tiene sustituto. La decisión correcta depende de si el producto regresa con una expectativa fiable, de si el sustituto resuelve la misma tarea, y del valor informativo, el tráfico y los enlaces que acumula la ficha. La regla que sí es común a los tres casos: la página nunca debe simular disponibilidad para conservar tráfico, y el estado que se declare en la ficha, en el marcado y en el feed tiene que ser el mismo.

Puntos clave

• Antes de decidir la acción hay que clasificar el caso: temporal, definitivo con equivalente o definitivo sin sustituto.
• Una fecha de reposición sin confirmar no se publica; una alternativa real sí.
• La equivalencia se demuestra comparando función, especificaciones, intención y precio, no por pertenecer a la misma categoría.
• Ficha visible, datos estructurados y feed de producto deben declarar la misma disponibilidad.
• Retirar una URL con el código correcto es una decisión válida; dejarla devolviendo 200 con un mensaje de agotado indefinido no lo es.
• Los cambios se aplican por lotes pequeños y reversibles, porque el inventario y la estacionalidad explican parte de lo que se observe después.

No es un caso: son tres

Agotado temporal

Se mantiene la ficha y se comunica el estado. Una fecha de reposición solo si está confirmada.

Retirado con equivalente

Se ofrece el sustituto real: misma función, especificaciones, intención y precio.

Retirado sin sustituto

Se retira con el código correcto. Un 200 con «agotado» indefinido no es una decisión.

Agotado temporal

Si el producto volverá y existe una expectativa operativa fiable, la ficha puede mantenerse publicada con la disponibilidad real, alternativas visibles y, si procede, un aviso de reposición. No muestres una fecha inventada: una fecha incumplida cuesta más que la ausencia de fecha, porque convierte una espera en una promesa rota.

La compra debe impedirse de forma accesible. Un botón deshabilitado sin texto alternativo ni mensaje asociado deja a parte de las personas sin saber qué ha pasado; el estado se comunica con texto visible y con una relación programática entre el mensaje y el control. El marcado de disponibilidad y el feed deben reflejar el mismo estado que la página: una ficha que dice «sin existencias» mientras el feed sigue declarando disponible produce anuncios que llevan a una compra imposible.

Conviene poner un límite temporal a esta categoría. Un producto «temporalmente agotado» durante meses ya no es temporal, y mantener esa etiqueta indefinidamente traslada a quien visita la web una expectativa que la empresa no piensa cumplir. Fija un plazo de revisión y, al vencer, reclasifica el caso.

Retirado con sustituto equivalente

Compara función, especificaciones, intención de compra y rango de precio antes de llamar equivalente a un sustituto. Una redirección permanente tiene sentido cuando el destino satisface la misma tarea que buscaba quien llegó; si cambia demasiado, conviene conservar la información de la ficha original o dirigir a una selección con contexto, y no automáticamente a la categoría más cercana.

El error habitual aquí es redirigir en bloque por proximidad de catálogo. Una redirección hacia una categoría amplia es correcta para el rastreador y desconcertante para una persona, que aterriza en una lista de decenas de artículos sin saber por qué su producto ya no está. Si el sustituto existe, la redirección debe apuntar a él; si no existe, redirigir a la categoría es una forma de esconder el problema.

Si el sustituto existe, la redirección debe apuntar a él; si no existe, redirigir a la categoría es una forma de esconder el problema.

Retirado sin sustituto

Evalúa cuatro cosas antes de decidir: tráfico que sigue recibiendo la URL, enlaces externos que apuntan a ella, valor informativo de su contenido y necesidad de soporte para quien ya compró el producto. Con esas cuatro señales, la ficha puede mantenerse como página histórica útil, retirarse con un código 410 o devolver un 404.

La ficha histórica tiene sentido cuando la información sigue sirviendo a alguien: manuales, especificaciones, repuestos compatibles o instrucciones de mantenimiento. En ese caso la página deja de ser comercial y pasa a ser documentación, y debe decirlo con claridad, retirando cualquier elemento que sugiera que se puede comprar.

El 410 comunica una retirada definitiva y el 404 comunica que no se encuentra. La diferencia práctica es menor de lo que suele discutirse, pero es una señal más precisa cuando la decisión es firme, y ayuda a los propios sistemas internos a distinguir una retirada planificada de un error de plantilla.

Criterios de equivalencia

La palabra «equivalente» es la que más decisiones erróneas ampara, porque cada persona la interpreta a su manera. Estos criterios la hacen comprobable:

• Función: resuelve la misma necesidad, no solo pertenece al mismo tipo de producto.
• Especificaciones críticas: coinciden las que condicionan la compra, como medidas, compatibilidad o capacidad.
• Intención: quien buscaba el original quedaría satisfecho con el sustituto sin sentir que ha bajado de categoría.
• Precio: el rango es comparable; un salto grande convierte la redirección en una sorpresa desagradable.
• Disponibilidad: el sustituto está en stock y no es a su vez un producto en retirada.

Si falla uno de los tres primeros, no es equivalente y no procede una redirección directa. Si solo falla el precio o la disponibilidad, puede procederse con una explicación visible en el destino. La decisión se documenta con el motivo, porque dentro de seis meses nadie recordará por qué esa URL apunta ahí.

Matriz

Matriz de decisión por estado del producto, demanda, sustituto y acción candidata.

Estado	Demanda/enlaces	Sustituto	Acción candidata
temporal	cualquiera	opcional	mantener con disponibilidad real
definitivo	alto	equivalente	redirigir tras validación
definitivo	alto	no equivalente	conservar información o alternativas
definitivo	bajo	ninguno	retirar con el código correcto

La matriz propone una acción candidata, no una sentencia. Un producto con pocos enlaces pero con documentación que sigue consultándose puede merecer la ficha histórica aunque la fila diga retirar. El artículo sobre decidir entre categorías, productos y facetas conecta esta decisión con el sitemap, los enlaces internos y el tratamiento de las facetas, que es donde estas retiradas suelen tener efectos colaterales.

Validación

Aplicado el cambio, hay que actualizar todo lo que apuntaba a la ficha: navegación, listados de categoría, sitemap, feed de producto, datos estructurados y enlaces internos desde artículos o guías. Después conviene rastrear las URLs afectadas y comprobar la caché, porque una redirección correcta en el origen puede tardar en verse si una capa intermedia sigue sirviendo la versión anterior.

Mide por lotes pequeños. Si se retiran cien fichas el mismo día y la semana siguiente cambian las cifras, no habrá forma de separar el efecto de la retirada del efecto de la estacionalidad o de una variación de inventario. Con lotes acotados y fechados, cada cambio deja una huella que se puede leer. La arquitectura de categorías conviene revisarla en paralelo, porque una retirada masiva puede dejar categorías con muy pocos productos.

La respuesta para la persona usuaria

Una decisión técnica debe conservar una salida comprensible. Si el producto vuelve, la página explica el estado sin prometer una fecha no confirmada y ofrece alternativas reales. Si fue retirado, puede mantener documentación útil o conducir a un sustituto equivalente, pero nunca debe simular disponibilidad para conservar tráfico.

Comprueba además los caminos que casi nunca se revisan: búsqueda interna del sitio, páginas guardadas por quien las tenía en favoritos, carritos con el producto añadido, feeds y enlaces desde campañas activas. Una campaña que sigue enviando visitas a una ficha retirada es un coste directo, y suele detectarse tarde porque nadie cruza el catálogo con los anuncios en marcha.

En cuatro láminas

JSON-LD: "offers": { / "@type": "Offer", / "availability": / "https://schema.org/OutOfStock", / "price": "49.90", / "priceCurrency": "EUR" / } / // ficha visible, marcado y feed: lo mismo

4 criterios. Función, especificaciones, intención de compra y rango de precio. Si falla uno de los tres primeros, no procede una redirección directa.

Reversible, con lectura después: 1. Clasificar el caso → 2. Comprobar equivalencia → 3. Lote pequeño → 4. Sitemap, enlaces y campañas → 5. Leer después

Errores frecuentes

• Publicar una fecha de reposición estimada como si estuviera confirmada.
• Redirigir todas las fichas retiradas a la categoría padre y llamarlo equivalencia.
• Dejar el feed declarando disponible lo que la ficha ya marca como agotado.
• Mantener la etiqueta de agotado temporal durante meses sin reclasificar el caso.
• Deshabilitar el botón de compra sin comunicar el estado de forma accesible.
• Retirar cientos de fichas de golpe y perder la capacidad de interpretar lo que ocurra después.
• Actualizar el sitemap y olvidar los enlaces internos y las campañas que apuntaban a la ficha.

Preguntas habituales

¿Qué hago con una ficha agotada?

Depende de cuál de los tres casos es: vuelve, no vuelve pero hay equivalente, o no vuelve ni tiene sustituto. Con reposición fiable se mantiene la ficha y se comunica el estado; con equivalente real se ofrece; sin ninguna de las dos, se retira con el código que corresponda. Clasificar el caso va antes que elegir la acción.

¿Puedo publicar una fecha estimada de reposición?

Solo si está confirmada. Una fecha estimada que no se cumple hace más daño que no dar ninguna, porque quien vuelve ese día se encuentra lo mismo. Sin confirmación se comunica el estado y, si existe, una alternativa real.

¿Redirijo las fichas retiradas a su categoría?

No como norma: la categoría no resuelve la tarea de quien buscaba ese producto. La redirección exige equivalencia demostrada —función, especificaciones, intención y precio—, no pertenecer a la misma familia. Sin equivalente, 404 o 410 son respuestas correctas.

¿Por qué no cuadra mi feed con la ficha?

Porque se actualizan por caminos distintos y es fácil que uno se quede atrás. Ficha visible, datos estructurados y feed tienen que declarar la misma disponibilidad: si el feed dice disponible lo que la ficha marca agotado, el conflicto lo paga la campaña y el cliente.

Próximo paso

Clasifica el catálogo afectado en las tres situaciones antes de tocar ninguna URL, y anota para cada ficha el tráfico, los enlaces externos y si existe candidato a sustituto. Esa tabla es el trabajo real; las acciones se derivan de ella casi solas.

Después define el primer lote, aplícalo con los cambios completos en ficha, marcado, feed y enlaces, y fija una fecha de revisión antes de continuar con el siguiente. Si el catálogo cambia con frecuencia, conviene convertir esa secuencia en un procedimiento estable en lugar de resolverla caso por caso cada temporada.

Fuentes

• Google Search Central, datos estructurados de producto — documentación oficial.
• Google Search Central, redirecciones y la Búsqueda — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, seo para ecommerce es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver seo para ecommerce