Poner un popup sin que Google lo renderice

Autor: Carlos Sánchez

Temática: Rastreo Renderizado

Publicado: 2026-11-04

Revisado: 2026-11-04

Índice mostrar

Es posible que en algún momento de nuestro trabajo como SEOs nos veamos enfrentados a tener que lidiar con un pedazo de Pop up que ocupe toda la pantalla.

Ya sea porque lo pida legal (cookies, verificación de edad), se necesite por marketing (newsletter, descuento) o directamente sea una decisión de cliente que no tengamos ni por qué entender.

Pero surge una cuestión que todo SEO se ha planteado alguna vez. ¿Qué hacemos con ese anuncio gigante que me está ocupando toda la pantalla?

Cuando tenemos que lidiar con un POP UP así, es normal que nos preguntemos cómo nos puede afectar a Google y si Google al no hacer click en ningún elemento, podrá leer el contenido con normalidad.

Es normal hacerse esta pregunta y pienso resolverla en este artículo. Para ello comencemos definiendo los términos correctos, y tras etiquetarlos y diferenciarlos, podremos resolverlo.

A este tipo de anuncio se le bautizó como "intersicial", que en realidad es un término médico para definir lo que ocupa el especio entre las células de un tejido. Creo que quien lo definió se quedó agusto para poder avisar de lo molesto que es este tipo de anuncio.

Los anuncios intersticiales y los diálogos intrusivos son elementos de página que obstruyen la vista del contenido por parte de los usuarios, generalmente con fines promocionales. — Documentación de Google

Con los popups hay dos problemas distintos y conviene no mezclarlos.

Uno es de calidad: desde 2017 Google tiene en cuenta los intersticiales intrusivos en móvil.
El otro es de renderizado: Googlebot ejecuta JavaScript, así que si el popup se inyecta con JS también se lo come, y lo que tape o lo que cambie en el DOM es lo que Google indexa.

John Mueller contestó en Reddit a una pregunta sobre esto y dio una solución que ya se usaba para otras cosas: dejar el popup fuera del renderizado con el robots.txt. Vamos a verla, con sus límites, y a ver cuándo es mejor no necesitarla.

Tipos de Pop Ups

La documentación de intersticiales intrusivos es corta y es clara. Lo que Google no quiere es un aviso que tape toda la página nada más llegar desde el buscador, ni que te redirija a una página de consentimiento.

Como en todo hay excepciones, que serían las siguientes:

Los avisos obligados por ley: cookies, verificación de edad. Aun así recomienda superponerlos al contenido, no sustituirlo.
Los de inicio de sesión cuando el contenido es de pago o privado.
Banners que ocupan una parte razonable de la pantalla y dejan el contenido accesible.

Si tu popup entra en esta lista, no deberías tener un problema de intersticiales (en principio). Aunque por muy eficiente que sea Google, siempre puede tener equivocaciones, por eso mi recomendación es que sea del tipo de Pop Up que sea, apliques lo que comentaré a continuación

Por si no es solo con los pop ups, tengo un artículo que habla en profundidad los anuncios en la compatibilidad con móviles.

Popup fuera del renderizado con robots.txt

En r/TechSEO han hecho una pregunta muy concreta:

Una web con un popup de verificación de edad obligatorio, servido desde otro dominio e insertado en la página mediante una API.
¿Sirve un Disallow en el robots.txt de ese dominio para que Google no renderice el popup?

La respuesta de John Mu: «That would generally work». Si el dominio del popup bloquea el rastreo en su robots.txt, Googlebot no pide ese recurso al renderizar y el popup no existe para él. Añadió que «así funcionan muchos servicios de anuncios».

Además dió la alternativa: si el popup lo carga un fichero JavaScript concreto de tu web, puedes bloquear ese fichero en tu propio robots.txt.

Con dos avisos que son la mitad de la respuesta:

«You need to make sure that your pages still load when those URLs are not fetched.»
«If you only have one JS file that does a bunch of things, I wouldn't do that.»

Es decir: la página tiene que funcionar sin ese recurso, y el fichero que bloquees tiene que hacer solo eso.

Si el PopUp y el JS de dicho popup viene de otro dominio, tu no tienes el control sobre él, entonces dependerá de la configuración en el robots.txt que tenga este tercero.

