En ROXEX Labs tenemos una regla para todo lo que publicamos: en la web no aparece ningún dato que no podamos señalar. Ni recuentos de clientes, ni porcentajes de satisfacción, ni testimonios, ni métricas de rendimiento, ni ahorros, si detrás no hay un registro, un informe guardado y fechado o una fuente pública enlazada. Este build log cuenta qué tuvimos que quitar de nuestra propia web para cumplirla, cómo funciona la comprobación automática que impide que esas frases vuelvan y qué parte depende todavía de una decisión humana.
Una aclaración antes de empezar: aquí no reproducimos las cifras que retiramos. Si las copiáramos como ejemplo, volverían a estar publicadas y alguien, persona o buscador, las tomaría por buenas. Describimos qué tipo de afirmación era, dónde estaba y por qué salió.
La regla, escrita donde se edita
La regla no está en un documento aparte que nadie abre: está en la cabecera de los archivos de los que sale el contenido. La de src/data/projects.ts, de donde salen el portfolio y los casos de estudio, dice tres cosas:
- •Sin métricas inventadas. Notas de Lighthouse, LCP, peso del JavaScript, plazos o resultados de negocio solo aparecen con una medición guardada y fechada.
- •Clientes sin resultados ni alcance hasta que el fundador los confirme por escrito.
- •Casos de estudio solo de primera mano: cada frase tiene que poder señalarse en el código, en un documento del repositorio o en la web pública del producto.
La versión corta, la que abre el propio detector, cabe en una línea: nada de estadísticas, recuentos de clientes, garantías, rankings ni testimonios sin respaldo.
Tenemos tres motivos, por orden de importancia:
- •Es lo honesto. Somos un estudio pequeño dirigido por su fundador. Si decimos algo sobre nuestro trabajo, quien nos contrata tiene que poder comprobarlo.
- •Es un riesgo legal. La Directiva (UE) 2019/2161 añadió a la lista de prácticas comerciales desleales enviar o encargar reseñas o recomendaciones de consumidores falsas, y en España se incorporó con el Real Decreto-ley 24/2021. Esto no es asesoramiento jurídico, pero basta para no jugar con testimonios.
- •Es lo que piden los buscadores. Las guías de Google sobre contenido útil y fiable preguntan si la información se presenta de forma que inspire confianza, con fuentes claras. Y sus directrices de fragmentos de reseñas no admiten las valoraciones que una empresa publica sobre sí misma en su propia web.
Qué quitamos
La revisión fue manual y página a página: leer cada afirmación y buscar de dónde salía. Si salía de nuestro código, de un informe guardado o de una fuente pública que dice exactamente eso, se quedaba. Si no, se quitaba o se reescribía. Estas son las categorías que encontramos, con ejemplos que ya no están en la web.
Testimonios de relleno
La portada tenía una sección de testimonios con tres citas firmadas con nombre, cargo y empresa. Eran textos de relleno (placeholders) que nunca se sustituyeron por citas reales. Ahora las dos listas, en español y en inglés, están vacías, y la sección no se pinta mientras lo estén. Para que vuelva, cada cita tiene que ser de un cliente real que haya dado permiso por escrito, con su nombre, su cargo y la cifra tal como la dijo.
Recuentos de clientes y presencia que nadie había contado
Un mapa marcaba clientes repartidos de Madrid a A Coruña, con un contador de ciudades y otro de presencia internacional. Ninguna lista de clientes lo respaldaba. Ahora el mapa enseña lo que es verdad: la base en Murcia y el trabajo en remoto, en español e inglés. En la misma línea cayeron un porcentaje de clientes que repiten y un titular del portfolio que hablaba de tráfico real y clientes reales en proyectos de los que no tenemos datos de tráfico publicados, dos de ellos productos propios.
Ahorros, retornos y productividad sin datos
Fue la categoría más grande, porque es la más tentadora en una web que vende automatización con IA:
- •La guía de automatización tenía una sección de retornos con tres casos con números (una tienda online, una asesoría y una agencia) cuyos ahorros no salían de datos de ningún cliente, y una tabla con una columna de retorno estimado sin supuestos detrás.
- •Las páginas de nuestros agentes de IA mostraban horas ahorradas por semana, el puesto y el salario que «reemplazaban» y una estimación de minutos de configuración que nadie había medido.
- •Un recurso gratuito decía que multiplicaba la productividad y que estaba probado en clientes reales.
- •Una comparativa de antes y después se presentaba como caso real, con cifras exactas.
Lo que hicimos en cada caso: los casos sin datos se borraron, y la guía explica ahora cómo calcular el retorno con tus propias cifras. La comparativa sigue, pero se presenta como ejemplo ilustrativo y sin cifras. La calculadora de ahorro de la portada enseña su fórmula y sus supuestos, dice que es una estimación y no un resultado medido, y el coste del proyecto y la cuota mensual opcional se mueven dentro de las horquillas publicadas en precios, en lugar de usar un número propio. Y en la calculadora de ROI de un chatbot, el dato sobre la velocidad de respuesta a un lead se cita con su estudio original, de Harvard Business Review, enlazado.
Métricas de rendimiento sin informe
El caso de estudio de Renzy, nuestra app de nutrición con IA, publicaba una nota de Lighthouse, un LCP móvil, un peso de JavaScript y un plazo de desarrollo en semanas. No había ningún informe fechado detrás de ninguno. Salieron todos y el caso se reescribió leyendo el repositorio de la app: arquitectura, decisiones y límites, sin cifras de precisión, latencia ni coste, porque sus evaluaciones internas no están revisadas para publicarse.
La regla vale también para nuestra propia web: las cifras del build log de rendimiento salen de los informes JSON de Lighthouse que guardamos, con el método explicado, las condiciones de cada tabla y las trampas de medición incluidas.
Promesas y estados que no estaban confirmados
Algunas frases no eran cifras, sino compromisos: un plan firmado en un número fijo de días, sprints semanales, una demo cada viernes, una propuesta en un plazo concreto. Puede que algún día sean ciertas, pero hoy dependen de una decisión que no está tomada, así que se quitaron de las páginas donde aparecían. Donde existe un plazo que sí está publicado, como el de la primera respuesta en contacto, se usa ese. Queda una excepción: /proceso todavía indica una propuesta en 3-5 días y sprints de 2 semanas, y esos dos plazos siguen pendientes de que el propietario los confirme.
En la misma limpieza cayeron un indicador decorativo de versión y estado «online» sin página de estado detrás, un contador de plazas de lanzamiento que nadie llevaba, un precio de lanzamiento que ya había terminado, una frase sobre herramientas «que usamos internamente» sin registro de ese uso y un enlace al supuesto código abierto del simulador del Mundial que devolvía un 404: el repositorio no es público, así que el enlace no vuelve hasta que lo sea.
Casos y fuentes inventados en el blog
Los artículos principales del blog se reescribieron entre el 28 de junio y el 1 de julio de 2026: fuentes enlazadas, preguntas frecuentes y casos inventados eliminados. Unos recursos descargables por sector incluían listas de «sanciones reales» que no lo eran; de todas ellas solo encontramos un expediente real de la AEPD, que ahora se cita con su número. El 8 de noviembre de 2026 se quitaron además de tres artículos unas horquillas de coste, tiempos de desarrollo y plazos de medición sin fuente. Cuando añadimos una fuente, la abrimos y comprobamos que dice lo que citamos.
Datos estructurados
Los datos estructurados de la web (el JSON-LD que leen los buscadores) no llevan valoraciones agregadas ni reseñas. Un comentario en el código deja escrita la condición para añadirlas: solo con reseñas reales del perfil de empresa en Google, copiadas el día en que se publiquen. Nunca estimadas.
Cómo evitamos que vuelva
Un comentario donde estaba la afirmación
Cada vez que quitamos algo dejamos un comentario en el mismo sitio del código: qué decía, por qué salió y qué haría falta para que vuelva. En la sección de testimonios, por ejemplo, el comentario explica que las citas eran de ejemplo, que inventarlas es una práctica desleal según la normativa de consumo y que la sección no se pinta mientras la lista esté vacía. Así, quien edite ese archivo más adelante, nosotros incluidos, no repone la frase pensando que se perdió por error.
El detector: scripts/check-claims.mjs
Revisar a mano no basta, porque el texto de una web sale de muchos sitios: componentes, ficheros de datos, artículos en markdown, metadatos. Por eso el detector no mira el código fuente, sino el resultado: recorre la carpeta out/ que genera la build estática y lee cada página HTML tal como se va a publicar.
De cada página toma el título y la meta descripción, que son lo que aparece en los resultados de búsqueda, y el texto visible: quita los scripts, los estilos y la cabecera, decodifica las entidades HTML y normaliza los espacios. Sobre ese texto busca diez patrones, escritos a partir de las fórmulas que ya habíamos usado para afirmaciones sin respaldo: recuentos redondos con un signo de más, porcentajes casi perfectos, recuentos de clientes, presencia internacional, crecimientos multiplicados y superlativos de ranking o de popularidad. Los patrones de números descartan una cifra precedida de otro dígito, de un separador o de un símbolo de moneda, para que un precio no cuente como un recuento.
Además revisa el HTML en bruto, JSON-LD incluido, en busca de tres marcas: clases o identificadores de testimonios, el tipo Review de schema.org y valoraciones agregadas sin una lista de reseñas detrás.
Cada coincidencia se guarda con el patrón, la ruta, el texto encontrado y unos 70 caracteres de contexto a cada lado. Si alguna no está cubierta por la lista de excepciones, el script termina con código de error. Con --json saca el informe completo. Forma parte de npm run verify, la cadena de comprobaciones que pasamos antes de publicar y que se detiene en el primer fallo.
La lista de excepciones
No toda coincidencia es una afirmación inventada. Un artículo que advierte contra las agencias que prometen el primer puesto en Google usa justo la fórmula que el detector busca, y lo hace para desmentirla. Lo mismo pasa con expresiones editoriales del tipo «el error principal» escritas con un ordinal, con una herramienta de terceros descrita como la más usada o con la página del Mundial, donde el modelo dio una probabilidad altísima a una selección que acabó cayendo: es la salida publicada del modelo, y la página la presenta como un fallo.
Para esos casos está scripts/claims-allowlist.json. Cada entrada tiene esta forma:
json{ "id": "<patrón>", "route": "/blog/<artículo>", "text": "<frase exacta>", "reason": "<por qué no es una afirmación sin respaldo>" }
Y una coincidencia solo se perdona si encaja en las tres cosas a la vez, patrón, ruta y frase:
jsconst isAllowed = (f) => allow.some( (a) => (a.id === "*" || a.id === f.id) && routeMatches(a.route, f.route) && (!a.text || f.context.toLowerCase().includes(String(a.text).toLowerCase())), );
La lista tiene hoy 36 entradas, cada una con su motivo, y la última revisión completa está fechada el 8 de noviembre de 2026. Las normas de uso están en scripts/README-audits.md: entradas estrechas, una frase en una ruta, y nunca una entrada para silenciar una afirmación sin respaldo. Si algo no tiene respaldo, se cambia el texto. Un detalle práctico de trabajar en Windows: el script quita la marca BOM del archivo antes de leerlo, porque PowerShell 5.1 la añade cuando lo reescribe y el JSON dejaría de ser válido.
Lo que el detector no hace
Conviene ser claros con sus límites, porque un detector que pasa en verde da una tranquilidad que no siempre merece:
- •No sabe si un número es verdad. Solo frena las fórmulas que ya conocemos. Un porcentaje inventado escrito con otra cifra, o un recuento redactado de otra manera, pasa sin problema.
- •Solo lee el HTML exportado. Los textos que llegan con JavaScript, como la versión en inglés de los artículos, que se sirve en un archivo JSON aparte, no los revisa.
- •Las excepciones cuestan. Cada coincidencia legítima exige escribir una entrada con su motivo, y una lista que crece sin control acabaría sirviendo para silenciar. Por eso las entradas son estrechas y se revisan.
- •No sustituye la revisión. Es una red de seguridad para que no vuelva lo que ya quitamos, no una forma de saber si lo nuevo es cierto.
Lo que depende todavía del fundador
Hay afirmaciones que ningún script puede desbloquear, porque necesitan un dato o una decisión que solo tiene quien dirige el estudio:
- •Clientes. Los proyectos de clientes aparecen sin resultados ni alcance del trabajo hasta que se confirmen por escrito. En uno de ellos falta confirmar incluso si es cliente o producto propio, y por eso la web no le pone etiqueta.
- •Testimonios. Solo con permiso por escrito de cada cliente.
- •Plazos y ritmo de trabajo. /proceso todavía indica una propuesta en 3-5 días y sprints de 2 semanas. Esos plazos siguen pendientes de que el propietario los confirme o los retire.
- •Valoraciones. Solo con reseñas reales del perfil de empresa en Google.
- •Fechas. La fecha de publicación del caso de Renzy usa, mientras no se confirme otra, la fecha demostrable en el historial del repositorio.
- •Compromisos de seguridad y privacidad. La página de seguridad solo recopila compromisos ya publicados en otras páginas y deja como «en preparación» lo que espera una acción del fundador.
- •Datos de campo. No tenemos datos de usuarios reales de Chrome sobre la velocidad de roxex.es, así que no afirmamos nada sobre ellos.
Qué nos llevamos al trabajo con clientes
La forma de trabajar se traslada tal cual a cualquier proyecto: decidir qué cuenta como prueba antes de escribir el texto, dejar escrito de dónde sale cada cifra y poner una comprobación automática al lado de cada regla que importa. Es lo que hacemos en nuestros casos de estudio, incluido el de nuestra propia web, y en el build log del simulador del Mundial 2026, donde cada cifra sale del script y de sus datos. Si quieres saber quién está detrás, está en nosotros. Y si tu web o tu producto necesitan una revisión parecida, cuéntanoslo.
Preguntas frecuentes
¿Por qué no enseñáis las cifras que quitasteis? Porque copiarlas, aunque sea como ejemplo, las vuelve a publicar. Un buscador o un lector que llegue a mitad del artículo puede quedarse con el número y no con el contexto.
¿Por qué no hay testimonios en la web? Porque solo publicamos citas de clientes reales con su permiso por escrito. Mientras no las tengamos, la sección no aparece.
¿El detector sirve para cualquier web? La idea sí: revisar el HTML final y no el código fuente, y obligar a justificar cada excepción. La lista de patrones no, porque recoge las fórmulas que nosotros habíamos usado. Otra web necesita la suya.
¿Cómo sé que las cifras que sí publicáis son reales? Cada una dice de dónde sale. Las de rendimiento llevan el método y la fecha de la medición; las del simulador del Mundial salen de un JSON fechado que se puede volver a generar con la misma semilla; y cada caso de estudio incluye una nota sobre qué se leyó para escribirlo.
Fuentes
- •EUR-Lex — Directiva (UE) 2019/2161 del Parlamento Europeo y del Consejo, de 27 de noviembre de 2019. https://eur-lex.europa.eu/eli/dir/2019/2161/oj
- •BOE — Real Decreto-ley 24/2021, de 2 de noviembre. https://www.boe.es/buscar/act.php?id=BOE-A-2021-17910
- •Google Search Central — Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- •Google Search Central — Review snippet (Review, AggregateRating) structured data. https://developers.google.com/search/docs/appearance/structured-data/review-snippet