El mismo fallo técnico te hunde el SEO y te encarece el PPC

Un servidor lento no te penaliza una vez. Te penaliza dos:

1. Pierdes capacidad para posicionar en orgánico (SEO/GEO).

2. Pagas más caro cada clic en paid (PPC/SEM). Misma causa, dos facturas distintas y dos equipos confusos que no saben cómo relacionar conceptos.

Esto va para los dos bandos:

1. SEO, para que sepas que tu trabajo técnico también le baja el coste a paid.

2. PPC, para que sepas qué pedirle a SEO antes de echarle la culpa al copy. Quizá ya lo sepas. Pero entenderlo te hace más valioso en cualquiera de los dos canales, justifica mejor tu trabajo en equipo y, en general, te hace mejor profesional. Y mejor persona, ya te pones.

Cuando lanzas una campaña de paid sobre una landing que no muestra elementos de conversión en menos de 3 segundos, no estás comprando clics útiles: estás pagando un extra y perdiendo conversiones en un escenario mejorable. Y esa misma landing lenta le está diciendo a Googlebot que tu sitio responde tarde.

Google lo tiene en cuenta por partida doble. La experiencia de página forma parte del cálculo de Ad Rank en paid y los Core Web Vitals son señal de página en orgánico: los mismos números, el mismo dataset de CrUX, alimentando las dos subastas.

Un Quality Score bajo no siempre es un problema de copy, de extensiones de anuncio o de CTR. Muchas veces es un servidor lento, una fuente tipográfica que bloquea el renderizado o una cadena de redirecciones que añade 400 milisegundos que nadie ha visto porque nadie ha mirado en ese sitio.

Y, en el mercado en el que estamos, cada segundo vale dinero. Mucho, de hecho.

Si el equipo SEO (o de desarrollo) no lo detecta, el paid lo paga en la subasta. El cliente los recibe como dos problemas distintos de dos equipos distintos.

Esa división de la responsabilidad es el error fatal que lleva todo al garete.

He participado en proyectos donde el equipo de SEO llevaba semanas reescribiendo metadescripciones y ajustando estructura de encabezados mientras el equipo de paid tenía CPCs por encima de lo normal sin explicación aparente.

“Everything is fine”, ¿eh?

Cuando revisamos las landing pages de paid, el LCP estaba por encima de 3 segundos en móvil. Nadie en paid lo había medido porque “eso es territorio de SEO”. Nadie en SEO lo había comunicado porque, para ese proyecto en concreto, “las landing pages de paid no entran en el crawl habitual” y “los pagaclicks pueden pagar para salir mejor”.

Dos equipos trabajando en paralelo. Ninguno mirando al mismo dato. El cliente pagando el coste de esa desconexión en dos líneas diferentes de los costes de marketing que deberían verse en el mismo lugar.

Compartir

Por desgracia, esto no es un caso aislado. Es la organización habitual cuando PPC y SEO son equipos distintos que facturan por separado.

El incentivo para coordinar la revisión técnica de la infraestructura compartida, sencillamente, no existe en la mayoría de estructuras de agencia o departamento de marketing.

Nadie tiene ese incentivo porque nadie “posee” la infraestructura. Y lo que nadie posee nadie lo revisa.

La lista es más larga de lo que parece a primera vista:

• El tiempo de respuesta del servidor afecta al presupuesto de crawl de Googlebot y al tiempo que espera el usuario que llega desde un anuncio. Si el TTFB (Time to First Byte, el tiempo hasta la primera respuesta del servidor) es alto, los dos canales sufren de forma distinta, pero con un impacto serio en las cifras de conversión.

• Las cadenas de redirección en URLs de paid añaden una latencia que puede ser medida. Muchas landing pages heredan redirecciones de migraciones antiguas que el equipo de SEO conoce pero que el equipo de paid no ha revisado nunca porque asume que la URL final es limpia.

• Los scripts de terceros en la landing (analytics adicionales, heatmaps, widgets de soporte) bloquean el renderizado e inflan el INP. Nadie los audita de forma conjunta. El resultado es un desastre prevenible: un formulario que tarda en responder en dispositivos medios, una tasa de conversión baja y un atributo de culpa que el equipo de paid asigna al copy cuando el problema está en el orden de carga de los scripts.

