1) Panorama general: ¿para qué sirve cada archivo?

Empecemos con la diferencia clave:

• robots.txt: protocolo de exclusión de robots. Es una sugerencia pública para agentes automatizados (bots) sobre qué rastrear o no. Está pensado para rastreo, no para seguridad. Los navegadores de usuarios humanos lo ignoran; un atacante también podría ignorarlo.
• .htaccess (Apache): archivo de configuración por directorio que permite reglas de reescritura, redirecciones, control de acceso, headers y más. Lo obedece el servidor en tiempo de petición, tanto para humanos como para bots. En Nginx no existe .htaccess; las reglas van en el server block.

Si robots.txt es un cartel de “zona peatonal” para robots, .htaccess es la policía de tráfico que, llegado el caso, detiene, redirige o prohíbe el paso.

2) Robots.txt: definición, límites y expectativas reales

El archivo /robots.txt debe estar en la raíz del dominio (p. ej., https://midominio.com/robots.txt). Indica a los user-agents (Googlebot, Bingbot, etc.) qué rutas pueden o no rastrear. Es público y legible por cualquiera.

Sus límites más importantes:

• No es seguridad: Disallow no impide que alguien acceda a una URL si la conoce; sólo pide a los robots que no la rastreen.
• No borra contenido del índice: si bloqueas una URL con robots.txt y esa URL ya estaba indexada por enlaces externos, puede seguir apareciendo (a veces sin snippet). Para desindexar, usa noindex a nivel de meta o responde 410 Gone/404, entre otras técnicas.
• No garantiza obediencia: los bots bien educados lo respetan; los maliciosos, no.

Entender esto te ahorrará frustraciones: robots.txt guía el rastreo; no controla la indexación por sí solo ni la seguridad.

3) Robots.txt: sintaxis esencial y ejemplos prácticos

La estructura básica es:

User-agent: <nombre del bot> | *
Disallow: /ruta/que/no
Allow: /ruta/permitida
Sitemap: https://midominio.com/sitemap.xml

Notas útiles:

• Comodines: * (cualquier secuencia), $ (fin de URL) — Google los entiende; no todos los buscadores lo hacen.
• Prioridad: las reglas más específicas suelen prevalecer.
• Mayúsculas/minúsculas: la URL es sensible a mayúsculas en servidores Linux.

3.1 Ejemplos típicos

Permitir todo (por defecto) y declarar sitemap:

User-agent: *
Disallow:
Sitemap: https://midominio.com/sitemap.xml

Bloquear carpetas internas sin valor de rastreo:

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

Bloquear parámetros de filtrado (si generan infinitas variaciones sin contenido nuevo):

