¿Vas a rediseñar tu sitio web? Mapea las URL antiguas antes del lanzamiento

Por Noe Guerrero III

Antes de reemplazar un sitio web, haz una lista de las direcciones de sus páginas actuales y decide qué debe pasar cuando alguien abra cada una después del lanzamiento. Algunas direcciones pueden quedarse. Otras necesitan una redirección al reemplazo correcto. Una página que eliminas deliberadamente requiere otra decisión.

Esa lista se convierte en tu mapa de URL. Agrega las respuestas esperadas, los resultados de las pruebas y la persona responsable, y se convierte en una lista de verificación del lanzamiento que tu negocio realmente puede revisar.

Yo querría ver ese archivo antes de aprobar un rediseño. La nueva página de inicio puede parecer terminada mientras que un enlace en una cotización guardada por un cliente sigue sin llevar a ningún lado.

Conserva una dirección cuando todavía cumple su función

Un nuevo diseño no necesita automáticamente una URL nueva. Si /services sigue describiendo los mismos servicios, pregunta si puede permanecer en esa dirección. Cambiar un encabezado o reemplazar una fotografía no le da, por sí solo, un motivo al cliente para usar otro enlace.

Decide la estructura de páginas propuesta antes de crear las reglas de redirección. De lo contrario, el desarrollador podría asignar una página antigua a un destino que vuelva a cambiar de nombre durante la revisión del diseño.

Dale una razón a cada cambio propuesto: dos páginas que realmente se superponen se convierten en una, un servicio pasó a una sección más clara o una oferta antigua terminó. “La plantilla nueva generó esta dirección” merece una revisión más detenida antes de convertirse en el plan permanente.

Construye el inventario a partir de algo más que el menú

Empieza con la exportación de páginas y el mapa del sitio web actual; después compáralos con un rastreo y con las URL que aparecen en los datos analíticos, registros del servidor o Search Console disponibles. Estas fuentes pueden descubrir páginas que no están en la navegación. Incluye también archivos descargables útiles y destinos de campañas.

Pide al personal los enlaces que ha compartido en cotizaciones, firmas de correo, códigos QR impresos y perfiles del negocio. Una pequeña lista de la oficina puede revelar un recorrido importante del cliente que la revisión del diseño no detectó.

Conserva la dirección original exactamente como la encontraste. Registra de dónde salió y qué espera encontrar ahí el visitante. No elimines sin avisar una cadena de consulta, como ?service=repair, hasta que alguien compruebe si selecciona contenido o transmite información que el negocio necesita.

Marca la información faltante como desconocida. Si nadie tiene acceso a los datos analíticos históricos, continúa con los registros disponibles y documenta esa carencia. Puedes priorizar los enlaces conocidos de los clientes sin inventar tráfico ni declarar que las demás páginas no importan.

Asigna una decisión clara a cada dirección

Usa una fila por cada dirección antigua. Mi hoja de trabajo incluiría la URL antigua, su propósito, la decisión, el destino previsto, la respuesta esperada, la persona que revisa y el resultado de la prueba.

Separa tres decisiones:

• Conservar: La página permanece en la misma dirección con contenido adecuado.

• Mover o combinar: Existe un reemplazo relevante y la dirección antigua debe enviar a los visitantes ahí.

• Retirar: El contenido ya no existe y no hay un reemplazo adecuado.

Para los cambios permanentes, la guía de redirecciones de Google recomienda una redirección permanente del servidor cuando sea posible. Tanto 301 como 308 indican un cambio permanente. Estas respuestas también ayudan a comunicar a Google cuál es el destino preferido.

Para el contenido retirado sin un reemplazo similar, Google recomienda devolver 404 o 410. Una página de error amigable puede seguir ofreciendo navegación, pero necesita la respuesta HTTP correcta; mostrar “no encontrado” con una respuesta exitosa 200 puede crear un error soft 404. La guía de errores de rastreo de Google explica la diferencia.

El propietario debe aprobar la decisión sobre el contenido. El desarrollador debe elegir e implementar la respuesta técnica. Ninguno debería tener que adivinar lo que el otro quiso hacer.

Trabaja con un mapa pequeño antes de aprobar el archivo completo

Imagina un taller de muebles en McAllen que está rediseñando su sitio web. Es un ejemplo hipotético, no una migración de un cliente. El equipo conserva su página de contacto, combina dos páginas de reparación, mueve su página de renovación de acabados y elimina una promoción vencida sin reemplazo.

La tabla usa rutas cortas para facilitar la lectura; el archivo de trabajo debe identificar las direcciones antiguas y de destino completas. Las entradas 301 son la opción de redirección permanente elegida para este ejemplo.

Ahora revisa el contenido real del reemplazo. ¿La página combinada de reparación explica tanto la reparación de sillas como la de mesas? ¿Alguien que llegue desde el antiguo enlace de renovación de acabados todavía puede encontrar ese servicio? Un destino con el nombre correcto pero sin la información necesaria no está listo solo porque carga.

En un negocio que atiende a clientes en inglés y español, revisa por separado las páginas antiguas de cada idioma. Conserva el idioma previsto cuando exista un reemplazo adecuado. Si el reemplazo traducido no está listo, regístralo como una decisión pendiente antes del lanzamiento.

Prueba las reglas contra el mapa aprobado

Pide al desarrollador que genere un informe de la configuración propuesta de redirecciones antes del lanzamiento. Para cada fila, el informe debe mostrar la dirección solicitada, la primera respuesta, los destinos intermedios, la URL final y la respuesta final.

Después compara lo ocurrido con lo que aprobó el propietario. Para la página hipotética de renovación de acabados, el resultado esperado es una redirección permanente al destino exacto de ese servicio, seguida de una respuesta exitosa que contenga la información del servicio.