Si el JS viene de tu dominio puede ser internal o external. Si es internal deberías moverlo a un archivo a parte, y si es external debes comprobar que SOLO se carga ahí el JS de tu popup. Si es el caso (si no, siempre puedes solucionarlo), siempre lo puedes bloquear con el robots.txt.

User-agent: Googlebot
Disallow: /js/popup-verificacion.js

Me veo en la obligación de hacer unas recomendaciones globales para evitar malentendidos si no estás acostumbrado a utilizar el robots.txt bien:

1. Los grupos del robots.txt no se suman. Google aplica un solo grupo por rastreador, el más específico. Si ya tienes un grupo User-agent: * con sus reglas y añades uno para Googlebot, Googlebot deja de leer el grupo * y se queda solo con el suyo. Hay que repetir ahí todo lo que ya tuvieras:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

User-agent: Googlebot
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /js/popup-verificacion.js

Si no te importa que el resto de bots tampoco carguen el popup (lo normal), es más limpio meter la línea en el grupo * y no abrir uno nuevo.

2. Cuidado con la versión en la URL. Los parámetros son super útiles, y ayudan a evitar tener problemas con la caché /js/popup-verificacion.js?ver=1.4.

Cuidado con terminar la regla en $, ya que haría que nada de lo escrito a continuación pudiese funcionar:

(Disallow: /js/popup-verificacion.js$)

3. Verificación de edad con contenido bloqueado detrás o muros de pago. Si el aviso no solo tapa, sino que impide que se vea el contenido que hay detrás y no se carga esa función en el js, no sirve de nada lo que hayamos hecho.

Si necesitas por medio de ese Pop Up restringir el contenido a los usuarios por diversos motivos (edad, subscripción, etc) te enseño a hacerlo en SEO en contenido no accesible para todos los usuarios.

4. Servir HTML distinto según el user-agent. No es del todo recomendable, ya que en algunos casos podría ser considerado como cloaking. Google recibe el mismo HTML que todos y decide, por una regla pública, no pedir un recurso.

No siempre es necesario bloquear por robots.txt

Se puede hacer el Pop Up sin necesidad de bloquearlo por el robots.txt (al menos si cumple estas características)

El contenido va en el HTML del servidor y el popup se superpone con JavaScript después. Nunca sustituye al contenido ni lo deja fuera del DOM.
En móvil es un banner, no una capa a pantalla completa. Y se puede cerrar.
No redirige a una página de consentimiento.
Se carga diferido, sin empujar el contenido (CLS) y sin ponerse delante del elemento más grande de la pantalla.

No obstante, no siempre es posible cumplir con todo eso, si realmente queremos un Pop Up que ocupe toda la pantalla.

Igualmente si quieres un ejemplo, mi aviso de cookies cumple todo esto y te enseño como hacerlo aquí: añadir un pop-up de cookies sin plugins.

Y como Googlebot no hace clic en nada, el aviso de cookies ni le va ni le viene: ve el contenido que hay debajo. Más sobre lo que ejecuta y lo que no en la guía del renderizado en Google.

Cómo comprobarlo antes de subirlo

Pasa la URL del script por el probador de robots.txt con el user-agent Googlebot. Así ves que la regla hace lo que crees y no bloquea nada más.
En Search Console, Inspección de URL → «Probar URL publicada» → «Ver página probada». Tienes la captura, el HTML renderizado y, en «Más información», la lista de recursos que Google no ha podido cargar.
En la captura debe salir el contenido y no el popup, que en el HTML renderizado esté todo el texto, y que en los recursos bloqueados aparezca solo tu fichero del popup. Si hay algo más en esa lista, revisa.

La prueba en vivo pide el fichero en el momento, así que ves el efecto de la regla al instante. La versión indexada tardará lo que tarde Google en volver a renderizar la página.

Veamos unos ejemplos

Ya que he empezado a poner de ejemplo a Saucony que tiene un pop up intersticial, va a ser el primero de la prueba.

En este caso Saucony pasaría la prueba

Skechers tiene otro pop up, pero parece tardar más que el renderizado para salir el popup, no es la solución más elegante y aún así parece poder tener algunos problemillas de renderizado a los que se les podría sacar punta.

Mientras que Visionlab en este caso no lo tiene restringido de ninguna forma

En su caso además se ha podido salvar en parte gracias a tener un máximo con una medida pseudo absoluta (va condicionada al tamaño de la fuente, pero al menos no al porcentaje de la página), si no, le podría haber arruinado el renderizado por completo.