Cómo explicar una auditoría SEO a un cliente sin que se pierda

Estás en una reunión. Has hecho bien tu trabajo: has analizado la web del cliente, tienes el informe delante y sabes exactamente qué hay que arreglar.

Empiezas a explicárselo. Hablas del LCP, de los Core Web Vitals, del JavaScript que bloquea el renderizado.

Y ves cómo asiente con la cabeza mientras se le apagan los ojos.

No es que no le importe. Es que le estás hablando en un idioma que no es el suyo. Y cuando alguien no entiende lo que le cuentas, no te dice "no te entiendo". Te dice "vale, déjame que lo piense".

Ese "déjame que lo piense" es un proyecto que se cae.

El problema no es el análisis, es la traducción

Cualquiera puede pasar una web por PageSpeed Insights. La herramienta es gratis y tarda treinta segundos. Eso no es lo que te contrata un cliente.

Lo que te contrata es que alguien interprete esos datos y le diga qué significan para su negocio.

Y ahí es donde casi todos fallamos, porque hacemos una de estas tres cosas:

Recitamos la lista. Le leemos los 47 avisos que ha sacado la herramienta, en orden, sin priorizar. El cliente sale de la reunión pensando que su web es un desastre irrecuperable.

Usamos la jerga para parecer profesionales. Hay algo de ego en soltar "Largest Contentful Paint" en vez de "cuánto tarda en aparecer lo importante". Suena a que sabes mucho. También suena a que no te vas a tomar la molestia de explicárselo.

Exageramos el impacto. "Estás perdiendo el 50% de tus clientes." ¿Medido dónde? Si no lo has medido en su web, no lo digas. El día que el cliente arregle la velocidad y no duplique sus ventas, habrás perdido su confianza para siempre.

La estructura que funciona: cinco piezas por hallazgo

En seosindrama.com hemos generado 731 auditorías sobre 573 dominios de pymes españolas. Cada hallazgo que sale de ahí tiene siempre la misma estructura, y no es casualidad: es lo que hemos ido afinando hasta que la gente dejó de preguntarnos "¿y esto qué quiere decir?".

1. Un título en lenguaje de negocio, con la evidencia dentro

Mal: "Reduce unused JavaScript".

Bien: "Hay 3.281 KB de código descargado que no se aprovecha".

El título dice qué pasa y cuánto, sin siglas. El número concreto hace dos cosas: da credibilidad y evita que suene a plantilla.

2. Qué supone para el negocio, sin inventar

Aquí está la parte delicada. Tienes que conectar el problema técnico con algo que al cliente le importe, pero sin prometer cifras que no has medido.

La fórmula honesta es separar lo medido de lo estimado:

Descargar código innecesario puede retrasar la aparición del contenido y mantener ocupado el dispositivo durante más tiempo, sobre todo con conexiones o equipos limitados. El ahorro de 6.020 ms es una estimación de Lighthouse, no una mejora garantizada.

Nadie te va a reprochar ser preciso. Sí te van a reprochar haber prometido un 30% más de ventas.

3. Una analogía cotidiana

Esta es la pieza que más nos ha sorprendido por lo bien que funciona. Una imagen de la vida real hace más que tres párrafos de explicación.

Es como transportar una caja enorme para entregar solo unos pocos documentos: el viaje tarda más y se consume más esfuerzo del necesario.

Las tres familias de analogías que mejor funcionan con clientes españoles: la tienda física (el escaparate, la puerta, el cartel), el coche (el mantenimiento, el consumo) y la cocina (los ingredientes, el tiempo de preparación).

Un consejo: ten dos o tres analogías por concepto. Si en el mismo informe repites cuatro veces lo del escaparate, se nota y pierde fuerza.

4. Exactamente tres pasos, empezando por un verbo

Ni uno ni diez. Tres.

Confirma si las tres referencias corresponden al reproductor de YouTube y si todas se necesitan al abrir la página.
Carga el reproductor solo cuando el visitante lo solicite, y retrasa el código que no participa en la primera pantalla.
Repite la auditoría y verifica que disminuyen los 3.281 KB y el tiempo estimado. El primer paso siempre es comprobar, el segundo actuar y el tercero validar. Ese orden evita que alguien toque algo sin saber si era necesario.