User-agent: *
Disallow: /*?sort=
Disallow: /*&sort=

Bloquear PDFs si no quieres que se rastreen (ojo: pueden seguir indexados por enlaces externos):

User-agent: *
Disallow: /*.pdf$

3.2 Declarar Sitemaps

Puedes listar varios sitemaps o un índice de sitemaps. Esto ayuda a los bots a descubrir contenidos con más precisión.

3.3 Validación

Valida la sintaxis en Search Console o herramientas de terceros. Google documenta el estándar del archivo y su interpretación: guía de robots.txt.

4) Robots.txt y SEO: cómo afecta (y cómo no) a la indexación

Relación clave:

• Rastreo → Indexación: si prohíbes el rastreo de una URL, el bot no puede ver metaetiquetas noindex ni contenido. Si esa URL ya tiene enlaces entrantes, podría permanecer indexada sin contenido visible. Para desindexar, permite rastreo y devuelve noindex, o bien responde con 410/404 si procede.
• Crawl budget: bloquear rutas sin valor (filtros infinitos, páginas internas irrelevantes) ayuda a concentrar el presupuesto de rastreo en lo importante.
• Duplicidad: robots.txt no “arregla” duplicidad por sí mismo; coordínalo con rel="canonical", arquitectura limpia y redirecciones correctas.

Conclusión: robots.txt es un acelerador de orden para rastreo, no una herramienta directa de indexación.

5) .htaccess: qué es, dónde vive y por qué manda tanto

En Apache, .htaccess es un archivo de configuración por directorio que se ejecuta en cada solicitud. Permite sobrescribir directivas del servidor sin tocar el archivo principal (httpd.conf), siempre que el admin del servidor lo permita (AllowOverride).

Con .htaccess puedes:

• Reescribir URLs (bonitas, canónicas).
• Redirigir (301/302/410…) con flexibilidad.
• Controlar accesos por IP, user-agent o directorios.
• Enviar cabeceras (cache, seguridad).

Documentación oficial de Apache (mod_rewrite): httpd.apache.org/docs/current/rewrite/. Sintaxis de directivas: .htaccess HowTo.

6) .htaccess: reglas básicas (reescrituras, redirecciones, control de acceso)

.htaccess trabaja con módulos. Para reescrituras necesitas mod_rewrite activo. Estructura típica:

RewriteEngine On
# Reglas aquí...

6.1 URLs canónicas (www vs sin www)

# Forzar sin www (301)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.midominio\.com$ [NC]
RewriteRule ^(.*)$ https://midominio.com/$1 [L,R=301]

Elige una variante canónica y sé consistente en enlaces internos, sitemap y Search Console.

6.2 HTTP → HTTPS (redirección permanente)

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Si usas un proxy/CDN (Cloudflare, etc.), revisa cabeceras como X-Forwarded-Proto o configura la redirección en el propio CDN para evitar bucles.

6.3 Redirecciones 301 por cambio de estructura

# De /blog/post-slug a /post-slug
RewriteEngine On
RewriteRule ^blog/(.*)$ /$1 [L,R=301]

6.4 Redirecciones puntuales

Redirect 301 /articulo-antiguo https://midominio.com/articulo-nuevo

6.5 410 Gone para URL retiradas

Redirect 410 /producto-descatalogado

Útil cuando un contenido dejó de existir y no hay equivalente. Ayuda a limpiar el índice.

6.6 Bloqueo de directorios sensibles

<FilesMatch "^(composer\.json|composer\.lock|\.env)$">
  Require all denied
</FilesMatch>

Nota: seguridad no debe basarse en .htaccess únicamente; refuerza permisos, estructura y despliegue.

6.7 Cabeceras de caché (estáticos)

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 6 months"
  ExpiresByType image/png  "access plus 6 months"
  ExpiresByType text/css   "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Evita invalidar caché con cada despliegue; usa versiones en querystring o nombres con hash.

7) Estrategia de redirecciones: del caos a un plan limpio

Las redirecciones son fáceis de crear y difíciles de gobernar con el tiempo. Buenas prácticas:

• Mapa maestro (CSV) con “desde → hacia” y fecha de alta.
• Evitar cadenas (A→B→C): apunta siempre al destino final (A→C).
• Evitar bucles (A→B → A).
• Revisión trimestral: elimina reglas obsoletas y consolida.
• Prioriza patrones sobre reglas individuales cuando sea posible.

Una migración ordenada (dominio o estructura) depende de este plan y de medir 404 post-migración.

8) Errores clásicos (y caros) con robots.txt y .htaccess

• Bloquear CSS/JS críticos en robots.txt: impides que Google renderice bien y evalúe Core Web Vitals.
• Bloquear todo el sitio en producción por un robots.txt heredado de staging (Disallow: /).
• Creer que robots.txt desindexa: ya vimos que no.
• Reglas de .htaccess duplicadas o en orden incorrecto, generando cadenas o bucles.
• Forzar HTTPS/www sin considerar CDN/proxy y cabeceras, provocando redirecciones eternas.
• No medir después de cambios: vuelas a ciegas.

9) Cómo verificar cambios sin romper nada (método de trabajo)

1. Backups y staging: copia de seguridad y entorno de pruebas.
2. Validación de robots.txt: usa la documentación de Google y su herramienta de pruebas; revisa que no bloqueas CSS/JS necesarios. Referencia: guía de robots.txt.
3. Prueba de redirecciones: con curl -I verifica códigos 301/302/410 y destinos finales (sin cadenas).
4. Registro de 404: activa logs y corrige rutas clave.
5. Rendimiento: mide antes/después (TTFB, INP, LCP). Ajusta caché y reglas.
6. Monitoreo continuo: usa alertas si cambian los patrones de error.

10) Aplicación en WordPress: orden de reglas, ejemplos y cautelas

WordPress aporta una base sólida, pero también complejidad (plugins, themes, endpoints). La clave es mantener orden y compatibilidad.

10.1 robots.txt para WordPress (base prudente)

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
# Permite recursos necesarios para renderizado
Allow: /wp-includes/js/
Allow: /wp-content/uploads/
Sitemap: https://midominio.com/sitemap_index.xml

Notas: evita bloquear /wp-includes/ de forma global si rompe el renderizado de CSS/JS. Comprueba con “Ver código fuente” y “Herramientas para desarrolladores”.

10.2 .htaccess típico de WordPress (pretty permalinks)

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Coloca antes de este bloque tus redirecciones canónicas (HTTP→HTTPS, www↔no-www) y después las puntuales si es necesario, evitando interferir con el enrutado de WordPress.

10.3 Forzar HTTPS y canónica sin www (ejemplo completo)

# 0) Seguridad: protege archivos sensibles
<FilesMatch "^(wp-config\.php|readme\.html|license\.txt)$">
  Require all denied
</FilesMatch>

# 1) Canonicalización y HTTPS
RewriteEngine On
# Fuerza HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]
# Fuerza sin www
RewriteCond %{HTTP_HOST} ^www\.midominio\.com$ [NC]
RewriteRule ^(.*)$ https://midominio.com/$1 [L,R=301]

# 2) WordPress (pretty permalinks)
<IfModule mod_rewrite.c>
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# 3) Redirecciones puntuales (si hacen falta)
Redirect 301 /antiguo-slug https://midominio.com/nuevo-slug

# 4) Cache estáticos (opcional)
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 6 months"
ExpiresByType text/css   "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>

10.4 Evitar bloquear recursos críticos con robots.txt

Verifica que el CSS y JS necesarios para renderizado no estén bajo un Disallow. Google recomienda permitir el acceso a recursos que afectan al render. Consulta su doc: recomendaciones específicas.

10.5 Admin-ajax y REST

No bloquees admin-ajax.php si tu sitio depende de él para funcionalidades (buscadores, filtros). Para REST, si expones endpoints, documenta y protege capacidades. Referencia WordPress REST: developer.wordpress.org/rest-api/.

10.6 Staging vs Producción

En staging, lo sensato es:

• Restringir por auth básica o IP a nivel de servidor (evita indexación directa).
• Si usas robots.txt con Disallow: /, recuerda retirarlo al pasar a producción (error típico).

# .htaccess con auth básica (ejemplo)
AuthType Basic
AuthName "Staging"
AuthUserFile /ruta/segura/.htpasswd
Require valid-user

11) Casos avanzados: multilenguaje, staging, proxies/CDN

11.1 Multilenguaje (subcarpetas)

Ejemplo: /es/ y /en/. Asegura coherencia en redirecciones y evita mezclar idiomas con reglas globales. Es mejor una regla por rama si cambias estructura (p. ej., /es/blog/ → /es/).

11.2 CDN/Proxy

Si usas CDN con reglas propias, decide dónde vive cada redirección (CDN vs .htaccess) para evitar duplicidades. Considera cabeceras X-Forwarded-Proto para HTTPS y X-Real-IP si registras IPs.

11.3 Micrositios y subdominios

Cada host tiene su robots.txt independiente. Documenta sitemaps por host y evita reglas “copiar/pegar” que no aplican.

12) Checklist final para pasar a la acción

1. Define tu canónica (www o no, y HTTPS) y sé consistente en todo el sitio.
2. Redirecciones: mapa maestro, sin cadenas ni bucles; apunta al destino final.
3. robots.txt: permite recursos críticos y bloquea solo lo que no aporta valor al rastreo.
4. Sitemaps correctos (índice si procede) y declarados en robots.txt.
5. Staging protegido por auth/IP; no confíes sólo en robots.txt para ocultar entornos.
6. Verificación con curl -I, herramientas de Search Console y logs 404.
7. Medición antes/después (TTFB, INP, LCP, cobertura de Search Console).
8. Mantenimiento trimestral: limpia reglas obsoletas, revisa 404 y consolida.

13) Recursos recomendados

• Google Search Central — Introducción a robots.txt: developers.google.com/search/docs/crawling-indexing/robots/intro
• Google — Específicos de Google para robots.txt: developers.google.com/.../robots/intro#google-specific
• Apache — mod_rewrite: httpd.apache.org/docs/current/rewrite/
• Apache — .htaccess HowTo: httpd.apache.org/docs/current/howto/htaccess.html
• WordPress REST API Handbook: developer.wordpress.org/rest-api/

14) FAQ

¿Puedo usar robots.txt para esconder datos sensibles?

No. Robots.txt no es seguridad. Usa autenticación, permisos, firewall y arquitectura adecuada. Robots solo “piden” a los bots que no rastreen.

Bloqueé una carpeta en robots.txt pero sigue saliendo en Google, ¿por qué?

Porque bloquear el rastreo no implica desindexar. Permite rastreo y añade noindex, o devuelve 410/404 si corresponde. También puedes usar herramientas de retirada en Search Console.

¿Debo bloquear /wp-includes/ o /wp-content/ en WordPress?

Evítalo si rompe los recursos necesarios para renderizar (CSS/JS). Es mejor un enfoque de permiso selectivo a recursos críticos.

¿Qué prioridad tiene .htaccess frente a reglas del CDN?

Depende del orden de la ruta de la petición. Si el CDN hace redirección antes de llegar a tu servidor, su regla “gana”. Coordina para no duplicar ni crear bucles.

¿Nginx usa .htaccess?

No. En Nginx las reglas van en el bloque de servidor (nginx.conf). El concepto es el mismo (reescribir/redirigir), pero la sintaxis cambia.