Cuando una regla parece correcta pero no funciona, revisamos el alcance antes que la sintaxis. Robots.txt se aplica al origen: protocolo, host y puerto.
Separamos cada origen
https://example.com/robots.txt
https://www.example.com/robots.txt
https://shop.example.com/robots.txt
http://example.com/robots.txt
https://example.com:8443/robots.txt
No asumimos herencia entre ellos. Un archivo del dominio raíz no controla automáticamente un subdominio.
Hacemos un inventario de hosts
Anotamos producción, www, tienda, documentación, previews y staging. Abrimos /robots.txt en cada host. Esto suele revelar archivos antiguos, 404 o plataformas diferentes.
Identificamos quién sirve el archivo
El apex puede estar en Next.js y la tienda en Shopify. También puede intervenir un CDN o reverse proxy. Antes de editar, confirmamos qué sistema genera la respuesta pública.
Probamos la URL en su propio host
Una URL de shop.example.com se prueba contra la política de ese host. Usamos el tester y revisamos la regla ganadora.
Staging no se protege con Disallow
Para contenido privado usamos autenticación o controles de acceso reales. Disallow: / es una señal de rastreo pública, no seguridad. En previews públicas también revisamos noindex.
Nuestro checklist
Comprobamos protocolo, host, puerto, www, HTTP/HTTPS, propietario del despliegue, staging y respuesta pública con el checker. Pensar por origen evita modificar el robots.txt equivocado.
