Resumen

  • El sitemap de AFRINIC contiene entradas separadas para /news y /privacy, y ambas páginas responden con contenidos propios.
  • La página de noticias devolvió HTTP 200 con título, H1, listado de 2026 y JSON-LD de noticias; no es una página caída ni sustituida.
  • Su canonical, descripción, metadatos Open Graph y título de Twitter identifican en cambio la política de privacidad.
  • La prueba exige corregir y registrar la identidad de la ruta, pero no permite afirmar que un buscador la desindexó, que perdió tráfico o que una red social mostró una tarjeta equivocada.

Dos filas separadas, una preferencia equivocada

El sitemap público de AFRINIC enumera una ruta de noticias y otra de privacidad. Esa separación es coherente con lo que encuentra un lector. En News & Announcements, el título de la pestaña y el encabezado visible dicen «News & Announcements». El cuerpo abre un archivo de anuncios de 2026 y muestra asuntos institucionales recientes.

La Privacy Policy es otra página. Su título, su encabezado y su canonical se refieren a la política de privacidad. Las dos rutas respondieron HTTP 200 durante la observación del 31 de agosto.

El conflicto aparece al mirar la preferencia declarada por la primera. La página de noticias pone como canonical https://afrinic.net/privacy.html. Su descripción habla de la política de privacidad. Los títulos y las URL de Open Graph apuntan a esa misma política, y el título Twitter también la nombra.

El sitemap conserva dos objetos. El canonical de uno pretende preferir el otro.

Disponibilidad, identidad y efecto no son el mismo dato

La disponibilidad está clara. La ruta de noticias respondió 200, tenía un H1 correcto y entregó una lista sustantiva. El JSON-LD también la llamaba News & Announcements y usaba una URL de noticias. No hay base para decir que el archivo público estuviera inaccesible.

La identidad declarada en otros campos también está clara, pero es distinta. Canonical y metadatos sociales no describían noticias. Un control que solo comprueba el código HTTP concluiría que todo funciona. Otro que solo comprueba que existe un canonical también pasaría. Ambos perderían la contradicción semántica.

El efecto externo, en cambio, permanece abierto. No se consultó aquí una consola de búsqueda, ni una caché de red social, ni una serie de tráfico. La fuente demuestra qué instrucciones estaban publicadas; no demuestra qué hizo cada aplicación con ellas.

Esa separación evita convertir un fallo verificable en una consecuencia imaginada.

Lo que la relación canonical realmente afirma

El RFC 6596 describe canonical como la relación con una versión preferida entre recursos de contenido duplicado. La página objetivo debe duplicar el contenido de la página de origen o contenerlo como parte de un conjunto más amplio.

Las dos páginas capturadas no cumplen esa relación por su función pública. Una reúne anuncios; la otra establece una política de tratamiento de datos. Tienen encabezados y cuerpos distintos. Que una etiqueta las una no vuelve duplicados sus contenidos.

El RFC explica que aplicaciones como los buscadores pueden concentrar el procesamiento en la dirección canonical. Pero también contempla que una declaración incorrecta sea ignorada y que la aplicación use sus propias heurísticas. Canonical tampoco es una redirección. Por eso el titular correcto trata de una declaración de identidad, no de una desindexación comprobada.

La reparación puede medirse en la fuente: cambiar la relación por la dirección que represente realmente las noticias y documentar la versión corregida. La recuperación externa necesitaría evidencia adicional y otro reloj.

Open Graph abre un segundo conflicto

El protocolo Open Graph define og:title como el título del objeto y og:url como la URL canónica que funciona como su identificador permanente en el grafo. En el HTML de noticias, ambos describen la política de privacidad.

Eso importa porque la identidad social no tiene por qué seguir el mismo tratamiento que la identidad de búsqueda. Una plataforma puede usar Open Graph, otra puede combinar valores y otra puede conservar una caché antigua. La fuente revela una entrada incorrecta; no una salida observada.

El JSON-LD añade una señal opuesta: continúa presentando una página de noticias. La página no carece de información para máquinas. Posee demasiadas respuestas incompatibles. El problema de control consiste en compararlas entre sí.

Un recibo de identidad por ruta

AFRINIC no necesita borrar ninguna de las dos páginas. Necesita que cada ruta conserve un recibo pequeño y versionado que diga qué objeto se aprobó.

Ese recibo debería unir la URL solicitada y la final con el papel del contenido; título y H1; canonical y justificación de duplicidad o conjunto superior; descripción; Open Graph y Twitter; tipo, nombre y URL de los datos estructurados; presencia en el sitemap; versión o huella del despliegue; resultado de la validación; excepciones; y una historia de correcciones.

La prueba decisiva es de significado. La pregunta no es solo si el destino canonical existe, sino si representa el mismo objeto. Tampoco basta con encontrar og:title; debe nombrar la misma página que el H1 y el cuerpo.

Cuando se publique una corrección, el recibo debe guardar huellas del antes y del después. Así una tarjeta antigua o una caché tardía no se confundirá con la fuente nueva. La fecha de Last-Modified de la representación actual no debe usarse como fecha de inicio del problema: muestra cuándo cambió el archivo servido, no cuándo nació cada valor.

Una noticia sobre control, no sobre daño supuesto

El hallazgo es pequeño en superficie y grande en método. Una institución que publica actas, consultas y comunicados depende de que esas páginas sean identificables tanto para lectores como para sistemas automáticos. El retorno 200 conserva acceso; la identidad incorrecta debilita la trazabilidad de cómo se descubre y comparte ese acceso.

La respuesta proporcional consiste en reconocer las dos cosas. La página de noticias funciona. Su identidad automática no concuerda con ella. Corregir la segunda no exige negar la primera, y verificar la reparación no exige atribuir daños que todavía no se midieron.

Fuentes