Reconstrucción de sitio web, sin renunciar al posicionamiento que ya se ganó.

Reconstruir un sitio web es la operación que reemplaza el sistema de abajo. Base tecnológica nueva, enfoque nuevo de gestión de contenido, hosting nuevo, con frecuencia integraciones nuevas, con frecuencia arquitectura de información nueva, más una capa visual rediseñada encima. La capa visual es una de siete cosas que se tocan, no la única.

Las siete cosas que cambia una reconstrucción, aproximadamente en el orden en que afectan el alcance del compromiso: la base de dibujado (de un SaaS de plantillas a un framework moderno, o de un framework a otro), el enfoque de gestión de contenido (de un constructor de páginas a un CMS headless, o de un CMS propietario a uno más flexible), la capa de hosting y de borde, las integraciones de terceros (pagos, agendamiento, CRM, automatización de mercadotecnia), la arquitectura de información (estructura de URL, navegación, jerarquía de páginas), el contenido mismo (reescrituras, consolidación y borrado) y la capa visual.

La referencia más larga sobre qué operación le corresponde a cada problema, y cuándo reconstruir es lo correcto frente a cuándo lo es rediseñar, vive en Rediseño o reconstrucción. Esa página es el punto de partida correcto si todavía no está seguro de qué operación necesita su sitio. Esta página es para el comprador que ya concluyó que reconstruir es lo correcto y quiere entender cómo corre de verdad el compromiso.

La preservación de señal es la parte de la metodología de reconstrucción que las propuestas de proveedor subdimensionan de forma consistente y que las reconstrucciones ejecutadas con descuido reprueban de forma consistente. La diferencia entre una reconstrucción que pierde 5 por ciento del tráfico orgánico y una que pierde 50 por ciento no es la elección del framework, ni la calidad visual, ni el calendario. Es si la reconstrucción se trató como una operación deliberada de preservación de señal o como un proyecto de tirar y volver a empezar.

La metodología tiene seis piezas concretas, y todas corren antes de que cualquier código nuevo llegue a producción.

Primero, documentar cada URL del sitio actual, con su título de página, su meta descripción, su etiqueta canónica, su jerarquía de encabezados y el conteo de palabras del cuerpo. Esa es la línea base. Para sitios de negocios de servicios de menos de quinientas páginas, esto toma uno o dos días. Para sitios más grandes, las herramientas importan más, pero la operación es la misma.

Segundo, identificar las URL que de verdad cargan tráfico orgánico y señal de conversión. Google Search Console más la analítica le dicen qué páginas están haciendo el trabajo. Las páginas de mucho tráfico, las de mucha conversión y las de mucha autoridad (las que reciben más enlaces externos) son el conjunto protegido. Casi todo el esfuerzo de preservación de señal del compromiso se enfoca en esas URL específicas.

Tercero, mapear cada URL vieja a una URL nueva. Casi toda reconstrucción es una oportunidad de limpiar una estructura de URL heredada, pero cada URL vieja necesita una redirección 301 hacia una URL nueva con contenido igual o mejor. Las redirecciones perdidas o rotas son la causa individual más grande del colapso de tráfico posterior a una reconstrucción.

Cuarto, conservar la jerarquía de encabezados y el contenido del cuerpo de las páginas protegidas donde se pueda. La presentación visual puede cambiar; el contenido de abajo rara vez debería encogerse sin una razón deliberada. El sitio nuevo puede ser más conciso en conjunto, pero las páginas de mucho tráfico que cargan la posición orgánica merecen edición cuidadosa y no reescritura completa.

Quinto, correr un despliegue paralelo durante al menos setenta y dos horas antes del cambio. El sitio nuevo vive en una URL de preproducción mientras el sitio viejo sigue sirviendo el tráfico de producción. Valido el dibujado, las redirecciones, las integraciones y la analítica en la URL de preproducción contra cargas reales. El cambio ocurre en una ventana de poco tráfico, con el sitio viejo mantenido en caliente por si hace falta revertir.

Sexto, enviar el sitemap nuevo a Google Search Console en el lanzamiento, monitorear cobertura y dibujado durante los primeros treinta días, y correr un escaneo de Pathlight contra la URL nueva en vivo cada semana durante los primeros noventa días. Los primeros treinta días son cuando aparece la mayor parte de la pérdida de señal; detectarla temprano y parcharla mientras Google todavía está rastreando de nuevo es la diferencia entre una caída de 5 por ciento y un colapso de 50 por ciento.

La base por omisión para reconstruir el sitio de un negocio de servicios es Next.js sobre el App Router, desplegado en Vercel, con un CMS headless cuando el flujo editorial importa y contenido en Markdown cuando no. La referencia más larga sobre lo que le compra esa base es la página de desarrollo en Next.js, que cubre a detalle las decisiones de arquitectura.

