Un medio decide que ciertas páginas auxiliares no deberían aparecer en Google. Alguien agrega un bloqueo en robots.txt; otra persona activa noindex desde el CMS. La combinación parece más segura porque acumula dos restricciones. Sin embargo, puede impedir que el buscador lea justamente la instrucción que necesita para dejar de mostrar la página.
Antes de tocar una plantilla, conviene escribir el objetivo con precisión: ¿querés evitar solicitudes del rastreador, excluir una página de los resultados o impedir el acceso público a información privada? Son problemas diferentes. Resolverlos con una única receta deja una configuración difícil de mantener y un diagnóstico todavía más confuso.
Robots.txt controla el rastreo, no garantiza la exclusión
La documentación de Google sobre robots.txt explica que una URL bloqueada puede seguir apareciendo en los resultados si el buscador la descubre mediante enlaces. Google no necesita visitar su contenido para conocer su dirección. Por eso, bloquear una página HTML en ese archivo no equivale a retirarla del índice.
El archivo tampoco funciona como un permiso de acceso para personas ni como una medida de seguridad. Sus reglas dependen de que cada rastreador las respete. Si el problema es que un documento interno quedó expuesto, discutir qué bot debería visitarlo es una respuesta insuficiente.
Noindex necesita que Google pueda leer la respuesta
Según la guía de noindex de Search Central, la instrucción puede enviarse en una etiqueta meta o en el encabezado HTTP X-Robots-Tag. Para que surta efecto, Googlebot debe acceder al recurso y encontrarla. Un bloqueo de rastreo puede impedir esa lectura.
Esto también importa para archivos que no son páginas HTML, como un PDF: el encabezado HTTP permite comunicar la restricción sin depender de una etiqueta dentro de una página. Google no admite noindex como regla dentro de robots.txt. Tampoco hay que asumir que el cambio será instantáneo: hace falta que el buscador vuelva a procesar la respuesta.
Una decisión editorial antes de una regla técnica
Nuestra propuesta para una redacción es separar el inventario en grupos con responsables claros. Una página de servicio que debe seguir disponible para lectores, pero no competir en búsquedas, plantea una decisión diferente de un borrador confidencial o de un documento que ya no tiene razón para estar publicado.
Registrá, para cada grupo, quién necesita acceder, cuál es el motivo de la restricción y qué resultado se espera observar. Evitá categorías vagas como “URLs malas”. Esa descripción puede mezclar errores, archivos antiguos, formularios y contenido todavía útil. Cuando el objetivo está mal definido, una implementación técnicamente correcta puede terminar resolviendo el problema equivocado.
Si hay urgencia, separar ocultamiento y solución permanente
Google distingue entre una retirada temporal de resultados y una medida duradera en su guía para retirar información del sitio. Las solicitudes de la herramienta de retiradas duran aproximadamente seis meses. No sustituyen los cambios necesarios en el contenido o en su acceso.
Si hay información privada expuesta, priorizá restringir el acceso en origen y revisar las distintas direcciones que permiten llegar al mismo contenido. Sacar una URL de un resultado no borra el recurso ni vuelve privada su dirección. En una redacción, este incidente necesita coordinación con la persona responsable del contenido y con el equipo técnico, no sólo un ajuste SEO.
Una auditoría pequeña que se pueda repetir
Para empezar, proponemos trabajar con una muestra manejable de cada plantilla afectada. No es una cantidad prescrita por Google: es una forma de probar hipótesis sin desplegar cambios generales a ciegas. Incluí un caso que debería seguir visible y otro que debería quedar excluido, para comprobar ambos resultados.
- Definí el estado deseado. Anotá si la página debe ser pública, rastreable y elegible para aparecer en búsquedas. No completes estas columnas por costumbre.
- Revisá la respuesta real. Contrastá la configuración del CMS con lo que entrega el servidor. Conservá fecha, URL y evidencia para poder comparar después.
- Buscá restricciones superpuestas. Revisá plantilla, configuración del servidor y robots.txt con el mismo objetivo. Evitá que distintos equipos cambien controles por separado.
- Asigná un responsable. Dejá definido quién implementa, quién verifica y en qué momento se vuelve a revisar. Un ticket sin criterio de cierre puede quedar abierto indefinidamente.
Comprobar hoy no es confirmar lo que Google ya procesó
La ayuda de Inspección de URLs distingue la información de la versión indexada y la prueba en tiempo real. La primera refleja lo que Google conoce del rastreo anterior; la segunda sirve para evaluar la versión disponible ahora. No conviene interpretar una diferencia entre ambas como prueba automática de que el cambio falló.
En la revisión, compará la fecha del último rastreo con la del despliegue. Consultá también si el rastreo estaba permitido y qué respuesta pudo obtener Google. Si sólo mirás un indicador general, podés atribuir al CMS un estado anterior al ajuste o dar por resuelta una exclusión que todavía no fue procesada.
El criterio de cierre no es “ya cambiamos el archivo”
Para Abigdoor, una buena entrega técnica debe permitir que otra persona reconstruya la decisión: objetivo, alcance, evidencia y resultado observado. Conservá además una ruta de reversión para cambios involuntarios. No hace falta convertir cada ajuste en un proyecto enorme, pero sí evitar que el conocimiento quede en una conversación privada.
La regla práctica es sencilla: primero elegí qué querés impedir; después seleccioná el control que corresponde y verificá que otro ajuste no lo contradiga. El éxito no se mide por cuántas restricciones agregaste, sino por si la página termina teniendo el acceso y la visibilidad que el medio decidió.
