La deuda técnica que no ves venir cuando escalás un sitio con landings por país

Duplicar una landing parece lo más rápido. Spoiler: no lo es.

Hubo un momento en ese proyecto donde todo parecía bajo control.

Arquitectura clara. Una landing por cada combinación de país, servicio y demanda del usuario. Sobre el papel, impecable. En producción, fue donde empezamos a levantar la guardia.

La decisión operativa fue la de siempre: duplicar la landing anterior y modificar lo que cambia. País, estado, algunos textos del cuerpo. El CMS lo permite. Es rápido. Y en las primeras iteraciones funciona bien. Demasiado bien, de hecho, como para sospechar que algo estaba saliendo mal.

Lo que no vimos fue lo que pasa cuando el sitio escala de verdad. Nuevos países, nuevos servicios, nuevas demandas del usuario. Lo que alguna vez fue una arquitectura limpia se convierte en una red de páginas clonadas donde el origen de cada dato se vuelve imposible de rastrear. El SEO deja de ser un problema de keywords. Pasa a ser uno de arquitectura. Y las señales de alerta, cuando aparecen, ya tienen semanas de antigüedad en producción.

El error que se esconde en los datos heredados

El caso que mejor ilustra esto lo encontré en una revisión de rutina.

Habíamos duplicado una landing de Perú para crear la versión de Uruguay. Rápido: copiar, pegar, cambiar los textos visibles. Pero el título SEO —el que Google lee en el <title> de la página— había quedado con "desde Perú" en lugar de "desde Uruguay".

La página estaba publicada. Indexada. Compitiendo en resultados de búsqueda con un dato incorrecto en el campo más importante para el posicionamiento.

Eso no es un descuido puntual. Es un error estructural.

Las implementaciones de CMS basadas en templates son, por diseño, propensas a heredar metadata. Sin un proceso de personalización explícita, cada página nueva hereda el mismo patrón de title tag o descripción del original. En sitios multi-regionales, eso tiene consecuencias directas sobre el targeting geográfico: una página pensada para Uruguay puede terminar compitiendo contra las de Perú si comparten metadata similar o idéntica.

Y así nos dimos cuenta que el problema no es el CMS, sino la ausencia de proceso.

Fácil culpar a la herramienta. Pero el problema no era la plataforma ni el addon de SEO que usábamos.

El problema era que no teníamos un paso de verificación entre "duplicar la página" y "publicar la página". Ese espacio vacío es donde vive la deuda técnica. Silenciosa, acumulándose, hasta que alguien la encuentra por casualidad.

Por qué la deuda se descubre tarde y cuesta más corregirla

Con cinco landings, el error de Perú-Uruguay lo encontrábamos en diez minutos revisando manualmente. Pero cuando llegamos a la revisión con 44 páginas publicadas, la conversación cambió completamente de tono.

La deuda técnica SEO funciona exactamente como la deuda financiera. En pequeñas cantidades es manejable, casi invisible. Pero se acumula con interés. Cada página nueva que se publica sin verificación es un potencial error que se suma al stack. Y cuando el stack tiene 44 páginas, ya no podés resolverlo con una revisión rápida. Necesitás un proceso de auditoría, una exportación de datos, una corrección en bulk, y tiempo que no estaba presupuestado.

Lo que más me impactó de esa experiencia fue esto: el error no dolía cuando ocurrió. Dolía semanas después, cuando alguien lo encontró por casualidad. Esa es la característica más peligrosa de la deuda técnica en proyectos de escala. Los síntomas aparecen lejos del momento en que se tomó la decisión que los causó.

El efecto compuesto que nadie anticipa

A medida que se agregan páginas, las ineficiencias no se suman. Se multiplican.

Una arquitectura de URLs inconsistente afecta el rastreo. Los meta tags heredados generan señales contradictorias para Google. Los enlaces internos que apuntan a versiones viejas de páginas diluyen la autoridad. Cada problema técnico no resuelto crea las condiciones para que el siguiente sea más difícil de diagnosticar.

Muchos equipos ignoran este impacto hasta que los rankings caen. Y cuando caen, la corrección es considerablemente más costosa que si se hubiera prevenido desde el origen.

Cómo una fórmula en planilla puede prevenir buena parte del problema

La solución que implementamos no fue sofisticada. Fue, en retrospectiva, obvia.

Pero requirió que el problema fuera lo suficientemente doloroso para que nadie lo cuestionara.

Agregamos una columna de "Title SEO" en la planilla de control del proyecto y la alimentamos con una fórmula de concatenación automática. La lógica era simple: el title de cada página debía ser el H1 de esa página más el sufijo de la marca, separados por un pipe.

=CONCATENATE(D2," | Nombre de Marca")

