Usamos cookies para mejorar tu experiencia, analizar el tráfico del sitio y personalizar el contenido. Puedes aceptar todas las cookies o elegir qué categorías permitir. Más información
Redirecciones en Ecommerce: 301, 410, Historial de Slugs y Evitando Cadenas (2026) | Ordiko
Guía
Redirecciones en Ecommerce: 301, 410, Historial de Slugs y Evitando Cadenas (2026)
Cuándo usar 301 vs 410 vs otros códigos de estado HTTP para cambios de URL en ecommerce, cómo rastrear el historial de slugs, detectar cadenas de redirección y evitar las trampas comunes que perjudican el SEO.
PT45M
TL;DR. Las redirecciones en ecommerce se tratan de preservar la equidad SEO a través de cambios de URL. Usa 301 para movimientos permanentes (correcciones de slug, rebranding). Usa 410 para eliminaciones permanentes. Rastrea el historial de slugs por entidad para que las URL antiguas se redirijan automáticamente. Detecta y aplana cadenas semanalmente. Renderiza páginas eliminadas con contenido útil, no con un 404 genérico.
Códigos de estado HTTP para ecommerce
Código
Nombre
Significado
Caso de uso
200
OK
La página existe
Página normal de producto/categoría
301
Movido Permanentemente
Usa la nueva URL para siempre
Cambios de slug, rebranding, migraciones de dominio
301 = permanente. Pasa casi toda la equidad de enlaces. Almacena la redirección en caché de manera intensiva. Usar para cambios de slug, migraciones de dominio. 302 = temporal. Pasa menos equidad. No almacena en caché tan agresivamente. Usar para pruebas A/B o interrupciones temporales. Para la mayoría de las redirecciones de ecommerce, 301 es correcto.
¿Cuál es la diferencia entre 404 y 410?
404 = 'no encontrado, podría volver'. Google puede mantener la URL en su índice por un tiempo en caso de que regrese. 410 = 'desaparecido, eliminado permanentemente'. Google elimina la URL más rápido. Para productos descontinuados permanentemente, 410 es mejor higiene SEO.
¿Cuántos saltos de redirección son demasiados?
Dos saltos es el límite práctico. Cada salto pierde 5–10% de equidad de enlaces y añade latencia. Tres o más saltos es una señal. Detecta y aplana automáticamente.
¿Cómo maneja Ordiko el historial de slug?
Cada tabla de entidad tiene una tabla de historial de slug correspondiente (por ejemplo, product_slug_history). En el cambio de slug, se inserta una nueva fila con el slug antiguo; se escribe automáticamente una redirección 301 para almacenarRedirects. La tarea de verificación de cadena de redirección semanal de Trigger.dev HEAD-traza redirecciones y marca cadenas y objetivos rotos.
Lecturas relacionadas
Igual que 302 pero preserva el método
Redirecciones API con POST
308
Redirección Permanente
Igual que 301 pero preserva el método
Redirecciones API con POST
404
No Encontrado
La página no existe, podría volver
Errores tipográficos, URLs mal recordadas
410
Eliminado
Eliminado permanentemente
Productos descontinuados, contenido eliminado
Para ecommerce, el par común es 301 para movimientos y 410 para eliminaciones permanentes.
Sugerir productos similares (usar pgvector cosine en la incrustación de la entidad eliminada).
Proporcionar un cuadro de búsqueda.
Tener un mensaje claro de "este producto ya no está disponible".
Historial de slug por entidad
Cuando un slug de producto cambia, la URL antigua debe redirigirse a la nueva URL. Almacenar esto manualmente es frágil. Rastrea el historial de slugs por entidad:
CREATE TABLE product_slug_history (
id SERIAL PRIMARY KEY,
product_id UUID NOT NULL,
old_slug TEXT NOT NULL,
new_slug TEXT NOT NULL,
changed_at TIMESTAMPTZ DEFAULT NOW()
);
La tabla de historial de slugs te permite rastrear la evolución de la URL de un producto (útil para soporte y archivos legales/de cumplimiento).
Cadenas de redirección
Una cadena: A → B → C.
Por qué las cadenas son malas:
Cada salto pierde un 5–10% de equidad de enlace (Google ha confirmado esto).
Cada salto añade 100–500ms de latencia.
Tres o más saltos aumentan la probabilidad de que Google se rinda al rastrear.
Detección: rastrea cada redirección semanalmente con HEAD.
async function traceRedirect(url: string, hops: number = 0): Promise<{ finalUrl: string; chainLength: number }> {
if (hops > 5) return { finalUrl: url, chainLength: hops }; // guardia de bucle
const res = await fetch(url, { method: 'HEAD', redirect: 'manual' });
if (res.status >= 300 && res.status < 400) {
const location = res.headers.get('location');
if (!location) return { finalUrl: url, chainLength: hops };
return traceRedirect(location, hops + 1);
}
return { finalUrl: url, chainLength: hops };
}
Aplana cadenas: reescribe la fuente para apuntar directamente a la URL final.
// Antes: A → B → C
await db.redirects.update({ from: '/a', to: '/b' }); // existente
// Después de aplanar:
await db.redirects.update({ from: '/a', to: '/c' }); // reescrito
Bucles de redirección
A → B → A es fatal. Detecta en el momento de escritura:
async function writeRedirect(from: string, to: string) {
const wouldLoop = await detectLoop(from, to);
if (wouldLoop) {
throw new Error(`La redirección de ${from} a ${to} crea un bucle`);
}
await db.redirects.insert({ from, to, statusCode: 301 });
}
Ping a IndexNow
Después de escribir una redirección:
await enqueueIndexNow([oldUrl, newUrl]);
El motor vuelve a obtener la URL antigua, ve el 301 y actualiza su índice.
Mejores prácticas
Mantén la tabla de redirecciones ajustada. Con el tiempo, docenas de pequeñas ediciones de slug crean docenas de redirecciones. Aplana periódicamente las cadenas.
No redirijas categorías enteras a la página de inicio. Eso es un 'soft 404' para Google. Redirige a la categoría equivalente más cercana en su lugar.
Evita redirigir a páginas no indexadas. Derrota el propósito de preservar la equidad.
Documenta la intención de redirección. Comentar la columna en la tabla de redirecciones ayuda a tu futuro yo a entender por qué.
Cómo Ordiko maneja las redirecciones
Tabla storeRedirects con columnas from, to, statusCode, tenant.
Historial de slug por entidad: productSlugHistory, categorySlugHistory, etc.
Escritura automática de 301 en el cambio de slug.
productLifecycle.archive() escribe una fila 410 en storeRedirects.
La capa de rutas eliminadas renderiza /products/[slug]/gone con recomendaciones de similitud.
La tarea semanal de Trigger.dev redirect-chain-verify.task.ts rastrea cada redirección y marca cadenas y objetivos rotos.
Reescritura de "Aplanar cadena" con un clic reescribe A → C directamente.
Pings de IndexNow en cada creación de redirección.
FAQ
¿Cuál es la diferencia práctica entre 301 y 302? 301 = permanente. Pasa casi toda la equidad de enlace. Almacena la redirección fuertemente. Usa para cambios de slug, migraciones de dominio. 302 = temporal. Pasa menos equidad. No almacena tan agresivamente. Usa para pruebas A/B o interrupciones temporales. Para la mayoría de las redirecciones de ecommerce, 301 es correcto.
¿Cuál es la diferencia entre 404 y 410? 404 = 'no encontrado, podría volver'. Google puede mantener la URL en su índice por un tiempo en caso de que regrese. 410 = 'eliminado, eliminado permanentemente'. Google elimina la URL más rápido. Para productos descontinuados permanentemente, 410 es mejor higiene SEO.
¿Cuántos saltos de redirección son demasiados? Dos saltos es el límite práctico. Cada salto pierde un 5–10% de equidad de enlace y añade latencia. Tres o más saltos son una señal de advertencia. Detecta y aplana automáticamente.
¿Cómo maneja Ordiko el historial de slugs? Cada tabla de entidad tiene una tabla de historial de slug correspondiente (por ejemplo, product_slug_history). Al cambiar el slug, se inserta una nueva fila con el slug antiguo; se escribe automáticamente una redirección 301 en storeRedirects. La tarea semanal de verificación de cadenas de redirección de Trigger.dev rastrea las redirecciones y marca cadenas y objetivos rotos.