5. La nota técnica, aparte

El cliente no la lee. Su desarrollador sí, y te lo va a agradecer.

Ponla en un bloque separado, en dos frases, lista para copiar y pegar en un ticket:

Analiza el bundle con Chrome DevTools Coverage o Lighthouse; aplica carga diferida y división de código. No modifiques el recurso servido por YouTube: controla su inclusión desde la página.

Separar las dos audiencias en el mismo documento es lo que hace que el informe le sirva a los dos.

Prioriza, o no has hecho tu trabajo

Una auditoría que entrega 47 problemas sin ordenar no es una auditoría, es un volcado de datos.

De las 731 webs que hemos analizado, el 81% tiene al menos un hallazgo de prioridad alta. Pero casi ninguna tiene solo uno. Lo habitual es que arrastren varios a la vez, y la diferencia entre un informe útil y uno inútil está en decir cuál se ataca primero.

Tres criterios que puedes usar:

Prioridad	Cuándo
Alta	Afecta a lo que ve el usuario en la primera pantalla, o impide que Google indexe
Media	Degrada la experiencia pero no bloquea nada
Baja	Mejora marginal, o requiere un rediseño para arreglarse

Y algo que conviene decir en voz alta cuando toca: "esto puedes ignorarlo". Un cliente que te oye descartar cosas confía más en lo que sí te parece importante.

El contexto que casi nadie da: la nota no es una nota de colegio

Cuando un cliente ve un 78 sobre 100, lo interpreta como un aprobado raspado y se preocupa.

Conviene explicarle dos cosas.

La primera, que la nota media de las 573 webs de pymes que hemos medido es 78,6. Su 78 no es malo, es exactamente lo normal. El 66% de las webs españolas de pymes están entre 70 y 89.

La segunda, y más incómoda: una web en 78 es más difícil de vender que una en 30. Un 30 se ve, molesta, el dueño ya sabe que algo va mal. Un 78 funciona, se ve bien, carga aceptablemente… y va perdiendo visitantes en silencio sin que nadie lo note nunca.

Ahí está el trabajo de verdad: explicarle a alguien que su web no está rota, pero que rinde por debajo de lo que podría.

"A mí me carga rápido"

Te lo van a decir. Casi siempre.

Y tendrán razón: en su móvil carga en un segundo, porque su navegador lleva meses guardando la web en memoria.

No discutas. Pídele que abra una ventana de incógnito, desde un dispositivo donde no entre nunca, y que lo pruebe él mismo delante de ti.

Cuando lo ve con sus ojos, la conversación deja de ser tu palabra contra la suya. Es su propia web enseñándole el problema, y eso vale más que cualquier gráfico que le lleves.

Qué hemos aprendido midiendo 573 webs

Si tuviéramos que resumir la traducción de una auditoría en una frase: el cliente no paga por entender SEO, paga por sentir que tú lo entiendes y se lo explicas como a una persona.

El resto son detalles de ejecución. Pero son los detalles que separan un informe que se lee de uno que acaba en una carpeta.

Si quieres los datos completos de qué falla y en qué proporción en las webs de pymes españolas, están publicados y actualizados: el 75% tiene un problema de velocidad, el 44% arrastra JavaScript sin usar y el 34% tiene fallos de accesibilidad. Puedes leer más sobre por qué las webs van lentas y sobre qué debería incluir una auditoría SEO.

Hemos publicado el prompt que hace esta traducción

Todo lo que acabas de leer no es teoría: es la estructura que usa nuestra herramienta para redactar cada hallazgo, afinada durante seis meses contra webs reales.

Lo hemos publicado en GitHub, gratis y con licencia MIT, como una skill para agentes de IA. Funciona en Claude Code, Codex y Cursor.

Le pegas el aviso de PageSpeed que te ha salido, le dices para quién es, y te devuelve el hallazgo con las cinco piezas de este artículo.

Ver seosindrama-skills en GitHub →

Si lo pruebas y falla, abre un issue. Para eso está publicado.

Explicar bien no es simplificar de más. Es quitar todo lo que sobra hasta que solo queda lo que la otra persona necesita para decidir.