Scaricare i siti web che utilizzano Strapi

In un censimento tecnologico, la prima cosa da capire sulla piattaforma Strapi è che il prodotto è costruito per essere invisibile. Un sistema di contenuti headless funziona come backend. I redattori lavorano in un pannello di amministrazione, i contenuti escono attraverso un’API e ciò che genera il sito pubblico è un’applicazione separata, che può essere scritta in qualunque framework, nessuno escluso. Niente obbliga un front end a dichiarare che cosa lo alimenta, per cui un censimento basato sul rilevamento legge un sistema headless attraverso effetti collaterali, e non attraverso una firma che la piattaforma stampa sulla pagina.

In pratica identifichiamo Strapi dalle tracce che un’installazione lascia quando non è del tutto disaccoppiata. File multimediali serviti dal percorso di upload del backend, una route API esposta su un sottodominio, un pannello di amministrazione raggiungibile nella posizione predefinita, un endpoint di anteprima o di plugin lasciato aperto. Ognuno di questi elementi è una prova reale. Nessuno di essi è presente per forza, e un’istanza installata con cura dietro una build statica e una CDN può non lasciare assolutamente nulla. Qualsiasi numero associato a un prodotto headless va letto in questa luce, e il nostro è una stima per difetto, non una misura del mercato.

Una volta dichiarato apertamente questo limite, avere la popolazione resta comunque utile. A novembre 2026 vediamo Strapi su 2130 siti. Il prodotto è sviluppato da Strapi Solutions, è distribuito con licenza Open Source, è scritto in JavaScript e risale al 2015, il che lo colloca tra i sistemi arrivati quando i team hanno cominciato a separare la pubblicazione dalla presentazione come scelta predefinita e non come esperimento. Un sito che usa Strapi dice diverse cose contemporaneamente. C’è di mezzo un team di sviluppo o un’agenzia, perché uno stack headless non è qualcosa che un responsabile marketing installa un venerdì pomeriggio. Il modello dei contenuti è stato progettato, non ereditato da un tema. E l’organizzazione ha scelto un backend per i contenuti che può far girare sui propri server o sul cloud gestito del fornitore, il che è una scelta di acquisto tanto quanto una scelta tecnica.

È questo profilo a rendere l’esportazione commercialmente utile. I fornitori di hosting e di piattaforme vogliono le installazioni self-hosted, perché sono proprio il bacino che un’offerta di cloud gestito punta a convertire. I fornitori di componenti e di API vogliono i front end collegati a quei backend, che diventano visibili solo incrociando l’elenco con i rilevamenti dei framework presenti nello stesso file. Le agenzie e i ricercatori di sicurezza vogliono i siti in cui un pannello di amministrazione o un’API si trova in un percorso predefinito, perché questo è al tempo stesso un’occasione di vendita e un risultato da segnalare. Una ricerca per singolo dominio non risponde a nessuna di queste esigenze, perché ognuna è una domanda su un insieme e non su un singolo dominio.