Con esta fórmula aplicada a toda la columna, cualquier error en el nombre de la página quedaba inmediatamente visible. Si alguien había duplicado la landing de Perú y olvidado cambiar el H1 a "Uruguay", la columna de title mostraba "[Service name] en [Páis] para [necesidad del usuario] | Marca" en la fila correspondiente a Uruguay. El error era evidente antes de publicar. Sin necesidad de revisar cada URL manualmente en el CMS.

TEXTJOIN para escalar la misma lógica a meta descriptions

Para las meta descriptions usamos una variante con TEXTJOIN que permitía combinar el primer párrafo de contenido con el nombre de la página de forma más flexible. La función permite escalar contenido programáticamente para páginas de ubicación o por país, manteniendo la coherencia del patrón sin trabajo manual.

Lo más valioso de este enfoque no es la fórmula en sí. Es que fuerza a que los datos correctos existan en un lugar centralizado antes de que lleguen al CMS. La planilla se convierte en la fuente de verdad. El CMS pasa a ser el destino final de datos ya verificados.

Ese orden importa, e importa mucho.

El proceso de revisión que implementamos antes de publicar cada tanda

Después de esta experiencia, establecimos un checklist mínimo que se aplica antes de publicar cualquier tanda de landings nuevas. No es un documento extenso. Es un proceso que tarda menos de veinte minutos por tanda y que evita horas de corrección posterior.

Checklist de QA SEO para landings duplicadas

Verificación de datos de origen:

• El nombre de la página no contiene referencias al país o estado desde donde se duplicó
• El H1 corresponde exactamente a la combinación país-estado de la página actual
• El title SEO en la planilla refleja el H1 correcto antes de ser cargado al CMS

Verificación de metadata:

• El title SEO no supera los 60 caracteres
• La meta description no contiene datos del país de origen
• No existen duplicados exactos de title entre páginas del mismo sitio

Verificación de enlaces internos:

• Los enlaces en el cuerpo de la página apuntan a URLs con el país correcto en la ruta
• Los enlaces del footer y menú son consistentes con la versión de la landing que se está publicando

Aprobación antes del lanzamiento:

• Ninguna tanda de páginas se publica sin que un segundo par de ojos haya revisado la columna de titles en la planilla

La planilla deja de ser un documento de seguimiento. Pasa a ser un mapa de control activo.

Ese fue el cambio más importante en nuestra forma de trabajar.

Cualquier miembro del equipo puede ver en tiempo real qué páginas están listas para publicar, cuáles tienen datos pendientes de verificar, y cuáles fueron aprobadas. Sin ese sistema compartido, los errores reaparecen más rápido de lo que cualquier auditoría puede detectarlos.

El problema no es la velocidad de publicación. Es la ausencia de un punto de control entre la velocidad y la producción.

El costo real de escalar sin procesos

Hay una frase que escucho seguido en proyectos de este tipo: "lo arreglamos después".

Entiendo la lógica. Cuando hay presión por publicar, cuando el cliente espera resultados, cuando el equipo ya está al límite, la corrección futura parece un costo razonable.

No lo es 😔.

Cada atajo que se toma en la fase de publicación reduce lo que la plataforma puede llegar a ser. Cada workaround apresurado incrementa el esfuerzo necesario para escalar o integrar funcionalidad nueva. La deuda SEO que no se resuelve no desaparece: genera overhead de mantenimiento, consume tiempo de auditoría, y desplaza el foco de iniciativas de mayor valor.

En nuestro caso, el tiempo que invertimos en corregir los errores de las 44 páginas fue significativamente mayor que el tiempo que nos hubiera llevado implementar el proceso de verificación desde el principio. La diferencia no era técnica. Era de planificación.

Lo que me llevé de esta experiencia

Escalar un sitio con landings por país y estado es un problema de arquitectura antes de ser un problema de contenido. Y los problemas de arquitectura no se resuelven con auditorías. Se previenen con procesos.

Estos son los aprendizajes que me quedaron:

1. La planilla de control es parte del trabajo SEO, no un extra. Si no tenés una fuente de verdad centralizada antes de publicar, el CMS va a heredar errores que después vas a tener que rastrear página por página.

2. El error no duele cuando ocurre. Duele cuando escala. Por eso el momento de implementar el proceso de verificación es antes de la primera publicación, no después de encontrar el primer error.

3. Automatizar los titles desde la planilla es la intervención de menor esfuerzo con mayor impacto. Una fórmula de concatenación tarda cinco minutos en configurarse y evita horas de corrección manual.

4. La velocidad de publicación sin proceso no es una ventaja competitiva. Es deuda que se va a cobrar con interés en la siguiente auditoría.

5. El checklist de QA SEO tiene que ser parte del flujo de trabajo, no una revisión opcional. Si depende de la buena voluntad del equipo en momentos de presión, no va a funcionar cuando más se necesita.

La planificación del proceso de duplicación no es burocracia. Es la diferencia entre un sitio que escala limpio y uno que escala roto.