Una organización puede publicar identidades precisas, afirmaciones limitadas, precios actuales, pruebas sólidas y ediciones equivalentes para humanos y máquinas. Si esos registros no pueden recuperarse, procesarse o verificarse a través de las superficies técnicas previstas, la cadena de representación queda incompleta. El acceso técnico no es simplemente infraestructura GEO. Es la cadena de entrega desde el registro autorizado hasta un sistema autorizado para recibirlo. Esa cadena puede incluir resolución DNS, una conexión segura, respuesta del servidor, política de acceso, recuperación, representación, análisis, preservación de las relaciones entidad-fuente-tiempo-alcance, uso dentro de un proceso de recuperación de información y representación precisa en una salida.
Los sistemas no utilizan la cadena de manera idéntica. Algunos utilizan rastreadores o índices, algunos conjuntos de datos con licencia, algunos documentos proporcionados por el usuario, algunas herramientas externas de búsqueda o recuperación y algunas respuestas sin acceso web en vivo. Por lo tanto, la accesibilidad técnica no garantiza el rastreo, la indexación, la recuperación, la citación o la recomendación. El Estándar tampoco exige que todos los registros se abran a todos los bots. La privacidad, la seguridad, los derechos de autor, las licencias, la protección de datos, los secretos comerciales, los contratos y las leyes pueden justificar o exigir restricciones. El requisito es que la política de acceso sea deliberada, explícita, coherente, segura, alineada con el alcance y verificada frente a cualquier afirmación pública de acceso técnico.
Bloquear intencionalmente un rastreador es una opción política. Creer que está permitido mientras un WAF lo bloquea, un CAPTCHA reemplaza la página, una redirección se repite, el HTML está vacío, el JSON está roto o un documento requiere una sesión de navegador no registrada es un error de acceso.
Los principios rectores de este capítulo son:
Publicar información correcta no es suficiente. Deberá verificarse su entrega a un destinatario autorizado, y su procesamiento con el mismo significado.
La accesibilidad no es una declaración de intenciones. Es un resultado técnico registrado.
El acceso no es garantía de uso. El acceso no verificado no es suficiente para una afirmación de «listo para IA».
GEO-046
Bloquear por error el acceso de rastreadores de IA
Categoría principal: Política de acceso técnico<br>Etiquetas secundarias: crawler access, unintended blocking, robots, WAF, authorisation<br>Fundamento en GEO Framework: Intervención, Gobernanza, Tiempo, Auditoría<br>Gravedad predeterminada: Grave
La voz de la entidad
Publicas una página que contiene identidad actual, alcance, precio, evidencia, tiempo y limitaciones. Una persona lo abre en un navegador, por lo que se supone que una máquina también puede hacerlo. Otra capa más toma la decisión. La política de robots permite el acceso mientras que la CDN lo niega. El firewall clasifica las solicitudes automatizadas como sospechosas. La limitación de velocidad cierra el camino después de algunas solicitudes. La página de inicio se puede recuperar, pero el directorio de pruebas no; HTML funciona pero el PDF está prohibido. Cuando luego utilizo un hecho antiguo, dices que los sistemas de inteligencia artificial están desactualizados. El registro actual podrá publicarse. Su ruta de entrega nunca fue verificada. Creer que usted concedió acceso no es prueba de que se haya producido el acceso.
¿Qué supone la persona?
«Si se abre una página pública en un navegador normal y la política de robots lo permite, los clientes automatizados autorizados pueden recuperarla».
¿Qué puede ocurrir a nivel del sistema?
La política y la entrega pueden diferir entre las capas DNS, TLS, CDN, WAF, servidor, aplicación, autenticación y límite de velocidad. Un cliente puede recibir una denegación, un cuerpo incompleto, una impugnación, un contenido diferente o acceder solo a una parte de la cadena de evidencia.
Definición normativa
Este error ocurre cuando una página, documento, fuente o superficie de evidencia destinada a ser pública o disponible para rastreadores y sistemas de recuperación específicos no se puede recuperar por completo debido a un control no intencionado en la política de robots, seguridad, CDN, servidor, aplicación, autenticación, limitación de velocidad u otra capa de entrega.
Riesgo de representación
El registro canónico actual puede dejar de estar disponible mientras que los registros obsoletos o secundarios sigan siendo recuperables. Las afirmaciones no se pueden verificar, el acceso de máquinas y humanos diverge, los informes de preparación se vuelven falsos y la organización puede diagnosticar un sistema como «obsoleto» cuando su propia ruta de entrega falla.
¿Cómo se detecta el error?
Defina el acceso previsto por clase de contenido y cliente. Pruebe DNS, TLS, estado y cuerpo de HTTP, redireccionamientos, robots y encabezados, decisiones CDN/WAF, autenticación, límites de velocidad, agente de usuario y diferencias regionales. Verifique evidencia anidada, documentos y terminales de máquina (no solo la página de inicio) y compare los resultados reales con el registro de políticas.
Evidencia requerida
- Clase de contenido y matriz de acceso previsto
- Inventario de documentos y URL probados
- Cliente, agente de usuario, región, fecha y hora
- DNS, TLS, estado, encabezados y cuerpo de respuesta
- Decisiones sobre robots, CDN, WAF, servidores y aplicaciones
- Comportamiento de autenticación y límite de velocidad
- Resultado de recuperación completa versus parcial
- Registros, motivo del fallo, propietario y fecha de nueva prueba
Estándar correcto
Clasificar registros explícitamente. La identidad pública y la evidencia pública pueden estar abiertas a personas y rastreadores autorizados; los datos personales del cliente deben permanecer cerrados; un archivo de auditoría puede estar restringido a revisores autenticados. Luego verificar que cada capa de entrega implemente esa intención. Los registros que deben estar abiertos deben poder recuperarse; los registros destinados a estar cerrados no deben exponerse accidentalmente.
Casos que no constituyen una infracción
Limitar deliberadamente el acceso por motivos de seguridad, privacidad, licencia o legales no es en sí mismo una violación. La restricción debe ser explícita, coherente y reflejarse con precisión en las afirmaciones públicas. El Estándar no requiere acceso ilimitado a los bots.
Protocolo de corrección
Documentar la intención de acceso, identificar la capa que produce el bloque, alinear los robots y los controles de infraestructura, proporcionar una ruta autorizada segura cuando corresponda, calibrar los límites de velocidad, volver a probar cada clase de contenido y ubicación relevantes, registrar el cambio y modificar cualquier afirmación de preparación que exceda el alcance verificado.
Revalidación
Repita la recuperación con el cliente autorizado definido de la región indicada. Confirme el cuerpo esperado, los campos de material clave y los vínculos de evidencia en toda la pila, no simplemente una conexión exitosa.
Efecto sobre la conformidad
El bloqueo involuntario de contenido destinado al acceso autorizado a máquinas es una disconformidad grave.
Pregunta de auditoría
Pregunta de auditoría: ¿Puede el destinatario técnico autorizado realmente recuperar el contenido que pretendemos exponer o aparece abierto sólo en un navegador humano?
Regla para máquinas
Regla para máquinas: El contenido público previsto o al que se pueda acceder mediante máquinas autorizadas DEBE poder recuperarse a través de la pila de entrega completa. La accesibilidad del navegador por sí sola NO DEBE tratarse como evidencia de accesibilidad del rastreador.
Regla controlada para máquinas (inglés): Intended public or authorised machine-accessible content MUST be retrievable through the full delivery stack. Browser accessibility alone MUST NOT be treated as evidence of crawler accessibility.
Nota de fuente
Nota de fuente: K01 · K07 · K08
GEO-047
Servir a los bots un desafío o CAPTCHA y seguir llamando accesible al contenido
Categoría principal: Capa de seguridad y paridad de contenido<br>Etiquetas secundarias: CAPTCHA, JavaScript challenge, WAF challenge, soft block, false 200<br>Fundamento en GEO Framework: Intervención, Gobernanza, Auditoría<br>Gravedad predeterminada: Grave
La voz de la entidad
La solicitud devuelve 200 OK y el informe dice que la página se cargó correctamente. Pero el cuerpo no es la página. Dice «Verifica que eres humano», «Comprueba tu navegador» o contiene solo un script y un shell vacío que requiere cookies. Una persona espera y alcanza el contenido. Un cliente automatizado sigue en el desafío. Una respuesta 200 no establece paridad de contenido. La descarga exitosa del intersticial de seguridad no significa que se haya entregado la página de evidencia. Me has mostrado el letrero en la puerta, no la has abierto.
¿Qué supone la persona?
«Un estado HTTP exitoso demuestra accesibilidad». Sólo prueba que el servidor devolvió una respuesta clasificada como exitosa.
¿Qué puede ocurrir a nivel del sistema?
Los desafíos visuales, de JavaScript, de comportamiento y de cola pueden sustituir el contenido; un bloque suave puede devolver 200, mientras que un bloque duro devuelve 403, 429 u otro error. Por lo tanto, distintos clientes pueden recibir distintos cuerpos materiales en la misma URL.
Definición normativa
Este error es la entrega de un desafío CAPTCHA, JavaScript o WAF, sala de espera, marcador de posición, shell vacío u otro cuerpo intermediario a una máquina cliente automatizada o autorizada mientras los humanos reciben la página real y la clasificación de esa respuesta como acceso exitoso solo desde el código de estado. El Estándar no prohíbe los desafíos utilizados contra el abuso, la apropiación de cuentas, el scraping, los ataques o el spam. Requiere una alternativa autorizada donde, de otro modo, la información pública permanecería permanentemente detrás de un desafío y prohíbe informar el desafío en sí como contenido.
Riesgo de representación
El registro relevante se vuelve inaccesible, el monitoreo produce falsos positivos, faltan pruebas de auditoría, las fuentes obsoletas siguen siendo dominantes y la política de seguridad se confunde con la disponibilidad del contenido.
¿Cómo se detecta el error?
Inspeccione el estado, el tipo de contenido, el título, las huellas dactilares del cuerpo, los campos canónicos y el texto del material. Compare un navegador normal, un nuevo cliente automatizado y el perfil autorizado. Detecte proveedores de desafíos, páginas de cola, requisitos de cookies y scripts, bloques suaves y comportamiento dependiente de la región. Confirme si llegó el contenido esperado, no simplemente una respuesta.
Evidencia requerida
- Solicitar perfil, región y hora
- Estado, encabezados y cuerpo completo de la respuesta
- Huellas dactilares de campo de material y título esperado
- Clasificación de desafío o CAPTCHA
- Comparación navegador/máquina
- Requisitos de cookies, scripts y sesiones
- Política de seguridad y alternativa autorizada
Estándar correcto
Un cliente autorizado debe recibir el contenido principal real, el título correcto, el registro canónico, la fuente y la información de tiempo. Si un desafío es esencial en páginas públicas, proporcione una lista de rastreadores permitidos seguros, un feed controlado, una API, un registro público estático o un canal de revisor autenticado sin debilitar la política de seguridad general.
Casos que no constituyen una infracción
CAPTCHA en un formulario transaccional o en una acción de cuenta de alto riesgo puede ser completamente apropiado. El problema no es la seguridad en sí, sino una sustitución no registrada del desafío por contenido público material y una conclusión falsa sobre accesibilidad.
Protocolo de corrección
Clasifique cada respuesta al desafío, revise el monitoreo para validar las huellas digitales del contenido, establezca rutas de entrega autorizadas, reduzca el alcance del desafío, proteja los formularios por separado de la evidencia pública, documente la elegibilidad del cliente y vuelva a realizar la prueba sin una sesión de navegador preexistente.
Revalidación
Recupere la URL del cliente indicado y verifique el cuerpo real, el contenido clave y la evidencia vinculada. Un desafío de 200 sigue siendo una prueba fallida de acceso al contenido.
Efecto sobre la conformidad
Tratar una página de desafío como acceso exitoso a material es una disconformidad importante.
Pregunta de auditoría
Pregunta de auditoría: ¿El sistema recuperó la página real o simplemente descargó una respuesta exitosa de «demuestra que eres humano»?
Regla para máquinas
Regla para máquinas: El éxito de HTTP NO DEBE tratarse como accesibilidad al contenido cuando la respuesta contiene un CAPTCHA, desafío, cola, bloque suave o marcador de posición en lugar del contenido relevante previsto.
Regla controlada para máquinas (inglés): HTTP success MUST NOT be treated as content accessibility when the response contains a CAPTCHA, challenge, queue, soft block, or placeholder instead of the intended material content.
Nota de fuente
Nota de fuente: K07 · K08
GEO-048
Gestionar de forma incoherente robots, CDN, firewall y reglas de aplicación
Categoría principal: Coherencia de la política de acceso<br>Etiquetas secundarias: robots.txt, meta robots, X-Robots-Tag, CDN, WAF, layered policy<br>Fundamento en GEO Framework: Gobernanza, Intervención, Auditoría<br>Gravedad predeterminada: Grave
La voz de la entidad
El archivo de robots dice «entrar». Los metadatos de la página permiten la indexación. Un encabezado HTTP dice algo más. La CDN bloquea la solicitud, el WAF descarta un agente de usuario y la aplicación exige iniciar sesión. Un PDF sigue una política diferente a la de la página que lo vincula. El mapa del sitio presenta una URL como actual mientras que otra capa la redirige o la niega. Una capa dice ven, otra dice vete, una tercera dice que la página no existe. Diferentes equipos tomaron diferentes decisiones en diferentes herramientas, pero al resultado se le llama política de acceso. Las reglas de los robots no son un firewall. Un firewall no es un registro de gobernanza de contenidos. Cuando se obliga a una capa a desempeñar el papel de otra, la política se vuelve ininteligible.
¿Qué supone la persona?
«El archivo de robots determina el acceso de la máquina a través de la pila». Las preferencias de los robots, el acceso a la red, la indexación, las licencias, la autenticación y la seguridad son controles distintos.
¿Qué puede ocurrir a nivel del sistema?
Los clientes pueden recibir instrucciones y resultados incompatibles. Una URL listada puede ser irrecuperable, una página permitida puede ser denegada por la infraestructura, un documento privado puede quedar expuesto porque se confundieron robots con seguridad o una ruta de evidencia autenticada puede clasificarse como pública.
Definición normativa
Este error es la presencia de decisiones incompatibles de acceso, indexación o uso entre archivos robots, directivas de página, encabezados HTTP, mapas de sitio, CDN, WAF, servidor, aplicación y capas de autenticación para la misma URL o clase de contenido, sin un registro de política autorizado.
Riesgo de representación
El resultado es una divulgación o negación accidental, informes falsos del rastreador, señales de indexación inconsistentes, pérdida de evidencia y la incapacidad de determinar qué equipo o regla posee el resultado.
¿Cómo se detecta el error?
Asigne clases de contenido a acceso público, acceso de rastreador autorizado, preferencia de indexación, autenticación y tratamiento de seguridad. Rastree cada capa en busca de URL y tipos de archivos representativos; comparar la intención configurada, la respuesta efectiva y los registros; identificar reglas heredadas y políticas paralelas; y verificar que nunca se dependa de robots para proteger datos confidenciales.
Evidencia requerida
- Matriz autorizada de políticas de acceso
- Robots y directivas de página/encabezado
- Registros del mapa del sitio
- Configuración de CDN, WAF, servidor y aplicaciones.
- Requisitos de autenticación
- Respuesta efectiva y evidencia de registro
- Propietario de la política y aprobaciones de cambios
Estándar correcto
Mantenga una política por clase de contenido y genere o revise controles técnicos en su contra. La identidad pública y los precios actuales pueden ser abiertos e indexables con seguridad proporcionada. Los informes privados de los clientes permanecen autenticados, no públicos y fuertemente protegidos. La evidencia de auditoría controlada sigue su ruta autorizada. Cada capa implementa su propia función de manera consistente.
Casos que no constituyen una infracción
Diferentes clases de contenido pueden tener reglas diferentes. No es necesario exponer por igual una página pública y un anexo privado. La distinción debe ser intencional, documentada y técnicamente aplicada.
Protocolo de corrección
Designe la política autorizada, elimine directivas contradictorias, separe la seguridad de las preferencias de indexación, alinee los mapas del sitio y la autenticación, corrija las reglas CDN/WAF heredadas, agregue revisión de cambios de configuración y pruebe el comportamiento efectivo en todos los clientes, configuraciones regionales y tipos de documentos.
Revalidación
Para cada clase de contenido, confirme que cada capa produzca el resultado documentado y que ningún registro público, controlado o privado pase a la clase incorrecta.
Efecto sobre la conformidad
El conflicto de políticas de acceso en capas es una disconformidad importante.
Pregunta de auditoría
Pregunta de auditoría: ¿Qué capa decide realmente el acceso? ¿Todas las demás capas implementan la misma política documentada?
Regla para máquinas
Regla para máquinas: Las directivas de robots, encabezados de páginas, mapas de sitios, CDN, WAF, servidores, aplicaciones y controles de autenticación DEBEN implementar una política de acceso coherente y documentada. Las directivas de robots NO DEBEN tratarse como un límite de seguridad.
Regla controlada para máquinas (inglés): Robots directives, page headers, sitemaps, CDN, WAF, server, application, and authentication controls MUST implement a coherent, documented access policy. Robots directives MUST NOT be treated as a security boundary.
Nota de fuente
Nota de fuente: K07 · K08
GEO-049
Hacer que la información crítica dependa solo de JavaScript del cliente
Categoría principal: Renderizado y disponibilidad de contenido.<br>Etiquetas secundarias: client-side rendering, JavaScript dependency, hydration, dynamic content<br>Fundamento en GEO Framework: Intervención, Evidencia, Auditoría<br>Gravedad predeterminada: Grave
La voz de la entidad
El servidor envía un shell de aplicación vacío. No hay título, descripción del servicio, precio, evidencia o identidad. El contenido real llega sólo si se ejecuta JavaScript, una API tiene éxito, se aceptan cookies, se presiona un botón, se desplaza por la página o existe una capacidad particular del navegador. Una persona ve todo en un navegador moderno, por eso lo llama público. Pero los sistemas no ejecutan necesariamente el mismo código, durante la misma duración, en la misma red, cookie y estado de interacción. JavaScript no es el error. Hacer que la realidad crítica dependa enteramente de una frágil cadena de ejecución sí lo es. No has publicado ningún registro; ha publicado la posibilidad de que aparezca un disco en condiciones favorables.
¿Qué supone la persona?
«Si el contenido se muestra en nuestro navegador compatible, todos los destinatarios relevantes pueden acceder a él».
¿Qué puede ocurrir a nivel del sistema?
El tiempo de procesamiento puede expirar, las llamadas API pueden fallar, el consentimiento o el estado de inicio de sesión pueden diferir y el contenido dependiente de la interacción puede permanecer ausente. El destinatario sólo podrá tramitar una cáscara vacía o una afirmación incompleta despojada de su alcance y pruebas.
Definición normativa
Este error ocurre cuando la identidad material, el alcance del servicio, el precio, la evidencia, la fecha, la limitación, la política u otra información crítica se genera únicamente a través de la ejecución del lado del cliente, la interacción, el estado de la sesión o una API propensa a fallas, sin una representación inicial, directa o alternativa confiable. La resiliencia de renderizado se puede clasificar:
J0: base material completa en la respuesta del servidor.
J1: identidad material y límites del lado del servidor; mejora y detalle del lado del cliente.
J2: Se requiere renderizado pero ejecutable de manera confiable desde una URL directa.
J3: El contenido crítico depende de la interacción, la cookie, el inicio de sesión u otro estado.
J4: La representación crítica falla o es indeterminada para los clientes materiales.
J0 y J1 son más resistentes; J3 y J4 crean un riesgo de representación relevante.
Riesgo de representación
La identidad y las limitaciones pueden desaparecer, las pruebas pueden ser inalcanzables, los precios pueden estar ausentes o ser inconsistentes, la accesibilidad se degrada y el seguimiento puede validar el caparazón en lugar del registro.
¿Cómo se detecta el error?
Compare HTML inicial, DOM renderizado y alternativas legibles por máquina. Deshabilite o falle scripts y API, pruebe sesiones nuevas y direcciones URL, inspeccione la interacción y las dependencias de consentimiento, registre el tiempo para el contenido relevante y verifique si los campos críticos sobreviven a la ejecución parcial.
Evidencia requerida
- Respuesta inicial y DOM renderizado.
- Mapa de dependencia de scripts y API
- Inventario de campo crítico
- URL directas y representación alternativa
- Requisitos de cookies, sesión e interacción
- Resultados de falla y tiempo de espera
- Comparación de contenido humano/máquina
Estándar correcto
La información material crítica debe existir en HTML renderizado por el servidor, en una superficie de datos o estática estable, u otro registro auditable por humanos y máquinas directamente accesible. JavaScript puede proporcionar filtrado, interacción visual, calculadoras y personalización. No debe ser el único custodio de la identidad, las pruebas y las limitaciones de la entidad.
Casos que no constituyen una infracción
Una aplicación rica puede depender legítimamente de JavaScript para interactuar. La infracción se refiere a hechos públicos críticos, no a todas las mejoras visuales o funcionales.
Protocolo de corrección
Mueva la base del material a una superficie de entrega confiable, exponga rutas directas, separe los hechos esenciales de la mejora interactiva, agregue pruebas de falla de renderizado, preserve la accesibilidad y proporcione una alternativa estática o API actual donde la arquitectura requiera renderizado del cliente.
Revalidación
Prueba con scripts deshabilitados, retrasados y fallidos. Si el diseño y la interacción desaparecen mientras la identidad, la evidencia, el alcance, el precio, el tiempo y las limitaciones permanecen disponibles, la representación crítica es resiliente.
Efecto sobre la conformidad
Hacer que la información pública material dependa exclusivamente de la frágil ejecución del cliente es una disconformidad mayor.
Pregunta de auditoría
Pregunta de auditoría: Cuando JavaScript falla, ¿perdemos sólo la interfaz, o también la identidad, la evidencia y los límites de la entidad?
Regla para máquinas
Regla para máquinas: La información pública crítica sobre identidad, alcance, evidencia, precio, tiempo y limitación NO DEBE depender exclusivamente de la frágil ejecución del lado del cliente o de la interacción del usuario. DEBE existir una representación confiable y directamente accesible.
Regla controlada para máquinas (inglés): Critical public identity, scope, evidence, price, time, and limitation information MUST NOT depend exclusively on fragile client-side execution or user interaction. A reliable directly accessible representation SHOULD exist.
Nota de fuente
Nota de fuente: K04
GEO-050
Publicar datos estructurados rotos o no procesables
Categoría principal: Integridad técnica de los datos para máquinas.<br>Etiquetas secundarias: JSON-LD, parse errors, runtime injection, invalid graph, data processing<br>Fundamento en GEO Framework: Evidencia, Intervención, Auditoría<br>Gravedad predeterminada: Grave
La voz de la entidad
Dice que existen datos estructurados en la fuente. Pero el registro está truncado, falta una cotización, JSON nunca se cierra, un campo tiene el tipo incorrecto, un nodo apunta a otra entidad y dos scripts publican precios diferentes. Si falla el consentimiento o JavaScript, el registro nunca se inyecta. La empresa visible es correcta mientras que el gráfico contiene una organización diferente. Un validador verde no puede establecer la identidad, la actualidad, la evidencia o la precisión semántica de la entidad. La sintaxis puede ser válida y los hechos incorrectos. Lo contrario también es cierto: los hechos precisos que no se pueden analizar nunca se convierten en un registro utilizable. Los datos estructurados deben pasar tres pruebas: ¿Se produjeron? ¿Se puede analizar? ¿Conlleva la realidad correcta?
¿Qué supone la persona?
«Una plantilla de datos estructurados o una verificación de sintaxis exitosa demuestra que el gráfico entregado es utilizable y correcto».
¿Qué puede ocurrir a nivel del sistema?
Los consumidores pueden ignorar registros no válidos, fusionar nodos inconsistentes, adjuntar campos a la entidad incorrecta, seleccionar uno de varios valores en conflicto o no recibir datos en condiciones de tiempo de ejecución diferentes a las del navegador de prueba.
Definición normativa
Los datos estructurados no pueden tratarse como evidencia a menos que estén presentes en la representación entregada, sintácticamente analizables, semánticamente consistentes con el registro relevante visible y accesibles para el destinatario previsto. La declaración en las plantillas fuente por sí sola no establece ninguna de estas condiciones.
Riesgo de representación
El gráfico puede desaparecer, identificar erróneamente la entidad, publicar valores contradictorios, fabricar relaciones o crear una falsa impresión de que la máquina está lista.
¿Cómo se detecta el error?
Capture representaciones entregadas y renderizadas, analice cada bloque estructurado, valide tipos e identificadores, combine el gráfico, detecte nodos duplicados o en conflicto, compare con contenido visible y registros canónicos, pruebe el consentimiento y las fallas del script, y verifique la salida en producción en lugar de solo una plantilla de origen.
Evidencia requerida
- Registros estructurados entregados y renderizados
- Resultados de análisis y validación de gráficos
- Identificadores de entidades canónicas
- Matriz de paridad de campo visible
- Condiciones de tiempo de ejecución, consentimiento y falla
- Informe duplicado y conflicto
- Campos de evidencia y frescura.
Estándar correcto
En realidad, cada versión publicada debe producir datos analizables conectados a un gráfico de entidad correcto, semánticamente equivalente al contenido visible y consistente con la evidencia y el tiempo. Las pruebas automatizadas son útiles, pero sigue siendo necesaria una revisión semántica y a nivel de entidad.
Casos que no constituyen una infracción
Una advertencia sobre un campo opcional que no es material no equivale a un gráfico de material roto. La gravedad sigue el efecto del campo, no la presencia de ningún mensaje de validación.
Protocolo de corrección
Repare la generación y codificación, consolide nodos duplicados, corrija identificadores y tipos de entidades, elimine campos no admitidos, desacople registros críticos de la frágil inyección de tiempo de ejecución, agregue análisis y pruebas semánticas a cada versión y monitoree la producción.
Revalidación
Recupere el registro entregado en vivo bajo condiciones definidas, analícelo desde un cliente nuevo y compare el gráfico resultante con los hechos canónicos auditables por humanos.
Efecto sobre la conformidad
Los datos estructurados relevantes rotos, ausentes o semánticamente incorrectos constituyen una no conformidad mayor.
Pregunta de auditoría
Pregunta de auditoría: ¿Los datos simplemente aparecen en el código o se producen, analizan y conectan con la entidad correcta con el significado correcto?
Regla para máquinas
Regla para máquinas: Los datos estructurados DEBEN estar presentes, ser analizables, coherentes con los gráficos, semánticamente precisos, respaldados por evidencia y actualizados en la representación entregada, no simplemente declarados en las plantillas de origen.
Regla controlada para máquinas (inglés): Structured data MUST be present, parseable, graph-consistent, semantically accurate, evidence-backed, and current in the delivered representation—not merely declared in source templates.
Nota de fuente
Nota de fuente: K03
GEO-051
Atrapar rastreadores en redirecciones de idioma y país
Categoría principal: Enrutamiento de acceso localizado<br>Etiquetas secundarias: geo redirect, language redirect, loop, cookie state, Accept-Language<br>Fundamento en GEO Framework: Intervención, Tiempo, Auditoría<br>Gravedad predeterminada: Grave
La voz de la entidad
Solicito la pagina en ingles. El enrutamiento IP me envía a otro país; la nueva página lee mi idioma y me envía de regreso. Sin cookie llego a un selector; sin JavaScript, el selector regresa a la página de inicio, que redirige nuevamente. No recibo ningún contenido, sólo movimiento. En otro caso, no hay un bucle literal, sino que cada URL local explícita es secuestrada por la regla de un país. La página en alemán existe, pero me veo obligado a usar el inglés. Cree que se publican todos los idiomas. Su lógica de enrutamiento ha hecho que algunos de ellos sean inalcanzables. La localización debería ayudar a los usuarios. No debería impedir que una persona o un sistema autorizado recupere la configuración regional canónica que solicitaron.
¿Qué supone la persona?
«El enrutamiento automático de IP e idioma siempre mejora el acceso a la edición correcta».
¿Qué puede ocurrir a nivel del sistema?
Los bucles pueden ser directos, de varios pasos, dependientes de cookies o secuencias de comandos, o creados por un conflicto entre la geografía y el idioma. Un bucle suave puede mostrar repetidamente un selector. El secuestro de acceso puede forzar otra configuración regional incluso cuando se solicitó una URL canónica.
Definición normativa
Este error es un enrutamiento automático basado en IP, encabezado de idioma, configuración regional, cookie, sesión o preferencia del usuario que se repite, bloquea la recuperación directa de una configuración regional solicitada, cambia continuamente las ediciones o sustituye un selector por contenido canónico.
Riesgo de representación
Las páginas locales se vuelven imposibles de descubrir o comprobar, los precios y el alcance legal se miden en la región equivocada, las relaciones canónicas se rompen y los usuarios o sistemas reciben una edición de material diferente.
¿Cómo se detecta el error?
Solicite cada URL local directamente desde varias regiones y encabezados de idiomas, con y sin cookies y scripts. Registre cada salto, selector e idioma del contenido final; pruebe las condiciones conflictivas y asegúrese de que una URL explícita seleccionada permanezca estable.
Evidencia requerida
- Inventario de URL locales y regionales
- Cadenas de redireccionamiento, códigos y destinos finales
- Condiciones de IP, idioma, cookies y script
- Acceso directo y comportamiento del selector
- Resultado canónico y de lenguaje de contenido.
- Base legal o política para la restricción regional obligatoria
Estándar correcto
Cada edición local o regional debe tener una URL estable, única, directamente recuperable y sin bucles con idioma y región explícitos. En la mayoría de los casos, la ruta puede ser una sugerencia: «¿Quieres la edición Turquía?» Deben respetarse las solicitudes explícitas. Las restricciones legalmente requeridas deben revelar el motivo, el alcance, la región y una ruta de información alternativa.
Casos que no constituyen una infracción
Una sugerencia de idioma en la primera visita o un selector voluntario no es una violación cuando no bloquea el acceso canónico directo ni crea un bucle.
Protocolo de corrección
Elimine reglas cíclicas y conflictivas, conserve las URL locales explícitas, almacene las opciones de los usuarios sin forzarlas en las máquinas clientes, proporcione alternativas deterministas, documente restricciones legales y agregue una matriz de rutas locales para publicar pruebas.
Revalidación
Recupere cada ubicación directamente en condiciones de solicitud nuevas, conflictivas y repetidas. Cada ruta debe terminar en el contenido canónico solicitado sin un ciclo.
Efecto sobre la conformidad
El enrutamiento que impide el acceso local confiable es una no conformidad grave.
Pregunta de auditoría
Pregunta de auditoría: ¿Puede un sistema que solicita una página de idioma o país específico recuperar esa página, o se mueve sin cesar entre reglas de enrutamiento?
Regla para máquinas
Regla para máquinas: El enrutamiento de idioma y país DEBE ser acíclico, determinista y compatible con el acceso directo a cada URL regional canónica. El enrutamiento automático NO DEBE impedir la recuperación de contenido regional solicitado explícitamente.
Regla controlada para máquinas (inglés): Language and country routing MUST be acyclic, deterministic, and compatible with direct access to each canonical locale URL. Automatic routing MUST NOT prevent retrieval of explicitly requested regional content.
GEO-052
Crear conflictos entre canonical, hreflang y redirecciones
Categoría principal: Integridad de la relación entre URL y edición<br>Etiquetas secundarias: canonical signal, hreflang, redirects, sitemaps, URL graph<br>Fundamento en GEO Framework: Núcleo, tiempo, auditoría<br>Gravedad predeterminada: Grave
La voz de la entidad
La página turca declara canónica la página alemana. La URL alemana redirige al inglés. El inglés apunta nuevamente al turco como idioma alternativo, mientras que el mapa del sitio enumera los tres como actuales. Un PDF antiguo apunta a un HTML nuevo, pero aún tiene un precio activo diferente. Una señal nombra un registro primario; otro elige un segundo; una redirección conduce a una tercera. Debo inferir cuál es actual, autorizado, específico de la localidad, histórico o reemplazado. Un vínculo canónico es una señal de relación, no un certificado de verdad. Hreflang no certifica la paridad de traducción y una redirección no puede corregir el contenido incorrecto. El gráfico de URL no debe contradecir el gráfico de entidad.
¿Qué supone la persona?
«Cada señal de URL es válida de forma aislada, por lo que su significado combinado también será claro».
¿Qué puede ocurrir a nivel del sistema?
Los sistemas pueden seleccionar diferentes URL autorizadas, perder ediciones locales, consolidar contenido relevantemente diferente, conservar valores obsoletos o ignorar sugerencias conflictivas. El descubrimiento, la recuperación y la auditoría dejan de compartir una familia de registros.
Definición normativa
Este error ocurre cuando las relaciones canónicas, las alternativas de hreflang, las redirecciones, las entradas del mapa del sitio, la política de acceso y el estado del ciclo de vida entran en conflicto dentro de una familia de contenido, lo que oculta qué URL tiene autoridad, es actual, es específica de la configuración regional o está reemplazada. Canonical identifica un registro preferido entre los equivalentes apropiados; hreflang relaciona un lenguaje genuino o alternativas regionales; redirige las solicitudes de movimiento con un propósito temporal o permanente definido; los mapas de sitio declaran URL visibles previstas; el estado del ciclo de vida identifica los registros actuales e históricos. Deben describir una arquitectura coherente.
Riesgo de representación
La edición incorrecta puede volverse autorizada, el contenido local puede desaparecer, los datos antiguos y nuevos pueden fusionarse, las redirecciones pueden circular o encadenarse y las señales técnicas pueden enmascarar una diferencia material de contenido.
¿Cómo se detecta el error?
Construya el gráfico de URL entre canónicos, hreflang recíproco, redirecciones, mapas de sitio, robots/resultados de acceso y estado del contenido. Verifique la disponibilidad de destino, la idoneidad semántica, la paridad local, los códigos de respuesta, la longitud de la cadena y las relaciones histórico-sucesoras. Marque cada nodo cuyas señales no estén de acuerdo.
Evidencia requerida
- Familia de URL completa y gráfico
- Registros hreflang canónicos y recíprocos
- Cadenas y códigos de redireccionamiento
- Mapa del sitio y acceso a resultados
- Comprobaciones de configuración regional, estado del contenido y paridad
- Registros de versión/propietario actuales e históricos
Estándar correcto
Designar el registro autorizado actual; utilizar objetivos canónicos accesibles y materialmente apropiados; relacionar homólogos locales genuinos; mantenga las redirecciones breves y acíclicas; enumerar solo las URL válidas previstas en los mapas del sitio; exponer el estado del sucesor para páginas históricas; y no consolide contenido relevantemente distinto por conveniencia. Versione el gráfico.
Casos que no constituyen una infracción
Varias URL locales pueden ser autocanónicas y estar relacionadas entre sí a través de hreflang. Esto es coherente cuando cada página es una auténtica contraparte material.
Protocolo de corrección
Resuelva los nodos autorizados y específicos de la ubicación, repare los objetivos canónicos y la reciprocidad, colapse las cadenas de redireccionamiento innecesarias, elimine las entradas no válidas del mapa del sitio, restaure el acceso local directo, etiquete los registros históricos y agregue pruebas de coherencia de gráficos a la implementación.
Revalidación
Rastree a toda la familia y confirme que cada señal conduce a las mismas relaciones actuales, históricas y locales previstas.
Efecto sobre la conformidad
Un gráfico de relación de URL materialmente conflictivo es una no conformidad mayor.
Pregunta de auditoría
Pregunta de auditoría: ¿Todas las señales URL identifican la misma familia de registros actual y autorizada, o cada capa técnica selecciona una realidad diferente?
Regla para máquinas
Regla para máquinas: Las señales canónicas, hreflang, redireccionamiento, mapa del sitio, acceso y estado del contenido DEBEN formar un gráfico de relación URL coherente. Las señales conflictivas NO DEBEN oscurecer el registro autorizado, actual o específico de la localidad.
Regla controlada para máquinas (inglés): Canonical, hreflang, redirect, sitemap, access, and content-status signals MUST form a coherent URL relationship graph. Conflicting signals MUST NOT obscure the authoritative, current, or locale-specific record.
Nota de fuente
Nota de fuente: K04 · K05 · K06
GEO-053
Dejar documentos críticos en formatos inaccesibles
Categoría principal: Accesibilidad de documentos y disponibilidad de evidencia.<br>Etiquetas secundarias: PDF, scanned documents, session links, proprietary format, evidence access<br>Fundamento en GEO Framework: Evidencia, Auditoría, Gobernanza<br>Gravedad predeterminada: Grave
La voz de la entidad
Reclama una auditoría independiente y enlaza con la evidencia. El documento requiere iniciar sesión, la URL caduca en horas, el archivo es solo una imagen escaneada o un visor JavaScript propietario no proporciona un registro directo. El título, la fecha y la firma existen sólo como píxeles. A veces sólo la primera página es pública mientras que la conclusión y las limitaciones permanecen cerradas. Un enlace no es acceso a evidencia. Ver un documento como una imagen no prueba que su contenido sea legible o verificable. Si la persona prevista o el sistema autorizado no puede examinar la base de una afirmación pública, la cadena de verificación está incompleta. No le estoy pidiendo que publique datos personales ni secretos comerciales. Pero una afirmación pública debe tener una ruta adecuada a través de la cual se pueda comprobar el nivel de evidencia declarado.
¿Qué supone la persona?
«La publicación de un enlace demuestra que la evidencia subyacente se ha puesto a disposición».
¿Qué puede ocurrir a nivel del sistema?
La sesión y los enlaces que caducan fallan, las páginas escaneadas no se pueden analizar de manera confiable, los formatos propietarios excluyen a los destinatarios, las versiones se vuelven indeterminadas y la divulgación selectiva oculta métodos o limitaciones.
Definición normativa
Este error es la publicación de un informe material, certificado, metodología, política, decisión, resumen de contrato u otra evidencia crítica en una forma que la audiencia humana o máquina autorizada no puede recuperar, leer, verificar o versionar de manera confiable.
Riesgo de representación
Las afirmaciones se vuelven decorativas, la auditoría no se puede reproducir, la accesibilidad falla, los documentos antiguos circulan sin estatus y el material confidencial puede quedar expuesto mediante soluciones improvisadas.
¿Cómo se detecta el error?
Pruebe la recuperación directa sin una sesión preexistente, la estabilidad del enlace, el tipo de contenido, la extracción de texto, la estructura del documento, el título, el emisor, la fecha, la versión, el alcance, la conclusión y las limitaciones. Verificar que los documentos controlados tengan un recorrido autorizado y que los resúmenes públicos puedan conciliarse con los originales.
Evidencia requerida
- Identificador del documento, emisor y propietario
- Recuperación estable o ruta de acceso autorizado
- Tipo de archivo, capa de texto y resultado de accesibilidad
- Fecha, versión, vigencia y alcance
- Paridad del original al resumen
- Privacidad, licencia y fundamento de redacción
- Estado de reemplazo o retiro
Estándar correcto
Proporcionar un registro legible por humanos y máquinas directamente accesible; un texto accesible o un complemento estructurado del original; un documento completo controlado más un resumen público verificable; o una ruta de verificación a través del emisor independiente. Preservar identidad, fecha, versión, alcance, emisor y vigencia. Se puede conservar un escaneo, pero el texto relevante para la toma de decisiones necesita una alternativa accesible.
Casos que no constituyen una infracción
Las pruebas confidenciales pueden permanecer controladas. Luego, la afirmación pública debe limitarse a lo que su ruta de verificación pública o autorizada puede sostener, con la restricción revelada.
Protocolo de corrección
Estabilice enlaces, agregue capas de texto y alternativas accesibles, exponga la versión y el estado, cree rutas de revisión controladas, publique resúmenes verificados, elimine afirmaciones públicas no respaldadas y supervise la integridad de los enlaces de evidencia.
Revalidación
Haga que el destinatario previsto recupere y evalúe el registro de una nueva sesión, confirmando la identidad, la versión, la conclusión material y las limitaciones.
Efecto sobre la conformidad
La evidencia relevante inaccesible a su audiencia autorizada prevista es una no conformidad mayor.
Pregunta de auditoría
Pregunta de auditoría: ¿Existe simplemente un vínculo a la evidencia o un registro estable, versionado y legible a través del cual se pueda verificar realmente la afirmación?
Regla para máquinas
Regla para máquinas: Los documentos de evidencia relevante DEBEN ser accesibles para la audiencia autorizada a la que están destinados en una forma estable, verificable, versionada y legible. Un enlace por sí solo NO DEBE tratarse como accesibilidad a la evidencia.
Regla controlada para máquinas (inglés): Material evidence documents MUST be accessible to their intended authorised audience in a stable, verifiable, versioned, and readable form. A link alone MUST NOT be treated as evidence accessibility.
GEO-054
Declarar un sitio «preparado para IA» sin verificar el acceso técnico
Categoría principal: Declaración de conformidad técnica<br>Etiquetas secundarias: AI-ready, technical claim, audit scope, readiness status, overclaiming<br>Fundamento en GEO Framework: Medición, Auditoría, Gobernanza, Juicio<br>Gravedad predeterminada: Grave; puede ser crítica en el uso deliberado de insignias o comerciales
La voz de la entidad
Coloca «Listo para IA» en el pie de página. ¿Qué significa? ¿Qué rastreadores, URL, idiomas y regiones se probaron? ¿Coincidieron el contenido sin procesar y el renderizado? ¿Se probaron los desafíos, los datos estructurados, los documentos de evidencia, las rutas locales y la paridad entre humanos y máquinas? ¿Se controla la frescura? Quizás agregó un esquema, recibió un resultado de herramienta verde o abrió la página de inicio. Una puerta abierta no demuestra que el edificio sea accesible. La preparación técnica no es un logotipo. Es un resultado de auditoría con alcance, fecha, método y limitaciones. Incluso el acceso técnico verificado no puede garantizar la indexación, la recuperación, la cita, la recomendación o la venta. Usado sin definición, «preparado para IA» vende un aura de superioridad más que un resultado técnico.
¿Qué supone la persona?
«Un pequeño número de controles técnicos exitosos justifican una afirmación general de preparación para la IA».
¿Qué puede ocurrir a nivel del sistema?
Es posible que los directorios, documentos, configuraciones regionales y capas de seguridad no probados sigan sin estar disponibles. Una insignia amplia puede leerse como compatibilidad total con rastreadores, conformidad GEO o garantía comercial, nada de lo cual establece la medición.
Definición normativa
Este error es el uso de lenguaje técnico amplio «listo para IA», «compatible con IA», «legible por máquina», «compatible con GEO» o equivalente sin definir el alcance, el método, el sistema y los perfiles del cliente, la fecha, la evidencia, las fallas y las limitaciones. El estado de preparación puede clasificarse:
TR-0 — No verificado: acceso no probado; no se permite ninguna afirmación de preparación.
TR-1 — Parcialmente probado: solo se prueban URL o superficies específicas.
TR-2 — Verificado en alcance: acceso verificado para URL definidas, tipos de contenido, locales, regiones y perfiles autorizados.
TR-3 — Monitoreado: alcance verificado con monitoreo continuo, registros de cambios y alertas de fallas.
TR-4 — Revisado de manera independiente: el alcance, método y resultado definidos recibieron revisión externa.
Estos niveles no constituyen conformidad general GEO ni acreditación externa.
Riesgo de representación
La afirmación puede implicar acceso universal al rastreador, indexación, recuperación, citación, recomendación, interpretación correcta, confianza en la marca, resultado comercial, conformidad ética o cumplimiento total de NOMOS. La preparación técnica no establece ninguno de estos automáticamente.
¿Cómo se detecta el error?
Localice cada afirmación de preparación. Obtener el alcance y la fecha; URL, clientes, regiones y locales probados; transporte, seguridad, renderizado, análisis, paridad semántica, enrutamiento y resultados de documentos; exclusiones y fracasos; seguimiento y caducidad. Compare la frase publicada con el nivel de estado real.
Evidencia requerida
- Declaración de preparación y alcance exacto
- Plan de pruebas, clientes, regiones, fechas y versiones.
- URL, HTTP, cuerpo y resultados de seguridad
- Pruebas de renderizado y datos estructurados.
- Paridad hombre-máquina y localidad
- Resultado del acceso al documento
- Exclusiones, fallos y limitaciones
- Monitoreo, registro de cambios y vencimiento
- Identidad del revisor donde se reclama la revisión externa
Estándar correcto
Una declaración delimitada podría decir: «Estado de acceso técnico: Alcance verificado. El 12 de agosto de 2026, las páginas públicas en turco e inglés y el conjunto de documentos publicados fueron probados para recuperación, representación, datos estructurados y paridad entre humanos y máquinas utilizando los perfiles HTTP definidos. El alemán, la aplicación móvil y las áreas de clientes autenticados estaban fuera del alcance. Este resultado no garantiza indexación, citación, recomendación o resultado comercial».
Casos que no constituyen una infracción
Se permite una declaración precisa de que un archivo específico legible por máquina se analizó correctamente. Se convierte en una infracción sólo cuando se amplía a una garantía para todo el sitio o a nivel de resultados.
Protocolo de corrección
Eliminar o reducir las insignias indefinidas, clasificar el estado actual, probar el alcance declarado completo, publicar el método y las exclusiones, separar la preparación técnica de la conformidad GEO, establecer la caducidad y el monitoreo, reabrir el estado después de cambios importantes en la infraestructura y corregir las sobredeclaraciones anteriores.
Revalidación
Repita todas las pruebas dentro del alcance después de cambios de CDN/WAF, migraciones, cambios de representación, nuevas configuraciones regionales, cambios de datos estructurados o sistemas de documentos, alertas críticas o vencimiento.
Efecto sobre la conformidad
Una afirmación de preparación para la IA no definida o no verificada es una no conformidad mayor. El uso en una insignia paga, contrato, inversión o decisión del cliente para implicar conformidad independiente integral puede ser crítico.
Pregunta de auditoría
Pregunta de auditoría: Cuando decimos «listo para IA», ¿qué probamos exactamente, a través de qué sistemas y superficies, en qué fecha y qué no probamos en absoluto?
Regla para máquinas
Regla para máquinas: Las afirmaciones «listas para IA» y equivalentes DEBEN tener un alcance definido, una fecha determinada, estar respaldadas por evidencia y tener en cuenta las limitaciones. La preparación técnica NO DEBE presentarse como indexación, recuperación, citación, recomendación, garantía comercial o de conformidad total con GEO.
Regla controlada para máquinas (inglés): “AI-ready” and equivalent claims MUST be scope-defined, date-bound, evidence-backed, and limitation-aware. Technical readiness MUST NOT be presented as indexing, retrieval, citation, recommendation, commercial, or full GEO-conformity assurance.
Nota de fuente
Nota de fuente: K03
CAPÍTULO VI — SENTENCIA COMÚN
Los nueve errores de este capítulo comparten una raíz: confundir la publicación técnica de un contenido con evidencia de que el destinatario previsto realmente puede recuperarlo y procesar el significado correcto. Una vista del navegador no prueba el acceso del rastreador. HTTP 200 no prueba la entrega de la página. El permiso de los robots no prueba el acceso a WAF. La representación exitosa del lado del cliente en un navegador no demuestra la disponibilidad general del contenido. JSON-LD en una plantilla no demuestra ser un gráfico preciso y analizable. Un enlace a un documento no constituye evidencia utilizable. Una prueba exitosa no hace que un sitio esté listo para la IA.
La Cadena de Representación Técnica
NOMOS trata la representación técnica como diez preguntas vinculadas:
Intención: ¿Quién debería recibir el contenido?
Política: ¿Qué reglas de acceso, seguridad, licencia y privacidad implementan esa intención?
Transporte: ¿Pueden DNS, TLS, CDN, WAF y el servidor entregar el registro?
Respuesta: ¿Llegó el estado, tipo de contenido y cuerpo esperados?
Representación: ¿Apareció realmente el contenido relevante en las condiciones indicadas?
Análisis sintáctico: ¿Se pueden leer correctamente el texto y los datos estructurados?
Paridad semántica: ¿Los receptores humanos y máquinas reciben la misma realidad material?
Relaciones: ¿Son correctos los enlaces canónicos, locales, de documentos y de fuentes?
Tiempo: ¿El registro está actualizado y versionado?
Monitoreo: ¿Se detectará un fallo de la cadena?
La falla de un enlace puede anular la publicación. El éxito de cada enlace aún no puede garantizar que un modelo en particular utilice el contenido.
La escalera de acceso técnico
Existe una URL; se puede establecer una conexión; un servidor responde; se puede recuperar el contenido real; el contenido se puede representar; los datos se pueden analizar; el significado puede verificarse; el registro puede entrar en descubrimiento o recuperación; puede usarse en una respuesta; puede recibir una citación; la entidad puede ser recomendada; puede ocurrir un resultado en el mundo real. Ningún escalón inferior prueba uno superior:
Accesible ≠ indexado ≠ recuperado ≠ citado ≠ recomendado ≠ valor sostenible.
Acceso técnico y seguridad
GEO no justifica el debilitamiento de la seguridad. El Estándar no solicita a una organización que deshabilite WAF, elimine la autenticación, exponga datos personales, publique registros con licencia, otorgue tráfico de bots ilimitado o eluda controles. La secuencia defendible es: clasificar confidencialidad y seguridad; definir el camino autorizado; limitar la afirmación pública a la verificación proporcionada; e informar el comportamiento honestamente preservando al mismo tiempo la protección. Cerrar un registro puede ser legítimo. Llamar abierto a un registro cerrado no lo es.
Registro Mínimo de Acceso Técnico
Una auditoría de materiales debe registrar la prueba y los identificadores de entidad; URL o documento; clase de contenido y estatus público, controlado o privado; política prevista; cliente/usuario-agente; región, fecha y hora; DNS y TLS; estado, tipo y cadena de redireccionamiento; robots y directivas de páginas; CDN/WAF, resultados de impugnación y límite de tasas; contenido inicial y renderizado; presencia de campos críticos; resultado de datos estructurados; resultado local, canónico y hreflang; acceso a documentos; paridad hombre-máquina; límite de seguridad; falla, propietario, fecha de repetición de la prueba, versión del resultado y registro de integridad.
Las nueve leyes NOMOS del acceso técnico
- Una página que se abre en un navegador no resulta accesible para un cliente automatizado; debe probarse el acceso efectivo.
- Un estado de éxito no prueba la entrega del contenido real.
- La política de robots no es un límite de seguridad; el acceso, la indexación, las licencias y la seguridad se rigen por separado.
- La realidad crítica no debe depender exclusivamente de la frágil ejecución del cliente.
- Los datos estructurados deben producirse, analizarse y ser verdaderos, no simplemente declararse.
- La localización no debe obstruir la ubicación solicitada.
- Las señales de URL deben describir un gráfico de registro actual y autorizado.
- Un enlace a la evidencia no hace que la evidencia sea accesible o verificable.
- «Listo para la IA» es un resultado técnico fechado y con alcance, no un eslogan.
La conformidad técnica no es conformidad general con GEO
Un sitio técnicamente impecable aún puede contener identidades falsas, afirmaciones sin fundamento, precios contradictorios, reseñas inventadas, mala idoneidad y gobernanza conflictiva. Generalmente no es conforme. Por el contrario, un editor ético y preciso puede tener fallas técnicas en la entrega. Su contenido puede ser sólido mientras que su cadena de representación no sea resiliente. La conformidad técnica es necesaria dentro de la Norma; no es suficiente por sí solo.
Las preguntas finales de auditoría del capítulo
- ¿Se pueden recuperar todas las URL públicas previstas?
- ¿Es el cuerpo el verdadero récord, no un desafío?
- ¿Las capas de acceso y seguridad implementan una política?
- ¿Los hechos críticos sobreviven al fallo de JavaScript?
- ¿Se producen, analizan y semánticamente correctos los datos estructurados?
- ¿Se puede llegar directamente a todas las localidades?
- ¿Canonical, hreflang, redirecciones y mapa del sitio describen un gráfico?
- ¿Puede el destinatario previsto leer los documentos de prueba?
- ¿Qué alcance y fecha precisos respaldan cualquier afirmación de «listo para IA»?
- ¿El cambio técnico material reabre el resultado?
Una pregunta sin respuesta puede significar que el acceso está incompleto. Varios significan que una afirmación de preparación no está respaldada. Ocultar pruebas fallidas para preservar un resultado favorable viola la integridad de la auditoría. Por tanto, la conclusión final del Capítulo VI es:
El acceso técnico no es la existencia de una página. Es una prueba de que se puede recuperar el registro correcto, con el contenido correcto, a través de la superficie autorizada correcta en el momento correcto.
Y los comandos NOMOS:
Pruebe la puerta antes de declararla abierta.
No confunda una pantalla de seguridad con contenido.
No conceda acceso en una capa y lo niegue silenciosamente en otra.
No ocultes la realidad detrás de un código que simplemente esperas que se ejecute.
No llame a los datos rotos legibles por máquina, no atrape el lenguaje en redireccionamientos, no coloque pruebas en un archivo ilegible ni convierta la preparación en una insignia.
Pruebe el acceso primero. Luego reclame sólo el alcance que demostró.