Salieron al ordenar la taxonomía del EN, y son los dos visibles:
1. el H1 del archivo de tag sale del campo `name`, y en el EN los siete tags
se llamaban COMO SU SLUG: /tag/military-cases/ le enseñaba
«military-cases» al lector, con el <title> correcto justo encima. El ES
enseñaba «Casos Militares». Siete páginas indexadas con un slug de titular.
2. `uap` e `investigation` tenían el MISMO meta_title — dos archivos
compitiendo en el SERP con el mismo titular.
Los nombres no se inventaron: salían del meta_title que cada tag ya tenía, o
sea de una decisión editorial que estaba en el campo equivocado. Slugs
intactos: `--name` y `--new-slug` son opciones distintas, así que las siete
URLs siguen dando 200 y no hace falta ninguna redirección.
Renombrar era IMPOSIBLE hasta esta mañana: researchowl casaba los tags por
NOMBRE, así que esto habría creado siete duplicados `-2`. Se pudo porque el
commit 3d8cba6 los pasó a resolver por slug→id.
El detector de «nombre == slug» exige un guion a propósito: `uap` llamándose
«uap» no se lee como slug crudo y marcarlo sería un falso positivo. Hay test.
Y un fallo del propio fichero de tests, encontrado al añadir estos: el bloque
`if __name__ == "__main__"` estaba en MEDIO, así que los tests definidos
después no entraban en globals() y no corrían nunca — pasaban en verde sin
ejecutarse. Movido al final.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Recuento de los fallos de esta semana: diecisiete. Ni uno solo fue un caso que
el vigilante juzgara mal — los diecisiete estaban en sitios donde el vigilante
no mira. Eso es una buena noticia: los puntos ciegos son enumerables y el
juicio equivocado no.
Lo que no miraba nadie, con el fallo real que lo motiva:
tags 5 duplicados vivieron TRES SEMANAS repartiendo 7 posts entre dos
archivos flacos, los dos ofrecidos a Google en sitemap-tags.xml
páginas todas las reglas eran de posts; /about no tiene metas en ninguno
de los dos sitios
<head> el EN emite DOS Article con titulares distintos, y sigue con
twitter:site=@ghost y article:publisher=facebook.com/ghost
robots.txt el bloque «Cloudflare Managed» apareció solo en el EN y nadie lo
decidió; cambia sin pasar por git
hreflang lo comprobaba SOLO seo_audit.py, que NO TIENE TIMER
hub se publicó una vez y se pudrió: «31 casos» con 33
programados check_rules hace `if status != "published": continue`, así que un
programado con la meta mal es invisible hasta el día DESPUÉS de
publicarse — cuando ya lo ha visto Google
Decisiones:
- módulo aparte y no dentro de seo_watch.py (ya pasa de 500 líneas), pero
colgando del MISMO vigilante: una huella por sitio y un solo aviso. Dos
notificadores compitiendo es como se deja de leer un informe
- robots.txt se compara contra una INSTANTÁNEA versionada. Sin una foto
contra la que comparar, un cambio que nadie hizo es invisible para siempre
- un chequeo que revienta se convierte en HALLAZGO, no tumba a los demás. Lo
peligroso de un vigilante no es que falle: es que falle y parezca limpio
- og_*/twitter_* vacíos en una PÁGINA quedan fuera por COMPROBACIÓN, no por
comodidad: Ghost los deriva de las metas al renderizar, verificado sobre el
HTML público del hub ES. Avisar de eso sería mandar a arreglar algo que ya
está bien
Timer semanal → DIARIO. Con 2 posts/semana más programados y deriva de tema y
robots, el lunes dejaba hasta seis días de exposición. No añade ruido: solo
avisa si hay hallazgos Y han cambiado, así que un día limpio no manda nada.
8 tests, cada uno la cicatriz de un fallo real, incluidos los dos que hacen
creíble a un vigilante: que DETECTA la avería (probado con deriva simulada de
robots) y que un chequeo roto se oye.
Primera ejecución real: 8 hallazgos, todos preexistentes, 32 s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
