Cómo migrar URLs de documentación Web3 sin perder acceso

Una migración de documentación es más segura cuando cada URL antigua tiene un destino definido y cada ruta importante se comprueba tras el lanzamiento. Planifico el cambio a nivel de URL, no como una tarea de rediseño. Así, la intención de cada página, las redirecciones, el acceso de los rastreadores y los enlaces internos quedan visibles en un mismo registro. Los equipos de protocolos suelen mover la documentación entre subdominios, frameworks o sistemas de alojamiento. El riesgo para las búsquedas aparece cuando se pierde el recorrido entre una dirección antigua y su reemplazo útil. Esta guía ofrece una secuencia práctica para mapear ese recorrido, probarlo y supervisar lo que siga siendo incierto.

Mapea las URLs antes de elegir una estructura nueva

Empieza con una lista completa de las URLs que pueden ser importantes para los lectores: guías, referencias de API, notas de versión, glosarios, tutoriales y páginas enlazadas desde las interfaces del producto. Exporta el sitemap actual, rastrea el host de documentación y compara ambas listas. Un sitemap muestra las URLs declaradas. Un rastreo muestra los enlaces accesibles. Ninguno demuestra que se hayan capturado todas las URLs históricas, así que añade las páginas de destino de Search Console, las páginas de entrada de analítica y los enlaces de soporte cuando tengas acceso a ellos. Registra la fecha de recopilación y la fuente de cada lista.

Para cada URL antigua, registra el propósito de la página, la tarea de la audiencia, el último estado conocido y el destino propuesto. Mapea por intención. Una migración de /developers/v1/bridge debería apuntar a la guía actual del puente si esa página responde a la misma tarea. Una página de inicio genérica de documentación no equivale a una referencia de API específica. Si el contenido no tiene sucesor, etiqueta esa decisión y determina si la página antigua debe permanecer, retirarse o redirigirse a una página principal realmente útil. No envíes todas las páginas eliminadas a la nueva página de inicio. Eso crea un recorrido deficiente para el lector y puede ocultar qué contenido se conservó realmente.

Usa una tabla de mapeo con una fila por cada dirección antigua. Incluye la ruta de origen exacta, el destino final, el motivo del mapeo, el responsable y el resultado de la prueba. Normaliza las barras finales y las mayúsculas solo según el comportamiento del servidor de origen. Conserva los parámetros de consulta cuando transmitan un estado relevante del usuario. Trata de forma explícita las rutas de idioma y versión. El mapa de URLs se convierte en la lista de aceptación de la migración, por lo que las filas ambiguas deben resolverse antes del cambio de DNS o de alojamiento.

Configura redirecciones permanentes y conserva el acceso de los rastreadores

Cuando una página se ha movido de forma permanente, Google Search Central recomienda redirecciones permanentes del lado del servidor. Implementa una redirección directa desde la URL antigua hasta su destino final. Evita cadenas como URL antigua a host intermedio y después a URL nueva. Las cadenas añaden puntos de fallo y hacen más difícil probar la experiencia final del lector. La redirección debe conservar la ruta relevante y, cuando sea necesario, la cadena de consulta. Prueba URLs representativas y el archivo de mapeo completo después del despliegue, no solo el dominio raíz.

Una redirección no puede ayudar a un rastreador si el host antiguo ya no responde. Mantén activos el dominio antiguo, el certificado TLS y la configuración de redirección durante el periodo de migración previsto. Revisa las redirecciones en la capa de servicio que realmente recibe las solicitudes. Una regla del framework no sirve si el proxy perimetral intercepta antes la solicitud. Confirma el código de respuesta, el destino de Location y la respuesta de la página final desde fuera del entorno de compilación.

Comprueba robots.txt por separado. Google describe este archivo como una forma de controlar el acceso de los rastreadores a las URLs, no como un método fiable para impedir que una página aparezca en Google. Una prohibición amplia puede impedir que Google obtenga la página y vea un noindex a nivel de página. Revisa las reglas tanto en los hosts antiguos como en los nuevos. Confirma también que los recursos de documentación necesarios para renderizar el contenido sean accesibles. Las reglas de robots son específicas de cada host, por lo que un archivo correcto en el dominio de marketing no establece el acceso en un subdominio de documentación.

Valida los canónicos, los enlaces y las respuestas de las páginas

Una lista de comprobación de migración debe verificar más que las redirecciones. En el nuevo destino, confirma que la página devuelve una respuesta correcta, muestra su texto principal sin requerir una ruta del cliente que no esté disponible y declara la URL canónica prevista. El canónico debe apuntar a la nueva dirección preferida, no a la URL retirada ni a una página de inicio sin relación. Comprueba las referencias de idiomas alternativos cuando la documentación esté localizada. Un selector de idioma debe llevar al tema correspondiente cuando exista, en lugar de enviar todos los idiomas a su raíz.