Describe las fallas con precisión. “Destino equivocado” necesita las direcciones esperada y observada. “Redirección rota” necesita la respuesta o el ciclo reales. Un informe útil permite que la siguiente persona reproduzca el problema sin repetir toda la investigación.

Revisa estos casos deliberadamente:

• Una dirección que cambia, una que permanece y una que se retira.

• Enlaces antiguos con la barra final o las variantes de mayúsculas y minúsculas que la gente realmente usa.

• Parámetros de consulta que seleccionan un servicio o llevan información de una campaña.

• Una dirección nueva e inventada que no existe y debe seguir mostrando una página genuina de no encontrado.

• Una excepción a cualquier regla general de redirección, como una página retirada dentro de una sección que se movió.

Una regla que envía cada dirección desconocida a una sola página de servicio puede pasar una revisión rápida de la página de inicio mientras oculta errores en otros lugares. Pide una lista explícita de excepciones en vez de depender únicamente de un patrón general.

Una visita en el navegador confirma la experiencia, pero el informe de respuestas te dice si la redirección prevista realmente ocurrió. Usa ambos. Para un sitio empresarial de tamaño modesto, solicita pruebas del mapa completo, con una revisión humana más detallada de las páginas de las que más dependen los clientes.

Alinea las páginas de destino con el mapa

Una indicación canónica identifica la URL preferida para contenido duplicado o muy similar. No reemplaza una redirección que traslada a los visitantes. La guía de URL canónicas de Google recomienda señales consistentes: indicaciones canónicas que apunten a sí mismas en las páginas preferidas, enlaces internos a esas direcciones y ningún conflicto entre los destinos canónicos de los distintos métodos.

En el ejemplo del taller, la nueva página de renovación de acabados debe identificar su dirección pública prevista en lugar de una ruta antigua o un dominio de vista previa. Revisa algo más que la página de inicio: un error en una plantilla compartida puede afectar todas las páginas de servicios.

Pide al desarrollador que informe la URL canónica encontrada en cada destino del mapa. Por separado, comprueba que las páginas destinadas a las búsquedas públicas no conserven una instrucción noindex o un bloqueo de rastreadores del sitio de vista previa. Mantén intactas las restricciones deliberadas de las áreas privadas.

Revisa la navegación y los enlaces contextuales del sitio nuevo contra el mapa para que utilicen las direcciones finales. Agrega una comprobación de los archivos descargables cuando formen parte del recorrido del cliente; una redirección exitosa de una página de servicio no demuestra que el enlace de su folleto funcione.

El mapa del sitio es un resultado aparte. La guía de mapas del sitio de Google pide URL completas y absolutas, así como las versiones preferidas de las páginas. Compara el archivo generado con los destinos públicos previstos en lugar de suponer que un complemento de mapas del sitio los seleccionó correctamente.

Repite las comprobaciones en el sitio web público

Probar una vista previa demuestra únicamente lo que hizo ese entorno. Después del lanzamiento, repite las comprobaciones de URL en el dominio público y abre los recorridos importantes en un teléfono y una computadora. Una regla del alojamiento o una redirección existente podrían comportarse de manera distinta a la configuración de desarrollo.

Para el taller de muebles, empieza desde la antigua dirección de renovación de acabados, lee la página nueva y usa su enlace para hacer una consulta. Después abre directamente la página de contacto y solicita la dirección de la promoción retirada. Registra el resultado real de cada recorrido con una marca de tiempo.

Mantén la aprobación del negocio separada de la finalización técnica. El desarrollador puede confirmar los códigos de respuesta, mientras que el propietario confirma que la página de reemplazo describe correctamente el servicio. Marca una fila como completa solo cuando pasen ambas comprobaciones requeridas.

Envía el mapa del sitio actualizado mediante la cuenta de administración web correspondiente y revisa los errores de procesamiento reportados. Google trata el envío de un mapa del sitio como una sugerencia, por lo que un envío exitoso no confirma que todas las páginas se hayan rastreado o indexado.

Si algo falla, asigna una persona responsable y una siguiente acción. Corrige la regla o el destino, repite las pruebas afectadas y guarda el resultado nuevo. No conviertas una falla sin explicar en una fila aprobada porque el resto del sitio se vea bien.

Conserva el mapa después del lanzamiento

Entrega el mapa aprobado, las reglas implementadas o su ubicación, el informe de pruebas con fecha y los pendientes. Identifica quién puede cambiar las reglas y dónde debe reportar el personal un enlace antiguo que falle. Estos registros deben quedarse con el negocio cuando termine el proyecto.

Programa una revisión de seguimiento de las solicitudes inesperadas de páginas no encontradas y de los reportes de clientes; después compáralas con los retiros deliberados. Un 410 previsto para una promoción terminada y un enlace roto a un servicio actual necesitan respuestas diferentes.

La guía de cambios de sitio de Google recomienda conservar las redirecciones el mayor tiempo posible, generalmente al menos un año, y señala que la visibilidad en búsquedas puede fluctuar durante un cambio. Una comprobación de lanzamiento no garantiza que las posiciones permanezcan iguales. Acuerda la revisión continua y la conservación de las redirecciones antes de que termine el soporte del proyecto.

El mapa debe acompañar las responsabilidades de cuentas, correo y lanzamiento que cubrimos en nuestra guía de reconstrucción de sitios web en McAllen. Para un rediseño con los servicios de desarrollo web de RGV Web Design, comparte tu sitio actual y los enlaces antiguos que tu equipo todavía utiliza. Eso le da al proyecto un punto de partida concreto: una decisión para cada dirección y evidencia de que funciona como se esperaba.