Aggiornamento prodotto KENSAI: 3 nuove regole di rilevamento, fix della sitemap e pubblicazione multilingue in giornata

KENSAI ha rilasciato tre nuove regole di scansione, corretto l’accesso alla sitemap che bloccava i crawler e irrigidito il flusso multilingue per mantenere allineati i post pubblicati nello stesso giorno in tutte le lingue supportate.

Cosa è stato rilasciato oggi

L’aggiornamento di oggi è molto semplice: rilevamento migliore, publishing più pulito e crawlability migliore. Abbiamo stretto tre parti della pipeline KENSAI che stavano creando attrito tra ricerca, pubblicazione e visibilità sui motori di ricerca.

Il risultato è meno vistoso di una nuova dashboard, ma molto più utile: più findings intercettati automaticamente, meno disallineamenti silenziosi tra gli indici locali e sitemap che i crawler possono finalmente recuperare senza problemi.

1) Copertura di rilevamento ampliata con tre nuove regole

Lo scanner ha ricevuto tre nuove regole estratte da pattern reali: credenziali hardcoded nel codice o nella configurazione, esposizione di dati sensibili in risposte pubbliche e una regola composta CORS più information disclosure per endpoint che perdono dati e allo stesso tempo si fidano delle origini sbagliate.

Abbiamo inoltre incluso pattern osservati su bucket S3 listabili e su telemetria o materiale di chiavi esposto nelle risposte frontend. Sono proprio quei problemi che continuano a comparire in produzione, sfuggono alle verifiche manuali e poi diventano una figuraccia costosa.

2) La pubblicazione multilingue in giornata è ora più rigorosa

Abbiamo ripulito la logica di freshness del blog e il percorso di sincronizzazione delle locale per evitare che i post del giorno divergano tra indice inglese e indici tradotti. La regola è volutamente dura: se esiste il post inglese, deve esistere nello stesso giorno anche il corrispondente post locale nel suo indice dedicato.

Sembra ovvio, ma l’automazione rotta ama fallire sulle regole ovvie. Una disciplina più severa sugli indici riduce i mismatch nelle pagine overview, mantiene i blog localizzati più freschi ed evita il fallimento SEO più stupido possibile: pubblicare contenuti e poi nasconderli alle proprie pagine di lingua.

3) Accesso alla sitemap per i crawler riparato

Abbiamo anche corretto un vero autogol SEO. Le URL della sitemap restituivano 403 perché il server web non riusciva a attraversare una parte del percorso filesystem sotto la root del workspace. Una volta corretto quel problema di permessi, gli endpoint sitemap verificati sono tornati a rispondere 200.

È esattamente il tipo di bug che dall’interno dell’app sembra innocuo e dall’esterno distrugge silenziosamente la reperibilità. Se la sitemap è bloccata, il ritmo di pubblicazione smette di contare perché i crawler non ricevono mai l’inventario pulito degli URL.

Perché conta

I prodotti di sicurezza vincono sulla fiducia, non sull’estetica. Conta la qualità del rilevamento. Conta l’affidabilità della pubblicazione. Conta la crawlability. Se una di queste cose si rompe, si lavora di più per ottenere risultati peggiori.

Le modifiche di oggi rendono la pipeline più onesta: i findings di ricerca si trasformano più facilmente in regole riutilizzabili, i post hanno meno probabilità di restare mezzi pubblicati tra le lingue e i motori di ricerca ricevono i file che si aspettano.

Cosa arriva dopo

Prossimo passo: continuare ad ampliare il rilevamento partendo da findings reali, continuare a chiudere i gap di traduzione e coerenza degli indici e continuare a rimuovere i piccoli errori infrastrutturali che sabotano la distribuzione. L’impianto noioso è quasi sempre dove si nasconde la leva vera.