Saltar al contenido
TwoQM · Software y tecnología empresarial · Brownsville, Texas · Desde 2016
TwoQM LLC
Artículos

Operaciones y cumplimiento

Elabore un mapa de redirecciones antes de renombrar o eliminar páginas del sitio

Inventarie URLs de alto tráfico, mapee vieja→nueva con 301, implemente en host/CDN/CMS, haga smoke-test tras el deploy y actualice el sitemap—para que el rediseño no deje huérfanos a Google, anuncios, favoritos y códigos QR.

Escritorio de madera cálido con una laptop abierta mostrando un diagrama simple de rutas URL, cuaderno espiral con columnas de mapeo a mano, pluma negra y taza de café en luz suave de mañana
Elabore el mapa de redirecciones antes de renombrar o eliminar páginas en vivo—para que Google, anuncios, favoritos y códigos QR impresos sigan funcionando.

Por qué las redirecciones van en el plan del proyecto—no en la semana de limpieza

Renombrar una página de servicios, limpiar slugs viejos del CMS o borrar un artículo que aún posiciona puede romper más que su menú. Google conserva URLs antiguas en los resultados. Los anuncios de pago siguen apuntando a la landing del año pasado. Los favoritos, las firmas de correo y los códigos QR impresos no se actualizan solos. Para un negocio pequeño, un rediseño sin mapa de redirecciones convierte el “refrescamos el sitio” en semanas de soft 404 y prospectos perdidos.

Esta es la lista de operaciones que TwoQM recomienda antes de renombrar, reorganizar o eliminar URLs en vivo. No es una comparativa de proveedores.

Una redirección indica a navegadores y buscadores que una URL se movió y hacia dónde ir. Un 301 (permanente) es la opción habitual cuando la ruta anterior desaparece de forma definitiva y quiere que el valor SEO y los favoritos sigan a la página nueva. Una redirección temporal puede servir para una campaña corta o una prueba A/B, pero la mayoría de los rediseños y limpiezas de CMS deben usar redirecciones permanentes.

Omitir el mapa genera problemas predecibles: URLs posicionadas o de pago regresan 404 o plantillas soft-404, los códigos QR y menús impresos siguen codificando la ruta vieja, y los favoritos del equipo envían gente a enlaces muertos. Elabore el mapa antes de publicar la nueva arquitectura de información, no después de la fiesta de lanzamiento.

Paso 1: Inventarie las URLs que de verdad importan

No empiece por cada archivo del CMS. Empiece por evidencia de tráfico y dinero:

Google Search Console — Páginas con impresiones y clics en los últimos 3–12 meses. Exporte las principales landings.

Analítica — Páginas de aterrizaje y de salida con sesiones reales (no solo visitas vanidosas a la home).

Google Business Profile y directorios — URLs en su perfil, publicaciones y botones de “sitio web”.

Anuncios y correo — URLs finales en campañas de Google/Meta, CTAs de newsletters y automatizaciones.

Impresos y enlaces de socios — Códigos QR, listados de cámara, portales de proveedores y PDFs.

Tope el primer pase a un conjunto manejable: cada URL con clics relevantes más cada ruta de conversión. Puede ampliar después. El objetivo es cubrir riesgo, no archivar cada borrador jamás publicado.

Paso 2: Arme la hoja de cálculo (vieja → nueva)

Cree una hoja compartida que el equipo pueda editar. Columnas mínimas:

| Columna | Propósito |

| old_url | Ruta completa o URL completa tal como existe hoy |

| new_url | Destino que vivirá después del lanzamiento |

| redirect_type | 301 (por defecto) o temporal si es realmente de corta duración |

| owner | Quién verifica que el contenido destino sea correcto |

| source | Search Console, anuncios, GBP, impresos, etc. |

| status | Planeado / implementado / smoke-tested / bloqueado |

| notes | Parámetros de consulta, reglas de diagonal final, rutas de idioma |

Reglas que mantienen la hoja honesta: una URL vieja por fila; prefiera pares claros de ruta a ruta (/servicio-viejo → /servicios/nombre-nuevo); mande huérfanos al hub más relevante—no un volcado a la home por cada página muerta—y anote por qué; nunca invente destinos—si el contenido no está listo, marque la fila como bloqueada antes de borrar la URL vieja.

Paso 3: Implemente en la capa correcta

Dónde configura las redirecciones depende de cómo se sirve el sitio:

Host / proxy inverso — .htaccess, mapas de nginx o herramientas de “redirect” del panel del hosting.

CDN / edge — Cloudflare Page Rules / Redirect Rules, Fastly, etc., cuando el edge responde primero.

CMS — Plugins de redirección o tablas nativas (útiles, pero confirme que se disparan antes de las plantillas soft 404).

Elija una capa principal para el mapa público y no mantenga tres listas en conflicto. Documente cuál gana. Verifique que una muestra de URLs viejas devuelva el código de estado esperado y el encabezado Location—no un mensaje HTML de “página movida” con código 200.

Paso 4: Smoke-test después del despliegue

Antes de dar por terminado el rediseño, pruebe como un desconocido con un favorito:

Abra 10–20 URLs viejas de alto valor de la hoja en una red celular y en una segunda red.

Confirme 301 (o el tipo planeado), la URL final correcta y que HTTPS siga coincidiendo.

Evite cadenas largas (vieja → intermedia → intermedia → nueva); un solo salto es ideal.

Envíe un formulario de contacto o reserva que usaba una URL vieja en anuncios o correo.

Confirme que las plantillas soft 404 no respondan por URLs mapeadas (un 200 de “no encontrado” es peor que una redirección limpia).

Deje los verdaderos desconocidos como 404 intencionales solo cuando no haya destino útil—y quítelos del sitemap.

Paso 5: Actualice sitemap, enlaces internos y el documento vivo de operaciones

Las redirecciones son necesarias pero no suficientes.

Sitemap XML — Publique solo URLs canónicas vivas. Quite rutas retiradas para que los rastreadores dejen de pedir fantasmas.

Enlaces internos — Actualice menú, pie, botones y enlaces en el contenido a las rutas nuevas. No dependa de redirecciones para siempre en su propio sitio.

Documento vivo de operaciones — La hoja sigue abierta. Cada renombre futuro obtiene una fila antes de publicar en el CMS. Trate el mapa como infraestructura, igual que DNS y respaldos.

Lista corta pre-lanzamiento

Las URLs top de Search Console y anuncios están como filas en la hoja

Cada fila tiene un destino real o una decisión explícita de “sin redirect / 404 verdadero”

El tipo de redirección por defecto es 301 salvo excepción fechada

Una capa de implementación está documentada, cargada y smoke-testeada desde dos redes

Sitemap y enlaces internos principales actualizados; hay un responsable para 30 días de monitoreo de 404

Cómo piensa TwoQM los cambios de URL

Los renombres y limpiezas son normales. Las rutas rotas del cliente son opcionales. Invierta medio día en el mapa de redirecciones y protege años de favoritos, posicionamiento y materiales impresos. Omítalo y reconstruirá la confianza una llamada confusa a la vez.

Si quiere un segundo par de ojos sobre una hoja de redirecciones antes del lanzamiento, TwoQM puede revisar el inventario, los códigos de estado y el plan de smoke-test—trabajo práctico de operaciones, no un pitch de rediseño.

TwoQM articles

Useful technology guidance, sent thoughtfully.

No generic news feed. Just practical analysis for the systems small businesses rely on.