Un sitio de veinte años, reconstruido en 18 días sin perder nada

Casi todos los dueños de un sitio web viejo saben que “hay que rehacerlo”. Casi todos también lo posponen, y con razón: una reconstrucción es la forma más fácil de perder lo que el sitio ganó con los años. Cambian las direcciones, desaparecen páginas, cae el tráfico de búsqueda, y el sitio nuevo se ve mejor mientras rinde peor.

Acabamos de terminar una. Un sitio de directorio y reseñas, en línea desde hace más de veinte años, con muchos años de artículos y reseñas en WordPress. Del arranque al sitio nuevo en vivo en su propio dominio pasaron 18 días, y el día del lanzamiento cada dirección vieja respondió según el mapa. La velocidad no era el objetivo. Fue posible por el orden en que se hizo el trabajo, y ese orden es lo que puedes copiar.

Primero la auditoría, con los datos del propio sitio

Antes de hablar de diseño, auditamos el sitio viejo con sus propios datos: la exportación de Search Console, un rastreo completo, la inspección de Google sobre una muestra de direcciones y los sitios que lo enlazan. Salieron cosas que ningún brief de rediseño habría mencionado:

• Google había sacado de golpe las páginas principales de reseñas, meses antes.
• La mayoría de las páginas que ganaban clics no estaban en el sitemap que el sitio le daba a Google.
• Google nunca había visto una buena parte de las direcciones que revisamos.
• Una buena parte de los sitios que lo enlazaban eran spam.
• Nada conectaba el tráfico con lo que el sitio gana.

La auditoría separó los hallazgos verificados de las hipótesis y dejó por escrito lo que no sabíamos. Un diseño nuevo no habría arreglado nada de esto por sí solo. Saberlo antes permitió que la reconstrucción lo arreglara a propósito. Es la misma lógica de las seis preguntas antes de comprar un sitio web: los datos del propio sitio te dicen qué tienes de verdad.

El plan del dueño es la especificación

Después, el dueño escribió su propio plan para el sitio nuevo, en veinte secciones. Nuestra regla fue simple: seguimos su plan sección por sección. Donde nuestros datos no coincidían, anotamos la diferencia como pregunta abierta y su plan quedó en pie. El plan se acordó antes de construir nada.

Esa regla ahorra días. Nadie discute a mitad de obra qué debería ser el sitio, y cada desacuerdo tiene dónde ir. Al lanzar se entregaron 20 de 20 secciones, con una lista que muestra el estado de cada una.

Dimensiona el sitio por la demanda de búsqueda, no por el tráfico viejo

El tráfico de un sitio viejo mide cómo se manejó, no lo que es posible. Por eso la estructura del sitio nuevo se dimensionó con la demanda de búsqueda del mercado: 13.252 búsquedas repartidas en las páginas que nombra el plan del dueño.

Luego una segunda pasada, más lenta: 1.005 búsquedas ordenadas una por una, cada una con una acción y un motivo. Unir a una página que ya cumple el mismo propósito, esperar, descartar, crear una página nueva, crear una herramienta. De ahí salieron 61 páginas nuevas. La mayoría de las filas se unieron a páginas existentes. Las que quedaron en espera eran búsquedas que piden datos que no podíamos respaldar con una fuente ni mantener al día. Antes del lanzamiento, 60 direcciones casi duplicadas se unieron a la página que cumple el mismo propósito, y sus búsquedas se fueron con ellas.

Cada dirección vieja mapeada y verificada en cada build

Cada dirección vieja se clasificó: se queda, se redirige o se elimina. Un script comparaba una copia del sitio nuevo en marcha contra ese mapa en cada build, así que una redirección rota aparecía el mismo día, no un mes después del lanzamiento. Los sitemaps y feeds viejos redirigen a los nuevos, y las imágenes conservan sus direcciones de siempre.

El paso a producción se ensayó con el interruptor real encendido (buscadores permitidos, sitemap declarado, herramientas de vista previa retiradas) antes del cambio de verdad, con un plan escrito para volver atrás. Más sobre este paso en rediseñar sin perder lo que posiciona.

Escribe solo lo que tiene fuente

Escribir rápido es donde las reconstrucciones suelen descuidarse. La nuestra tenía una regla: nunca inventar un dato, una cifra ni un recuerdo. Cada dato sobre una empresa listada sale de las páginas de esa misma empresa, con la fuente y la fecha revisadas. Las páginas que piden datos sin fuente quedaron en espera, no se adivinaron. En la revisión se cortaron las líneas que sonaban a experiencias personales que nadie vivió.

Las páginas están escritas con la voz del dueño, a partir de un perfil hecho con sus propios textos, y un control de voz corre sobre cada página escrita o editada. Las fuentes de las páginas viven como archivos de texto en el repositorio del sitio, para que su equipo pueda editarlas.

Revisa todo, en dos anchos, tres veces

• Cada página vista en ancho de teléfono y de escritorio: sin desbordes, sin imágenes rotas, sin errores del navegador.
• Lighthouse 100 en accesibilidad, buenas prácticas y SEO en la portada y en una página de reseña.
• Tres revisiones: una de limpieza con cuatro revisores, una de correctitud que encontró y corrigió 10 errores, y una de seguridad sin nada explotable.
• El formulario donde una empresa pide aparecer en el directorio, probado de punta a punta: 63 de 63 pruebas pasaron.

Cuando salió un aviso de seguridad crítico para el framework del sitio a mitad de obra, el sitio se pasó a una versión no afectada y quedó en vivo el mismo día.

El lanzamiento es el comienzo del trabajo

Un sitio nuevo empieza a envejecer el día que se lanza. Un sitio web nunca está terminado, así que este tiene un agente de IA de guardia, con un ingeniero que pone las reglas y revisa el trabajo. Sigue una rutina escrita: los cambios en las empresas listadas que tocan el dinero del lector entran en la página ese mismo día, con la fuente; el build rechaza las noticias sin fuente; las guías se actualizan desde una lista de páginas con revisión pendiente; los enlaces y la seguridad se revisan cada semana. Contamos ese tipo de rutina en cómo mantener tu sitio trabajando cada semana.

Antes de empezar tu propia reconstrucción, pregunta

• ¿Qué dicen los datos del propio sitio viejo que está roto hoy, y cuáles de esos hallazgos están verificados?
• ¿El plan de quién es la especificación, y dónde se anotan los desacuerdos?
• ¿Cómo se dimensionó la estructura nueva: con el tráfico viejo o con lo que la gente busca?
• ¿Está mapeada cada dirección vieja, y se verifica el mapa automáticamente en cada build?
• ¿De dónde sale cada dato de las páginas nuevas, y qué pasa cuando no tiene fuente?
• ¿Se ensayó el lanzamiento, y cuál es el camino escrito para volver atrás?
• ¿Quién mantiene el sitio al día después del lanzamiento, y cómo vas a ver lo que hizo?

Un equipo que puede responder esto antes de empezar puede ir rápido sin ser imprudente.