Servire i file di verifica all’edge: ads.txt, security.txt, AASA e assetlinks.json
Alcuni file devono vivere nella root o sotto /.well-known/. Se CMS o store rendono la cosa scomoda, una risposta edge può servirli con status e Content-Type corretti.
La parte difficile dei file di verifica quasi mai è il contenuto. È il path.
Ad ops vuole ads.txt nella root. Security vuole security.txt sotto /.well-known/. Mobile ha bisogno di apple-app-site-association. Android ha bisogno di assetlinks.json. Un CMS, uno store o un site builder possono andare benissimo per le pagine normali e fallire proprio su quelle URL.
Così un file piccolo blocca un launch, una validazione app o una migrazione.
Se stai lavorando su Universal Links o Android App Links, tieni vicino Come configurare Universal Links e App Links dopo Firebase. Qui il focus è sul servire i file.
Il problema della root e di .well-known
Questi file sono piccoli, ma le piattaforme che li verificano sono rigide.
Errori tipici:
- il CMS non permette file nella root
/.well-known/viene catturato dal router- un redirect entra prima del file
- il Content-Type è sbagliato
- nessuno è owner del file dopo il lancio
L’edge aiuta perché può rispondere direttamente sul path richiesto, senza trasformare tutto il sito in un progetto infrastrutturale.
Ogni file ha un contratto diverso
ads.txt e app-ads.txt
Servono a trasparenza pubblicitaria e inventory control. Devono essere facili da leggere:
- path diretto
- risposta
200 - testo semplice
- owner chiaro
Se il file finisce dietro redirect, login o fallback del CMS, una verifica può fallire.
security.txt
security.txt indica come contattare l’organizzazione per una vulnerabilità. In molte aziende la responsabilità si divide tra web, security, legal e platform.
Una risposta edge rende chiari path, body, Content-Type e owner.
apple-app-site-association
I Universal Links Apple dipendono dal file AASA al posto giusto. Se il file non arriva correttamente, si finisce spesso a debuggare l’app mentre il problema è nell’URL del file.
assetlinks.json
Android App Links ha bisogno di un assetlinks.json valido. Se manca, è vecchio o viene riscritto dal builder, la verifica del dominio diventa instabile.
Cosa deve fare bene la risposta edge
Non deve essere intelligente. Deve essere precisa.
| File | Path tipico | Requisito | Errore comune |
|---|---|---|---|
ads.txt | /ads.txt | 200, testo, contenuto stabile | metterlo dietro redirect o login |
app-ads.txt | /app-ads.txt | 200, testo, inventory app | dimenticare che l’app ha inventario suo |
security.txt | /.well-known/security.txt o /security.txt | 200, testo, contatti aggiornati | root senza owner |
apple-app-site-association | /.well-known/apple-app-site-association o /apple-app-site-association | 200, JSON, body esatto | Content-Type o path sbagliato |
assetlinks.json | /.well-known/assetlinks.json | 200, JSON, body esatto | route riscritta dal CMS |
Se una piattaforma chiede un path esatto diverso, segui la sua documentazione. Il punto è mantenere il contratto verificabile.
Non nascondere questi file dietro redirect
Per i file di verifica, diretto è di solito meglio.
Un hop in più crea un punto di failure in più. Complica anche il debug quando una verifica va bene un giorno e male il giorno dopo.
Usa redirect solo se il consumer lo accetta esplicitamente. Altrimenti, servi il file direttamente.
Definisci ownership
Questi file si rompono perché dopo il lancio nessuno li sente davvero propri.
Un modello pratico:
- ad ops possiede
ads.txteapp-ads.txt - mobile engineering possiede AASA e
assetlinks.json - security o platform possiede
security.txt - web/platform possiede path, status e Content-Type
Quando cambi CMS, dominio o app, questa chiarezza evita giorni di rincorsa.
Flusso operativo
- scegliere il path esatto di ogni file
- definire body e Content-Type
- servire direttamente dall’edge
- documentare owner e review date
- testare con il consumer reale, non solo dal browser
È utile quando non vuoi aprire un deploy del sito per un file root.
Dove entra UrlEdge
Il Custom Response Tool di UrlEdge può servire risposte testo o JSON direttamente dall’edge.
È utile quando:
- l’origin gestisce male root o
.well-known - serve una risposta
200diretta - Content-Type e body devono essere controllati
- il dominio usa già UrlEdge per redirect o routing
Non sostituisce tutta la stack di deep link. Riduce la frizione del file hosting.
FAQ
Questi file devono stare sull’origin?
No. Devono essere disponibili sul path atteso. Se l’origin non lo fa bene, l’edge è una soluzione pratica.
Posso fare redirect?
Solo se la piattaforma che verifica lo consente. Una risposta diretta è di solito più robusta.
Perché non lasciarlo al CMS?
Molti CMS funzionano bene per le pagine e male per root o /.well-known/. È questa la lacuna.
È solo per mobile app?
No. AASA e assetlinks.json riguardano le app, ma ads.txt, app-ads.txt e security.txt riguardano advertising e security.
Riferimenti
Servi i file di verifica senza toccare l’origin
Pubblica file root e .well-known dall’edge con status, Content-Type e ownership chiari.
Esplora le edge responsesArticoli correlati
Visualizza tutto
www, apex e wildcard forwarding senza rompere il SEO
La normalizzazione dell’host sembra semplice finché root domain, www, subdomain, path e query string seguono regole diverse. Una policy chiara mantiene stabile la URL canonica.
Link firewall per traffico paid e affiliate: filtra bot, proxy e clic sospetti
Non ogni clic sospetto è frode, ma ogni clic sospetto può far saltare budget, attribuzione e report partner. Un link firewall decide cosa succede prima che il traffico arrivi alla destinazione.