• La configuración de CDN y caché puede romper la personalización de paid. Si la caché es demasiado agresiva y no excluye las URLs con parámetros UTM, el usuario que llega desde un anuncio ve contenido obsoleto o incorrecto. Difícil de detectar si nadie cruza el rendimiento de caché con la conversión de paid.

• Y una caché mal planteada distorsiona lo que cada equipo mide: SEO ve tiempos correctos porque el bot recibe la versión cacheada, mientras el usuario real que llega del anuncio se come la carga completa sin caché porque el gclid o el fbcid hacen que la caché no sepa bien qué hacer. Mismo sitio, dos lecturas opuestas, cada equipo defendiendo su dato.

• El setup de GA4 y GTM es compartido. Un tag mal configurado que duplica eventos de conversión afecta a los datos de paid tanto como a los de orgánico. Y en muchos proyectos ese setup lo montó alguien que ya no trabaja en la empresa y que documentó lo justo. O nada, posiblemente.

Compartir

Cada uno de estos puntos tiene su responsable habitual en el equipo. El problema es que no hay una revisión conjunta que los cubra antes de que el daño sea visible en los resultados.

El coste de tener una infraestructura deficiente no aparece en ni una sola de las líneas de informe de SEO o PPC.

Sin embargo, es un coste que se reparte y que la persona responsable del proyecto conoce bien. O debería. Lo tiene presente al leer el informe financiero y al decidir el presupuesto de PPC (y, de tanto en tanto, el de SEO).

Rankings más bajos de lo esperado en orgánico, CPCs más altos de lo óptimo en paid y tasas de conversión peores para todo el tráfico, pagado y no pagado. Todo saliendo de la misma causa que nadie revisa.

Es más cómodo así. Si el paid tiene ROAS positivo, nadie pregunta si podría ser un 20% mejor con una revisión de rendimiento técnico.

Si el SEO avanza trimestre a trimestre, nadie calcula qué parte del potencial se pierde porque el servidor tarda en responder o porque las landing pages de conversión tienen un script que bloquea el hilo principal.

El dato que falta en la mayoría de proyectos no es el coste de arreglar la infraestructura. Es el coste de oportunidad de no arreglarla. Son cosas distintas y conviene tratarlas como tal en una reunión. Y no una de SEO y otra de PPC, sino en una de SEO, PPC y alguien de infraestructura.

No hace falta fusionar los equipos de SEO y PPC ni crear un nuevo rol de “responsable de infraestructura técnica cross-channel”. Lo que hace falta es acordar unos mínimos de revisión conjunta sobre la base que los dos comparten.

• Cualquier tipo de landing nuevo debe pasar por un check de WPO antes de activar la campaña. Core Web Vitals (LCP, INP, CLS) y un repaso básico de la cadena de redirecciones. Son diez minutos que pueden evitar semanas con el Quality Score bajo y los CPCs inflados.

• Las alertas de rendimiento del servidor deberían llegar también al equipo de paid, no solo al de SEO. Si el TTFB sube porque hay un problema de caché o de servidor, el equipo que tiene dinero corriendo en ese momento necesita saberlo ese día, no cuando el SEO haga el informe mensual.

• El audit de tracking (GA4/GTM) debe pasar una revisión de ambos equipos antes de activar campañas nuevas. Los eventos de conversión son demasiado críticos para vivir en el silo de un solo canal.

Ninguno de estos tres puntos requiere un proceso nuevo ni complejo, solo compartir trabajo, pasarse acciones y ser un poquito voluntarioso.

Requiere reconocer que la infraestructura técnica no es territorio de un equipo concreto. Es la base que los dos pisan.

Mientras eso no entre en la forma habitual de trabajar, los presupuestos de paid seguirán pagando un sobrecoste silencioso por problemas que el SEO técnico lleva meses viendo pero que nunca llegan a la reunión donde está el cliente y la persona que gestiona las campañas.

Aprovecho para dejaros un vídeo en el que colaboro con Performance Observer para tratar el gran problema de los tiempos de respuesta del servidor: