¿Cómo redactar un brief SEO para el rediseño de un sitio web? Lista de aspectos clave para la migración y la validación

¿Cómo compatibilizar el calendario del proyecto y el tráfico de búsqueda al rediseñar un sitio web? Ante necesidades de SEO para el rediseño de un sitio web como «cahier des charges seo refonte d'une site», la verdadera tarea de quien dirige el proyecto no consiste en añadir unas cuantas recomendaciones de optimización, sino en lograr que los equipos de diseño, desarrollo, contenidos y marketing acuerden el alcance de la migración, las responsabilidades de entrega y los criterios de aceptación. Que las páginas se abran es solo el punto de partida; lo que más suele pasarse por alto al publicar el sitio es si el tráfico antiguo podrá llegar a las páginas nuevas correctas.

Antes de empezar, deje por escrito los activos del sitio antiguo y los límites del rediseño

El documento de requisitos no debería empezar con «la nueva página de inicio debe ser más atractiva». Primero, confirme si el proyecto abarca el diseño visual, el sistema de gestión de contenidos, el dominio, la estructura de directorios o varios de estos elementos a la vez. Si el rediseño no cambia el dominio ni las rutas, la atención puede centrarse en el contenido de las páginas y la implementación técnica. Si también se cambia el dominio o se reorganizan los directorios multilingües, habrá que planificar pruebas de migración y un periodo de seguimiento posterior al lanzamiento.

El inventario del sitio antiguo debería incluir, como mínimo, las URL actuales, los tipos de página, los títulos, los códigos de estado, las URL canónicas y las páginas que reciben tráfico de búsqueda orgánica o generan consultas comerciales. Los datos pueden cotejarse con los resultados del rastreo del sitio, Google Search Console, las herramientas de analítica web y los registros del equipo comercial. No se fije únicamente en el tráfico reciente: los productos de temporada y la documentación técnica vinculada a ciclos de compra largos también pueden merecer conservarse.

Para las páginas que se vayan a eliminar, el documento de requisitos debe registrar el motivo y cómo se gestionarán. Por ejemplo, si un producto descatalogado tiene un modelo sustituto, se puede dirigir al usuario a la página correspondiente. Si no existe contenido equivalente, no conviene redirigir todas las páginas a la página de inicio solo para evitar errores. La persona responsable del negocio debe confirmar las equivalencias, el personal de SEO debe evaluar el impacto en las búsquedas y el equipo de desarrollo debe implementar los cambios, para evitar discusiones sobre quién toma las decisiones el mismo día del lanzamiento.

Trate la tabla de migración como un entregable, no como un anexo de última hora

Se recomienda que la tabla de migración indique, para cada elemento, la URL antigua, la URL nueva, el tipo de página, el método de tratamiento, la persona responsable y el resultado de las pruebas. En la medida de lo posible, las páginas que se conserven deberían mantener sus rutas originales. Cuando sea necesario cambiarlas, la dirección antigua debe redirigirse de forma permanente con una redirección 301 directamente a la nueva URL más pertinente. Evite las cadenas de redirecciones y no envíe indiscriminadamente a la página de inicio varias páginas antiguas con intenciones distintas.

El documento de requisitos también debe definir las reglas de las URL: cómo se gestionarán las mayúsculas y minúsculas, las barras finales, los parámetros, la paginación y las URL canónicas. Las redirecciones, los enlaces internos, las etiquetas canónicas y el mapa del sitio deben apuntar de forma coherente a las URL de destino. Las páginas eliminadas de forma permanente que no tengan contenido sustituto adecuado pueden devolver un código de estado 404 o 410. La elección concreta debe depender de la forma de mantenimiento real; no es necesario considerar todos los errores 404 como fallos.

En los sitios web de comercio internacional también hay que comprobar por separado las versiones lingüísticas. Las páginas equivalentes en chino, inglés y otros idiomas deben asignarse por separado; no se deben redirigir todas las páginas de producto antiguas a la página de inicio en otro idioma del sitio nuevo. Si se utiliza hreflang, compruebe los códigos de idioma y región, la correspondencia entre páginas y las URL finales. Si una página no tiene una traducción correspondiente, no invente una URL equivalente. Una vez definidas las rutas multilingües, envíelas a los equipos de traducción y desarrollo para que trabajen en paralelo; así se reducirán las revisiones.

Redacte los requisitos técnicos como acciones verificables

La frase «la página debe ser compatible con los motores de búsqueda» no permite verificar la aceptación. El documento de requisitos debe especificar si se puede acceder al contenido y los enlaces importantes, si las páginas devuelven los códigos de estado correctos, si los títulos y las descripciones se pueden editar por página, y quién genera las etiquetas canónicas, los datos estructurados y el mapa del sitio. El entorno de desarrollo debe bloquear el acceso de los motores de búsqueda; al publicar el sitio, hay que retirar uno por uno los bloqueos de acceso, las reglas de robots y las etiquetas noindex que no deban mantenerse.

Una vez aprobados los diseños, también hay que comprobar las páginas reales. Si las especificaciones de los productos, los casos de uso y los puntos de contacto para consultas solo aparecen en imágenes, serán difíciles de consultar para los usuarios y de mantener como contenido. El contenido clave que se carga mediante scripts debe probarse para verificar que los motores de búsqueda puedan obtenerlo. En lugar de limitarse a indicar «carga rápida» como requisito de rendimiento, se pueden seleccionar páginas representativas y entornos de prueba, registrar las métricas web esenciales antes y después del lanzamiento y definir quién se encargará de corregir cualquier incumplimiento.

Si el rediseño implica cambiar el servidor, el dominio o el proveedor de acceso en China continental, también debe incluirse en el calendario la comprobación de los registros regulatorios del sitio. La necesidad de tramitar un registro, modificarlo o cambiar de proveedor de acceso debe confirmarse según las circunstancias del sitio y los requisitos de las autoridades competentes y del proveedor. Las actividades comerciales también deben verificar por separado los requisitos de licencias pertinentes. Si necesita ayuda para organizar la documentación y comprobar el proceso, puede consultar el número de servicio de registro ICP nacional, pero no conviene tratar los plazos de aprobación como una garantía fija de lanzamiento.

Realice la aceptación en dos etapas: revise los riesgos antes del lanzamiento y las señales reales después

Antes del lanzamiento, revise como mínimo la página de inicio, las principales categorías, los productos prioritarios, los artículos de contenido y las plantillas de cada idioma. Compruebe individualmente las páginas con mucho tráfico o muchas consultas, así como las redirecciones clave. La revisión debe abarcar no solo la visualización de las páginas, sino también los códigos de estado, los títulos, las etiquetas canónicas, los enlaces internos, el envío de formularios y la experiencia en dispositivos móviles. Haber superado las pruebas en el entorno de pruebas no sustituye a la verificación en el entorno de producción.

Después del lanzamiento, envíe cuanto antes el mapa del sitio actualizado, compruebe que las URL antiguas importantes se redirijan según la tabla de migración y supervise continuamente el rastreo, la indexación y el rendimiento de la búsqueda orgánica. Conviene acordar de antemano en el documento de requisitos el periodo de seguimiento, la frecuencia de los informes, el procedimiento para escalar incidencias y las condiciones para volver atrás. Por ejemplo, si las páginas principales no están disponibles o el formulario de consultas deja de funcionar, hay que definir quién decide pausar la publicación y quién se encarga de restablecer el sitio. Las fluctuaciones a corto plazo en las posiciones y el tráfico no significan automáticamente que la migración haya fallado, pero tampoco son un motivo para ignorar las anomalías.

No olvide comprobar la cadena de marketing. Es posible que las páginas de destino de anuncios antiguos, los enlaces de redes sociales y de correo electrónico, y los eventos de analítica sigan apuntando a direcciones antiguas. Aunque la redirección funcione, la atribución de los formularios o el seguimiento de las conversiones pueden interrumpirse. En proyectos que integran la creación del sitio, el SEO y la gestión de campañas publicitarias, se puede tomar como referencia el modelo de colaboración de servicios integrales como 易营宝 e incluir la migración de URL, los enlaces de las campañas y el seguimiento de consultas en una misma lista de publicación, en lugar de investigarlos por separado cuando el tráfico ya presente anomalías.

Antes de finalizar el documento de requisitos, conviene pedir al responsable de desarrollo, al responsable de contenidos y al responsable de marketing que confirmen cada uno que el plan se puede ejecutar, quién aportará la información que falte y qué etapas se verán afectadas por los retrasos. En particular, es preferible dedicar más tiempo a revisar la tabla de migración y el plan de reversión durante la fase de diseño que dejar esas decisiones para el día del cambio de dominio.