Para las reconstrucciones en específico, tres decisiones de base merecen atención explícita. Primera, si la base nueva es headless o completamente a la medida. A la mayoría de los negocios de servicios les sirve mejor un patrón headless (el CMS actual se queda como fuente de contenido y el frontend nuevo dibuja a partir de él), porque el equipo editorial ya está entrenado en el CMS actual y el costo de migración es mucho menor que reemplazar toda la gestión de contenido. La excepción es cuando el CMS actual es en sí mismo la restricción que manda, y en ese caso la reconstrucción incluye migrar el CMS a algo que el equipo de verdad pueda usar.

Segunda, si la reconstrucción incluye una capa de herramientas internas a la medida. Para un negocio de servicios con necesidades internas de administración (inventario, agendamiento, gestión de clientes), la reconstrucción suele ser la ventana correcta para agregar un pequeño nivel de administración a la medida en lugar de seguir suscrito a un SaaS de terceros que no termina de encajar. Si eso cabe en el alcance del compromiso es una decisión de la llamada de descubrimiento.

Tercera, la superficie de integración. Las reconstrucciones suelen estar motivadas por el dolor del techo de integración (la base actual no se pudo integrar con los sistemas de los que el negocio ahora depende). La base nueva debería soportar de forma explícita las integraciones que el negocio ya superó, con el trabajo de integración tratado como alcance de primera clase y no como un añadido posterior. El descubrimiento cubre las integraciones específicas y cómo se ve su implementación.

Una reconstrucción típica para un negocio de servicios corre de diez a catorce semanas desde el arranque hasta el lanzamiento, más una ventana de optimización de treinta días después del lanzamiento. El trabajo se divide en cuatro fases.

Descubrimiento y línea base (una a dos semanas). Se identifica el conjunto de URL protegidas, se documentan las líneas base de rendimiento y de conversión, se dimensiona la superficie de integración, corre la auditoría de contenido y se aprueba la propuesta de arquitectura de información. El entregable es un documento de línea base contra el que corre todo el resto del compromiso.

Arquitectura y diseño (dos a tres semanas). Se elige y se levanta la base nueva, se toma la decisión entre headless y completamente a la medida, se redacta el mapa de redirecciones a partir del inventario de URL, se diseña el sistema visual contra el contenido real y no contra texto de relleno, y se construye de punta a punta la primera plantilla interior como prototipo.

Construcción (cuatro a siete semanas). Las páginas se construyen contra contenido real, las integraciones se conectan y se prueban, el mapa de redirecciones se implementa y se prueba para cada URL vieja, el presupuesto de rendimiento se hace cumplir página por página, y la auditoría de accesibilidad corre de forma continua en lugar de ser una revisión de la semana del lanzamiento.

Lanzamiento (una a dos semanas). El despliegue paralelo corre un mínimo de setenta y dos horas en una URL de preproducción con analítica real y monitoreo de search console. El cambio ocurre en una ventana de poco tráfico. Las primeras setenta y dos horas después del cambio se vigilan de cerca por fallas de redirección, problemas de dibujado o huecos de analítica. Casi todos los problemas que aparecen en los primeros tres días se pueden arreglar antes de que afecten la posición orgánica.

Una reconstrucción exitosa es medible en tres puntos de control.

A treinta días del lanzamiento. La posición orgánica ha perdido menos del cinco por ciento en el conjunto de URL protegidas. Los Core Web Vitals aprueban en al menos el setenta y cinco por ciento de las páginas. La tasa de conversión está a la par de la línea base previa o por encima. Sin fallas de redirección en Google Search Console. La analítica reporta limpio, con el modelo de eventos nuevo mapeado al anterior.

A noventa días del lanzamiento. La posición orgánica se ha recuperado a los niveles previos y empieza a crecer en las URL protegidas. La tasa de conversión ha subido entre diez y treinta por ciento en las páginas de mucho tráfico, porque el sitio nuevo es de forma medible más rápido y la arquitectura de conversión se apretó. El equipo publica actualizaciones de contenido sin un desarrollador, la superficie de integración está sana, y la iguala de mantenimiento está en el nivel previo o por debajo.

A un año del lanzamiento. El sitio está de forma medible por delante de donde lo habría dejado la trayectoria previa a la reconstrucción en cada métrica de negocio que importa: tráfico orgánico, tasa de conversión, calidad de prospectos, costo de mantenimiento y velocidad por cambio. El beneficio acumulado de una reconstrucción limpia se nota más a los doce meses y de ahí en adelante, y por eso la vida útil de una reconstrucción cuidadosa es de cinco a ocho años antes de un rework estructural, en lugar de dos a cuatro años como un rediseño.