andresmentor.com: el sitio que Google ve como una página de espera
Este caso es distinto a los otros tres, y por eso está aquí. El contenido del sitio es bueno y
funciona: con JavaScript activo, la web carga completa, con su blog, su
bootcamp y sus testimonios. El problema es que ningún rastreador llega a verlo.
Un desafío anti-bots devuelve HTTP 200 —no 403— con una página de verificación
de 12 KB en las seis URLs probadas, incluidos robots.txt y
sitemap.xml. Puntuación global: 32 sobre 100.
Contexto y punto de partida
Andrés Arboleda es mentor de oratoria y comunicación: prepara a directivos y profesionales para hablar en público. Su web carga bien, el diseño funciona y el contenido está donde tiene que estar. Un análisis rápido desde el navegador no encontraría nada grave, y ese es exactamente el peligro de este caso.
La auditoría se hizo rastreando con el User-Agent de Googlebot y sin ejecutar JavaScript,
que es como llega la mayoría de los rastreadores y prácticamente todos los motores
generativos. El resultado fue el mismo en las seis URLs probadas: HTTP 200,
12 KB, y una página con el texto «One moment, please… Please wait while
your request is being verified». Ninguna página real. Ningún robots.txt.
Ningún sitemap.xml.
- Dominio
- andresmentor.com
- Muestra
- 6 URLs + robots.txt + sitemap.xml
- Método
- Rastreo HTTP con UA Googlebot + renderizado con JS
- Puntuación global
- 32 sobre 100 · 5 áreas medidas × 10
- Hallazgos
- 11 · 3 P0, 4 P1, 4 P2
- Áreas no medidas
- Rendimiento y Mobile (cuota de PageSpeed agotada)
Todas las cifras de esta página proceden del informe incrustado más abajo. El propio documento declara que está «preparado para revisión y publicación», a diferencia de otros informes del bloque que llevan nota de confidencialidad. El informe indica como fecha de auditoría el 19 de octubre de 2026 y la hoJa de evidencia técnica encabeza con otra fecha; lo señalamos en la nota de más abajo en lugar de elegir una.
El informe original, consultable aquí
Se abre dentro de la página, con sus cinco hojas navegables —resumen, hallazgos y soluciones, plan de acción, evidencia técnica y monitoreo— y también se puede descargar. Es el archivo que se entregó, no un resumen.
El visor lee el archivo original y lo pinta en el navegador: no es una captura ni una reconstrucción. Cada pestaña es una hoja del libro entregado, con las columnas del auditor, la evidencia medida y el comando de verificación de cada arreglo.
- Hojas
- 5 (incluye monitoreo)
- Hallazgos
- 11, priorizados P0 a P2
- URLs probadas
- 6 + robots.txt + sitemap.xml
- Formato
- XLSX · 25 KB
Dos precisiones sobre el documento. Primera: la hoja «Resumen» fecha la auditoría el 19 de octubre de 2026 y la cabecera de «Evidencia Técnica» dice 19-02-2026. Los datos internos son coherentes entre sí —mismas URLs, mismos tamaños, mismos TTFB—, así que la discrepancia es de transcripción de fecha, no de contenido; preferimos dejarlo escrito a elegir una. Segunda: las áreas de Rendimiento y Mobile aparecen como N/A porque la API de PageSpeed Insights devolvió «Quota exceeded». Se excluyen del promedio, y por eso la puntuación global se calcula sobre cinco áreas y no sobre ocho.
Puntuación por área
Ocho áreas, de las que cinco se pudieron medir. La escala aquí es de 0 a 10 por área, y la puntuación global es el promedio de las áreas medidas multiplicado por diez.
- Rastreo
- 1de 10 · desafío anti-bots
- Indexabilidad
- 3de 10 · metadatos invisibles
- Datos estructurados
- 2de 10 · sin JSON-LD
- Estructura de URLs
- 4de 10 · www sin redirigir
- Seguridad
- 6de 10 · sin HSTS
- Rendimiento (CWV)
- N/Acuota de PSI agotada
- Mobile
- N/Ano verifiable tras el bloqueo
- Internacional
- OKmonolingüe, sin hreflang
Fuente: hoja «Resumen». El promedio de las cinco áreas medidas (1, 3, 2, 4, 6) es 3,2, y multiplicado por diez da los 32 puntos de la puntuación global. El informe lo explica así: «Las áreas N/A se excluyen del promedio. Un puntaje bajo se explica casi por completo por el bloqueo anti-bots».
El hallazgo que explica los demás
Once hallazgos, pero solo uno es la causa. Los otros diez o son consecuencia del bloqueo o son deuda técnica que no se puede ni verificar mientras el bloqueo siga ahí. Esto importa porque cambia el orden del trabajo: si se empieza por los datos estructurados, se está arreglando algo que ningún rastreador puede leer.
| Grupo | Hallazgos | Se puede arreglar ya | Motivo |
|---|---|---|---|
| El bloqueo | F-01, F-02, F-03 | Sí, y es lo primero | Desactivar el reto anti-bots o abrir una allowlist para Googlebot y Bingbot. Treinta minutos de trabajo que desbloquean todo lo demás. |
| Consecuencia directa | F-07 | Solo después | Título, meta description, canonical y Open Graph no se pueden auditar porque el HTML que llega es el del desafío. Primero se abre el acceso, después se audita. |
| Deuda independiente | F-04, F-05, F-06 | Sí, en paralelo | Redirección de www al dominio principal, HSTS y cabeceras de seguridad se arreglan sin tocar el bloqueo. |
| Requiere desbloqueo previo | F-08, F-09, F-10, F-11 | Bloqueado | Datos estructurados, barras finales, atributo de idioma y Core Web Vitals no se pueden verificar en un sitio que devuelve otra página. |
El informe lo resume con una frase que merece repetirse: el arreglo F-01 «desbloquea de golpe el rastreo, el sitemap, los metadatos y la medición de CWV — es la tarea con mayor retorno por minuto invertido de todo el plan». Con veinticuatro horas de retraso en ese clic, cualquier otro trabajo del plan es tiempo perdido.
Los 11 hallazgos, por prioridad
Tres P0 —bloquean la indexación—, cuatro P1 —limitan el rendimiento— y cuatro P2 —higiene y mejora continua. Esta es la tabla completa con la evidencia medida y el esfuerzo de cada corrección.
| ID | Prioridad | Área | Hallazgo y evidencia medida | Esfuerzo |
|---|---|---|---|---|
| F-01 | P0 | Rastreo | Un desafío anti-bots basado en JavaScript reemplaza el contenido real de todas las URLs, incluso con User-Agent de Googlebot. Las 6 URLs probadas devolvieron HTTP 200 con una página de verificación de 12 KB. | 30 min |
| F-02 | P0 | Rastreo | robots.txt no es accesible: devuelve el HTML del desafío en lugar de las directivas Disallow/Allow. |
15 min |
| F-03 | P0 | Rastreo | sitemap.xml no es accesible: devuelve el desafío en lugar de XML válido. Sin sitemap, el descubrimiento de posts nuevos se detiene. |
15 min |
| F-04 | P1 | URLs | El subdominio www responde HTTP 200 directamente, sin redirigir al dominio principal. Dos hosts que responden 200 dividen las señales de ranking. |
30 min |
| F-05 | P1 | Seguridad | La cabecera HSTS (Strict-Transport-Security) no está configurada. Permite el primer acceso por HTTP sin forzarlo. | 15 min |
| F-06 | P1 | Seguridad | Faltan X-Content-Type-Options, X-Frame-Options y Referrer-Policy: exposición a MIME-sniffing, clickjacking y fuga de referrer. |
30 min |
| F-07 | P1 | Indexabilidad | Los metadatos no se pueden auditar porque el HTML que reciben los rastreadores es el del desafío: sin JS, 0 meta description, 0 canonical, 0 og:*, 0 JSON-LD y sin H1. |
2-3 h |
| F-08 | P2 | Datos estructurados | Ningún bloque JSON-LD detectable. Se pierden resultados enriquecidos y señales E-E-A-T en un nicho de formación y autoridad personal. | 3-4 h |
| F-09 | P2 | URLs | Las URLs sin barra final responden 200 sin redirigir a su versión canónica con barra. Versiones duplicadas compitiendo entre sí. | 1 h |
| F-10 | P2 | Idioma | El HTML servido sin JS declara lang="en" (el del desafío) mientras el contenido es 100 % español. No se pudo confirmar lang="es" en las páginas reales. |
30 min |
| F-11 | P2 | Rendimiento | Core Web Vitals sin medir por cuota de PSI. Las imágenes de la home se sirven a 1024 px de ancho, posible peso excesivo en móvil. El sitio envía cache-control: no-store. |
4-6 h |
Evidencia técnica recogida
Lo que hace verificable este informe no es la lista de hallazgos, sino la hoja de evidencia: cada prueba tiene su método, su código de respuesta y el tamaño de lo que se recibió. Esto es lo que se puede reproducir desde un terminal cualquiera.
| URL probada | Método | HTTP | Tamaño | Resultado observado |
|---|---|---|---|---|
/ |
curl + UA Googlebot | 200 | 12,0 KB | Página del desafío anti-bots, no el sitio |
/blog/ |
curl + UA Googlebot | 200 | 12,1 KB | Página del desafío anti-bots |
/blog/como-hablar-en-publico-sin-tartamudear/ |
curl + UA Googlebot | 200 | 12,1 KB | Página del desafío anti-bots |
/entrenamientos-para-hablar-en-publico/ |
curl + UA Googlebot | 200 | 12,0 KB | Página del desafío anti-bots |
/robots.txt |
curl | 200 | 12,0 KB | HTML del desafío en lugar de robots.txt |
/sitemap.xml |
curl | 200 | 12,0 KB | HTML del desafío en lugar de XML |
/ con JavaScript |
rastreo con render JS | — | — | El sitio carga completo: contenido, blog, bootcamp y testimonios |
Cabeceras de respuesta
- server: cloudflare — CDN delante del origen.
- content-type: text/html — correcto.
- cache-control:
private, no-cache, no-store, must-revalidate, max-age=0— deshabilita toda caché. - Strict-Transport-Security: ausente.
- X-Content-Type-Options / X-Frame-Options / Referrer-Policy: ausentes.
Redirecciones y tiempos
- http → https: 301 correcto. Bien
- www → apex: 200 directo, sin redirección. Mal
- TTFB (3 mediciones): 0,20 s / 0,40 s / 0,18 s. Excelente, aunque medido sobre la página del desafío.
- PageSpeed Insights API: «Quota exceeded». Sin línea base de LCP, INP ni CLS.
Fuente: hoja «Evidencia Técnica», secciones A (URLs probadas), B (cabeceras), C (redirecciones y tiempos) y D (fragmento del desafío servido). El TTFB se midió sobre la página de verificación, no sobre el sitio real: es un dato válido del servidor y no una medida del rendimiento del contenido.
Plan de reparación por fases
El informe agrupa las once acciones en tres fases con un responsable y un criterio de verificación por cada una. No es una lista de deseos: es una ruta con una prueba al final de cada paso.
-
Fase 1 · Hoy (crítico)
Desactivar el desafío anti-bots o crear una allowlist para Googlebot, Googlebot-Image, Bingbot y los servicios de Google verificables por rDNS. Después, comprobar que
robots.txtdevuelvetext/plaincon la línea Sitemap, y reenviar el sitemap en Search Console. Criterio de verificación: un curl con UA de Googlebot devuelve el HTML real, y la inspección de URL en GSC muestra el contenido. Treinta más quince más quince minutos. -
Fase 2 · Esta semana
Redirección 301 permanente de
wwwal dominio principal, HSTS en Cloudflare, y las tres cabeceras de seguridad que faltan. En paralelo, auditar título, meta description y canonical por plantilla una vez que el acceso esté abierto. Criterio de verificación:curl -sIsobre www devuelve 301 con Location al apex, y securityheaders.com califica A o superior. -
Fase 3 · 30 días
Datos estructurados —
Organization,Person,Article,FAQPage,BreadcrumbList—, redirección de las URLs sin barra final, confirmación delang="es"en todas las plantillas y medición de Core Web Vitals con PSI. Criterio de verificación: Rich Results Test sin errores, y PSI móvil con LCP, INP y CLS en verde.
Fuente: hoja «Plan de Acción». Los esfuerzos indicados —30 min, 15 min, 2-3 h, 4-6 h— son los que declara el informe, no una estimación nuestra.
Cómo se vigila después
Un bloqueo de este tipo puede volver: lo activa un plugin, una regla del WAF o una actualización del hosting. Por eso el informe incluye ocho controles con umbral de alerta, y el primero es diario durante dos semanas.
| Control | Frecuencia | Herramienta | Umbral de alerta |
|---|---|---|---|
| Accesibilidad de robots.txt | Diaria · 2 semanas | curl con UA Googlebot + GSC | Debe devolver text/plain, no el desafío |
| Indexación | Semanal | Search Console → Cobertura | Caída superior al 10 % semana a semana |
| Estado del sitemap | Semanal · 1 mes | Search Console → Sitemaps | Estado distinto de «Correcto» |
| Rastreo de URLs nuevas | Semanal | GSC Inspección de URL | «Recuperación fallida» |
| Core Web Vitals | Mensual | PageSpeed Insights / CrUX | LCP ≥ 2,5 s · INP ≥ 200 ms · CLS ≥ 0,1 |
| Cabeceras de seguridad | Mensual | securityheaders.com | Calificación inferior a A |
| Redirección www y barra final | Mensual | curl -sI | Respuesta distinta de 301 |
| Datos estructurados | Mensual | Rich Results Test + GSC | Errores nuevos de schema |
Fuente: hoja «Monitoreo». Los umbrales son los que declara el documento. Este bloque es lo que separa un informe de una lista de problemas: define qué se mira, cada cuánto y a partir de qué valor hay que actuar.
Preguntas frecuentes
Porque un 403 se ve. Cuando el servidor responde 403, el rastreador registra un error, Search Console lo notifica y alguien se entera. Cuando responde 200 con una página de verificación, el rastreador cree que ha recibido el sitio correctamente: no hay error, no hay alerta, y lo que indexa es una página de espera. El bloqueo es silencioso y puede pasar meses sin que nadie lo detecte, mientras las impresiones caen sin explicación aparente y se busca la causa en el contenido, que está bien.
El contenido no se pierde, pero deja de ser accesible para quien no ejecuta JavaScript. En esta auditoría se comprobó que con JavaScript activo el sitio carga completo, con su blog, su bootcamp y sus testimonios. El problema es que el desafío se resuelve ejecutando JavaScript, y un modelo de lenguaje o un rastreador que no lo ejecuta solo recibe la página de espera. El contenido existe y no se puede leer: eso es distinto de no tener contenido, y el arreglo también es distinto —aquí no hay que escribir nada nuevo, hay que abrir la puerta—.
Porque la API de PageSpeed Insights devolvió «Quota exceeded» durante la sesión de rastreo y el informe lo declara en lugar de estimar. Las áreas de Rendimiento y Mobile quedan marcadas como N/A y se excluyen del promedio, que se calcula solo sobre las cinco áreas que sí se pudieron medir. Es la regla que aplicamos siempre: cuando una fuente no está disponible, se escribe, no se rellena con una aproximación. Un N/A honesto vale más que un número inventado que después alguien usa para tomar decisiones.
No. Esta página muestra el diagnóstico y el plan de reparación priorizado, con la fecha de cada medición. Cualquier cifra de mejora exigiría una medición posterior con su propia fecha y fuente, y no la tenemos. El informe sí incluye el criterio de verificación de cada arreglo —qué comando ejecutar y qué debe devolver—, que es lo que convierte el plan en algo comprobable en lugar de una promesa. Cuando exista esa segunda medición, irá en esta misma página.
Servicio y método relacionados
Este caso corresponde al servicio de auditoría SEO técnica. El detalle de las comprobaciones está en el checklist técnico, y el mismo dominio tiene un caso hermano sobre su perfil de enlaces en autoridad de andresmentor.com: dos diagnósticos distintos sobre el mismo sitio, que se leen juntos.
¿Tu web carga bien pero no aparece en Google?
Comprobamos qué ve un rastreador cuando pide tu página sin ejecutar JavaScript. Es la primera prueba de la auditoría gratuita, y la que más bloqueos silenciosos descubre.