TL;DR: En un casino online, la mayor parte del tráfico orgánico se pierde antes de escribir una línea de contenido. Los cinco fallos técnicos más caros son: un geobloqueo que también bloquea a Googlebot, un lobby que solo existe después de ejecutar JavaScript, miles de fichas de juego casi iguales, filtros que generan URLs infinitas y un hreflang mal montado entre mercados. Todos se diagnostican con Search Console y un rastreo propio, y casi todos se arreglan sin tocar el diseño.
Una plataforma de casino se parece más a una tienda online grande que a una web corporativa: cientos o miles de juegos, filtros por proveedor y tipo, páginas de bonos que cambian cada semana y versiones por país. Esa escala es la que convierte el SEO técnico en la primera fase de cualquier proyecto de SEO para casinos. Este artículo repasa los fallos que encontramos una y otra vez en auditorías, en el orden en que suelen costar dinero.
¿Por qué el geobloqueo puede sacar a un casino de Google?
Porque Googlebot rastrea sobre todo desde Estados Unidos. La propia guía de Google sobre páginas adaptadas a la configuración regional dice que las direcciones IP predeterminadas del robot «parecen proceder de Estados Unidos» y que el rastreador envía las peticiones sin cabecera `Accept-Language`.
Un casino con licencia en Perú o España está obligado a restringir el acceso a jugadores de otros países, y es habitual que bloquee Estados Unidos entero. Si ese bloqueo se aplica a todas las páginas, Googlebot recibe la pantalla de «no disponible en tu país» y eso es lo que indexa.
Google es claro en que no hay trato especial: al robot hay que tratarlo como a cualquier usuario del país desde el que parece llegar. La salida no es dejarle pasar a escondidas, que sería *cloaking*, sino separar dos capas:
- Las páginas informativas (qué juegos hay, reglas, bonos con sus condiciones, métodos de pago, juego responsable) se sirven a todos, sin sesión y sin juego real.
- El registro, el depósito y el juego con dinero se bloquean por país como exige la licencia.
Cómo encaja esto con cada regulador lo decide el equipo legal del operador. La parte técnica es comprobar con la herramienta de inspección de URLs de Search Console qué ve realmente Google en cada plantilla.
¿Qué pasa si el lobby del casino está hecho en JavaScript?
Que Google puede verlo, pero tarde y no siempre entero. La guía de conceptos básicos de SEO en JavaScript explica que Google procesa las páginas en tres fases (rastreo, renderizado e indexación) y que el renderizado puede quedar en cola.
En un casino el problema típico es un lobby que carga los juegos desde una API cuando el navegador ya abrió la página. El HTML servido está vacío: sin nombres de juego, sin enlaces a las fichas, a veces sin un solo título. Googlebot tiene que renderizar para descubrir cada ficha, y un rastreador que no ejecute JavaScript no ve nada.
La comprobación es sencilla: abre el código fuente de la página (no el inspector) y busca el nombre de un juego. Si no aparece, el contenido depende del JavaScript. Las soluciones, de menos a más trabajo:
- Prerenderizar el lobby y las fichas en el servidor, de forma que el HTML ya traiga textos y enlaces.
- Servir al menos una lista enlazada de juegos y proveedores en el HTML, aunque la interfaz rica siga cargándose después.
- Usar enlaces `<a href>` reales. Los botones que navegan con un evento de clic no son enlaces para un rastreador.
¿Cómo se evita que miles de fichas de juego parezcan contenido duplicado?
Dando a cada ficha indexable algo que no tenga ninguna otra, y quitando del índice las que no lo tienen. Una tragamonedas publicada por veinte casinos con la misma descripción del proveedor es la misma página veinte veces. Google elige una y el resto se queda en «Descubierta: actualmente sin indexar» o «Rastreada: actualmente sin indexar» en Search Console.
Lo que diferencia una ficha:
| Elemento | Ficha débil | Ficha que se gana el índice |
|---|---|---|
| Descripción | Texto del proveedor copiado | Texto propio con cómo se juega y para quién es |
| Datos | Ninguno o solo el nombre | RTP publicado por el proveedor, volatilidad, apuesta mínima y máxima en el casino |
| Enlaces | Botón «Jugar» | Proveedor, juegos parecidos, bonos aplicables, guía relacionada |
| Condiciones | Ausentes | Si el juego cuenta para el rollover y en qué porcentaje |
| Estado | Juegos retirados que siguen publicados | Redirección o `410` cuando el juego sale del catálogo |
No todas las fichas tienen que indexarse. En catálogos de miles de juegos, lo razonable es priorizar los juegos con demanda de búsqueda real, darles contenido propio y dejar el resto con `noindex` o fuera del sitemap hasta que lo merezcan. Cuando dos URLs muestran el mismo juego (por ejemplo, versión demo y versión real), la guía de URLs duplicadas explica cómo indicar cuál es la canónica.
¿Qué hacer con los filtros de juegos y el presupuesto de rastreo?
Los filtros por proveedor, tipo de juego, volatilidad o funciones generan combinaciones casi infinitas de URLs. Google tiene una guía específica sobre navegación por facetas que recomienda, cuando esas URLs no tienen que aparecer en búsquedas, impedir su rastreo con `robots.txt` o usar fragmentos de URL (`#`) en lugar de parámetros.
El criterio que aplicamos: una combinación de filtro solo merece URL indexable si responde a una búsqueda real. «Tragamonedas de Pragmatic Play» puede serlo; «tragamonedas de Pragmatic Play, volatilidad alta, con compra de bono, ordenadas por novedad» no.
Sobre el presupuesto de rastreo, Google aclara en su guía para sitios grandes que está pensada para sitios de más de un millón de páginas que cambian cada semana, o de más de 10.000 páginas que cambian a diario. Un casino con filtros abiertos llega a esas cifras sin darse cuenta, aunque su catálogo real sea de mil juegos. Por eso el problema rara vez es «Google no me rastrea lo suficiente» y casi siempre es «Google pierde el tiempo en URLs que no deberían existir».
¿Cómo se monta el hreflang de un casino con varios mercados?
Con una URL por mercado, todas enlazadas entre sí de forma recíproca. La guía de versiones localizadas de Google pide que cada versión declare a todas las demás, incluida ella misma, y que los códigos sean de idioma y, si hace falta, de región (`es-PE`, `es-ES`, `es-MX`).
En casino hay una complicación que no existe en otros sectores: las versiones por país no son traducciones, son productos distintos. El catálogo de juegos, los bonos, los métodos de pago y los textos legales cambian por licencia. Eso obliga a revisar tres cosas:
- Que cada versión tenga contenido adaptado de verdad. Tres páginas en español idénticas salvo la moneda compiten entre sí.
- Que el hreflang solo empareje páginas equivalentes. Si un juego no está disponible en México, la ficha peruana no debe declarar una alternativa mexicana que no existe.
- Que las redirecciones por país no rompan el hreflang: si `es-ES` redirige según la IP, Googlebot desde Estados Unidos nunca ve la versión española.
¿Qué señales de cumplimiento tienen que estar en el HTML?
Las mismas que revisan las plataformas publicitarias: licencia visible con su número o resolución, control de edad, enlaces de juego responsable y términos de los bonos. Google pide la licencia local para certificar a un operador en su política de juegos de azar, y entre los motivos de rechazo más frecuentes están las páginas de destino que no muestran esas señales.
Para el SEO importan por otra razón: son parte de lo que hace fiable una página de casino. Si están dentro de una imagen o solo aparecen al abrir un modal, para un rastreador no existen. Van en texto, en el HTML servido, en todas las plantillas. En Perú, además, el artículo 26.18 de la Ley 31557 modificada obliga a verificar identidad, edad y nacionalidad en el registro; el detalle del mercado peruano está en SEO para casinos en Perú.
¿Por dónde empezar una auditoría técnica de casino?
Por Search Console, antes que por cualquier herramienta de pago. El informe de indexación de páginas dice cuántas URLs conoce Google y por qué deja fuera las que deja fuera, y la inspección de URLs enseña el HTML que ve el robot. Con eso y un rastreo propio de la web se cubre la mayor parte del diagnóstico.
El orden que seguimos en el servicio de SEO para casinos online: acceso del robot por país, HTML servido de lobby y fichas, duplicados y canónicas, filtros y sitemap, hreflang y, al final, velocidad. La velocidad importa, pero rara vez es lo que tiene a un casino fuera del top 10. Con la base técnica resuelta, el trabajo pasa a elegir qué páginas atacar (investigación de palabras clave) y a reforzarlas con link building. Si vas a encargar la auditoría fuera, las comprobaciones para elegir proveedor están en mejores agencias de SEO para casinos.
Preguntas frecuentes
¿Google indexa casinos online?
Sí. Google no tiene una política que excluya del buscador orgánico a los casinos con licencia. Las restricciones por país y la certificación obligatoria aplican a los anuncios, no a los resultados orgánicos. Lo que sí aplica a todos son las políticas de spam.
¿Es cloaking dejar pasar a Googlebot cuando el país está bloqueado?
Si Googlebot recibe contenido que un usuario de su mismo país no puede ver, sí. Google pide tratar al robot como a cualquier usuario del país desde el que parece llegar. La solución correcta es que las páginas informativas estén abiertas y que el bloqueo se aplique al registro y al juego con dinero.
¿Hay que indexar todas las fichas de juego?
No. Conviene indexar las que tienen demanda de búsqueda y contenido propio. Las demás pueden quedar fuera del índice sin perjuicio, y eso ayuda a que Google se concentre en las que sí pueden posicionar.
¿Qué hago con un juego que sale del catálogo?
Si hay un juego equivalente del mismo proveedor, redirige la ficha con un 301. Si no lo hay, devuelve un 410 o un 404. Mantener publicada la ficha de un juego que ya no se puede jugar frustra al usuario y desperdicia rastreo.
¿La velocidad de carga importa en un casino?
Importa para la experiencia y para la conversión, sobre todo en móvil. Pero en las auditorías que hacemos casi nunca es la causa principal de que un casino no posicione: los problemas de acceso, renderizado y duplicados pesan mucho más.