Actualiza los enlaces que controla tu equipo. Sustituye los enlaces internos de la navegación del producto, los portales de desarrolladores, los tutoriales, los ejemplos de API, las notas de versión y las macros de soporte. Las redirecciones ayudan a quienes usan marcadores antiguos, pero no sustituyen a los enlaces actuales. Search Central recomienda actualizar los enlaces internos para que apunten directamente a las nuevas URLs durante una migración. Esto también reduce la dependencia de la capa de redirección.

Usa una muestra que incluya páginas de alto valor, rutas profundas, cadenas de consulta, páginas con barras finales, contenido retirado y cada idioma. Después, ejecuta la lista de mapeo en bloque. Guarda el resultado con la marca de tiempo, el método de solicitud, el estado de respuesta, la URL final y cualquier discrepancia. Una URL que devuelve una página de error blando con HTTP 200 requiere revisión humana. El estado por sí solo no demuestra que se haya cargado el contenido previsto.

Supervisa la migración y responde a las brechas

Después del lanzamiento, revisa los registros del servidor y Search Console para detectar rutas antiguas que aún reciben solicitudes, páginas nuevas que no se pueden rastrear, 404 inesperados y páginas cuya selección de Google difiere del canónico declarado. Compara grupos de páginas equivalentes a lo largo del tiempo. Distingue un retraso temporal del nuevo rastreo de un destino roto comprobando la respuesta real y el contenido renderizado. Los informes de búsqueda no certifican una migración de forma inmediata, y ninguna lista de comprobación puede garantizar la continuidad del posicionamiento.

Mantén un registro breve de incidencias. Para cada anomalía, captura la URL antigua, el destino esperado, la respuesta observada, el momento en que se observó por primera vez, la evidencia y el responsable. Corrige la redirección o el destino, vuelve a probarlo y cierra el registro con un resultado nuevo. Si el destino ha desaparecido realmente, elige un reemplazo útil solo cuando exista. De lo contrario, permite que la URL devuelva una respuesta honesta de contenido no encontrado y elimina los enlaces que sugieran que el contenido sigue disponible.

Para una revisión técnica más amplia, compara este proceso de migración con la guía de SEO técnico para Web3 del sitio y la referencia de SEO para Web3. El propósito no es prometer un resultado de búsqueda. Es conservar un recorrido claro para lectores y rastreadores y hacer visible cualquier pérdida restante para poder diagnosticarla.

Google distingue las redirecciones permanentes y temporales por la señal que proporcionan sobre el destino canónico. Su documentación enumera HTTP 301 y 308 como opciones permanentes del lado del servidor, y HTTP 302, 303 y 307 como opciones temporales. Este recuento describe únicamente las opciones de códigos de estado documentadas. No mide los efectos sobre el posicionamiento ni determina qué regla se ajusta a una migración concreta. Elige según si el cambio es realmente permanente y después prueba la respuesta y el destino desplegados.

Registro de evidencias

Preguntas frecuentes

¿Cómo afectan las redirecciones a Google Search?

Una redirección indica a visitantes y rastreadores que una URL se resuelve en otro lugar. Para un cambio permanente, Google recomienda una redirección permanente del lado del servidor. No garantiza que el posicionamiento o el tráfico permanezcan sin cambios.

¿Debería redirigir cada URL antigua de documentación a la nueva página de inicio?

No. Mapea la página antigua a la página más cercana que resuelva la misma tarea. Si no existe un equivalente, registra esa decisión y utiliza una respuesta honesta de retirada en lugar de un destino general engañoso.

¿Robots.txt elimina una página de Google?

No. Google afirma que robots.txt controla el acceso de los rastreadores y no es un mecanismo para impedir que una página aparezca en Google. Usa los controles de indexación documentados que correspondan al caso y asegúrate de que los rastreadores puedan obtener las señales necesarias.

¿Qué debo comprobar después de migrar la documentación?

Prueba cada URL mapeada, la respuesta final, el canónico, los enlaces internos y el acceso de los rastreadores. Después, supervisa los registros y Search Console para detectar rutas rotas o una selección canónica inesperada.

Referencias

1. https://developers.google.com/search/docs/crawling-indexing/301-redirects, consultado el 2026-11-09.
2. https://developers.google.com/search/docs/crawling-indexing/robots/intro, consultado el 2026-11-09.