Come capire se il software del tuo concessionario è pronto per l'era degli agenti AI

MILANO — La domanda di partenza si può scrivere in diciassette caratteri, e la si può fare con uno strumento che esiste dal 1996, gratuito, installato di default su ogni Mac e su ogni Linux. Si chiama curl. Si digita curl -I seguito dal dominio di un sito, e la macchina restituisce gli header HTTP che il server mette nei propri pacchetti di risposta. Fra quegli header ce n'è uno che si chiama «Server», ed è pubblico per definizione: il sito stesso lo dichiara a chiunque lo interroghi. Per chi sceglie un software per il proprio concessionario, quella riga è un'informazione utile da leggere — dieci minuti prima della firma — quanto qualunque voce del contratto.

Per scrivere questa guida abbiamo osservato il mercato italiano del software per concessionari indipendenti lungo sei dimensioni misurabili — le stesse che un dealer può controllare da sé: stack tecnico, sicurezza HTTP, accessibilità mobile, fondamenti SEO, dati strutturati Schema.org e architettura del prodotto. I segnali AI più recenti (llms.txt, C2PA, MCP) sono trattati a parte, in forma qualitativa: nati dopo il 2024, è corretto non usarli per giudicare piattaforme costruite anni prima. L'obiettivo non è la pagella di un fornitore, ma una griglia di lettura riutilizzabile su qualunque prodotto.

Sei dimensioni, una griglia di autovalutazione

Sei dimensioni: stack & runtime, sicurezza HTTP, mobile/accessibility, SEO, dati strutturati, architettura. Segnali AI futuri valutati a parte. Sotto, come si posiziona DealerMax sulla stessa griglia — e gli archetipi tecnici che ricorrono nel settore, descritti senza riferirli ad alcun fornitore.

Il pattern più diffuso: un CMS multi-tenant sotto il marketing «SaaS»

Il pattern tecnico più ricorrente nel settore, anche fra operatori grandi e strutturati, è un sito generato da un CMS generico (tipicamente WordPress) con un page builder visuale e un tema multi-tenant condiviso fra tutti i clienti. È una scelta legittima e molto comune, ma è bene saperla riconoscere: il prodotto descritto a marketing come «piattaforma SaaS web ready-to-use» può, sotto al cofano, coincidere con un CMS off-the-shelf.

Come si riconosce, da soli, in trenta secondi. Il meta tag generator nel codice sorgente spesso dichiara il page builder usato; la presenza ricorrente di percorsi come wp-content indica una base WordPress; e gli endpoint diagnostici standard di quel CMS — /wp-json/, /wp-login.php, /wp-admin/ — quando rispondono, confermano l'impianto. Sono tutti segnali pubblici, leggibili da chiunque, senza accesso privilegiato.

Va detto con equilibrio: questo archetipo non è sinonimo di bassa qualità. Spesso la parte di sicurezza HTTP è curata — security headers OWASP completi (Content-Security-Policy, Referrer-Policy e affini) indicano un team competente. Il limite è architetturale: un page builder appoggiato a un CMS multi-tenant è più rigido di una piattaforma costruita su misura quando si tratta di dati strutturati, performance e leggibilità dagli agenti AI. Per il dealer — e per chi valuta il settore — è una distinzione di sostanza, non di marketing.

Un pattern di settore, non un caso isolato

Vale la pena ribadire un punto, perché è ciò che rende questa griglia utile al dealer: il pattern «CMS generico + page builder dietro un brand SaaS» non è un'eccezione, è la configurazione più comune nel mercato italiano dei siti per concessionari, dalle vetrine indipendenti ai gruppi multi-brand strutturati.

Lo stesso tema ricorre su clienti molto diversi. La medesima base tecnica — stesso page builder, stessa versione, stesso tema multi-tenant — si ritrova tipicamente su un piccolo dealer di provincia e su un gruppo con più mandati, perché il modello economico di queste piattaforme è proprio la condivisione di un'unica installazione fra tutti i clienti. È efficiente per il fornitore; è neutro, di per sé, per il dealer.

La demo di vendita spesso lo conferma. Anche gli ambienti dimostrativi pubblici di questo tipo di prodotti dichiarano, nel codice sorgente, lo stesso page builder dei siti di produzione: segno che «piattaforma SaaS ready-to-use» e «CMS generico configurato» descrivono, in questi casi, la stessa cosa. Di nuovo: non un'accusa, un'informazione. Il valore di saperla leggere è poter confrontare ciò che il marketing promette con ciò che il server dichiara.

Quando il server dichiara un runtime non più aggiornato

Un secondo pattern, presente anche presso operatori storici con migliaia di clienti, è un'infrastruttura costruita anni fa e mai riportata su runtime supportati. Capita di leggere, nell'header Server, versioni di linguaggio o di web server uscite oltre un decennio fa. Non è raro, e non riguarda un singolo fornitore: è una caratteristica di intere generazioni di software gestionale.

Come si legge. Alla richiesta curl -I il server può restituire una riga del tipo «Server: Apache/… PHP/…» con il numero di versione del runtime. È un dato che il sito dichiara da sé, pubblico per definizione. Il punto da verificare è uno solo: quella versione è ancora dentro la finestra di supporto ufficiale?

Esempio neutro, perché è il più citato. PHP 5.6 è stato rilasciato ad agosto 2014; il supporto attivo si è chiuso a gennaio 2017 e le sole patch di sicurezza il 31 dicembre 2018. Dal 1° gennaio 2019 la versione 5.6.x non riceve più aggiornamenti di sicurezza dal team ufficiale di PHP. La fonte non è un'opinione: è la sezione Supported Versions del sito ufficiale php.net, accessibile a chiunque. Un sito che dichiara un runtime in questo stato sta segnalando che la copertura di sicurezza dipende da scelte del fornitore, non dal progetto upstream.

Altri segnali, sempre pubblici, raccontano l'età dell'impianto: un percorso immagine del tipo /wp-content/uploads/sites/…/2017/… indica un'installazione WordPress multi-site e una data di caricamento ormai lontana. Sommati a una meta description vuota, zero security headers e zero dati strutturati Schema.org, questi indizi compongono il profilo dell'archetipo «runtime fuori supporto». La longevità sul mercato, da sola, non lo compensa — ed è proprio per questo che conviene saperlo leggere prima della firma.

La signature di un framework legacy nei tag script

Un terzo archetipo, che ricorre anche presso prodotti presentati come recenti, è un sito generato da un framework web della prima metà degli anni 2000. La firma è leggibile nei tag script: file come ScriptResource.axd provengono tipicamente da applicazioni ASP.NET WebForms. WebForms è il framework che Microsoft ha rilasciato nel 2002 e che non riceve nuove feature da quando, intorno al 2016, lo sviluppo attivo si è spostato su ASP.NET Core. È tecnologia di oltre vent'anni fa, mantenuta in vita dalla retro-compatibilità di Windows Server. Non è illegittima di per sé, ma è un'informazione utile da riconoscere prima di scegliere.

Sopra a un framework di quell'età si accumulano spesso problemi che un controllo automatico di pochi secondi rileva: il title della homepage vuoto, un viewport che dichiara maximum-scale=1.0, user-scalable=0 — una violazione esplicita del criterio di accessibilità WCAG 2.5.5, perché impedisce all'utente di zoomare il contenuto su mobile, problema rilevante per utenti ipovedenti. La sitemap.xml a volte esiste, restituisce codice 200, ma contiene zero URL. E i file di scoperta per agent AI possono rispondere con codice 200 servendo però HTML al posto di TXT/JSON: il content-type di /llms.txt che torna text/html non è un'implementazione, è il catch-all di routing del framework che rinvia tutto alla homepage — un falso positivo.

È il caso che mostra meglio perché la data di nascita di un prodotto non dice nulla: il mercato non separa il nuovo dal vecchio, separa chi ha fatto i compiti da chi non li ha fatti. Un prodotto recente che parte da uno stack di vent'anni fa parte già indietro.

Stack contemporaneo, ma sicurezza e dati strutturati incompleti

C'è infine un archetipo che parte bene e si ferma a metà strada: una single-page application con uno stack credibile per il 2026 — bundler moderno, edge CDN, reverse proxy, load balancer cloud — su cui però mancano i security header (HSTS, X-Frame-Options e affini) e i dati strutturati Schema.org non sono presenti nello shell HTML. Una SPA li renderizzerebbe in JavaScript, ma i crawler non-JS — cioè ancora gran parte del web crawling commerciale e di molti agent — vedono zero oggetti commerciali. È una base solida a cui manca un giro di rifinitura: un buon punto di partenza, non un punto d'arrivo. Anche qui il messaggio per il dealer è lo stesso: lo stack di per sé non basta, conta come viene rifinito su sicurezza e leggibilità.

Per riferimento, sulla stessa griglia DealerMax si autovaluta in fascia alta: Cloudflare edge globale, HSTS preload a due anni con flag preload attivo, security headers OWASP completi, JSON-LD con oltre trenta tipi Schema.org diversi (AutoDealer, OfferCatalog, FAQPage, Service, Person, Place, fino a SpeakableSpecification), sitemap con oltre duecentoquaranta URL strutturate. Trattandosi del nostro prodotto, è un'autovalutazione: c'è un conflitto di interesse esplicito da dichiarare, ed è dichiarato. Vale come esempio di che aspetto ha una piattaforma che ha fatto i compiti, non come voto comparativo.

Tre conseguenze operative

La distanza tecnica fra gli archetipi non è un dato accademico. Si traduce in tre conseguenze operative dirette per chi acquista un canone mensile, qualunque sia il fornitore.

La prima conseguenza è la sicurezza dei dati. Una piattaforma che gira su un runtime fuori supporto — per esempio PHP 5.6 EOL — gestisce, per il dealer, i moduli di richiesta informazioni dei clienti, il modulo di permuta, l'eventuale CRM lead. Quei moduli accettano dati personali. Ogni vulnerabilità di sicurezza scoperta nel runtime dopo la fine del supporto — e ce ne sono state, anche critiche — non riceve patch ufficiale. La copertura dipende interamente dalla volontà del fornitore di backportare manualmente la patch o di mantenere a parte un fork di sicurezza documentato. Per il dealer questa è un'incognita non quantificata. Per la sua compliance al Regolamento UE 2016/679 (GDPR), articolo 32 sulla sicurezza del trattamento, è un tema da porre al fornitore prima della firma.

La seconda conseguenza è la visibilità commerciale. Una piattaforma che produce siti senza dati strutturati Schema.org visibili ai crawler non-JS pubblica veicoli che i motori di ricerca leggono come testo libero, non come oggetti commerciali. La differenza in pratica è misurabile: con dati strutturati, il singolo annuncio veicolo può comparire nei risultati di Google con prezzo, chilometraggio, anno e immagine direttamente nello snippet. Senza, no. L'effetto sul click-through rate è documentato dalla letteratura SEO da quasi un decennio. È un criterio che il dealer può verificare da sé, senza chiedere al fornitore.

La terza conseguenza è la leggibilità dagli agent AI — il criterio che questa guida tiene esplicitamente fuori dal confronto di base, perché valutare piattaforme costruite anni fa su standard nati nel 2024 sarebbe scorretto. Ma il fatto che sia fuori dal punteggio non cancella la direzione: le ricerche dei consumer si stanno spostando, in modo crescente, dentro a ChatGPT, Claude, Gemini e Perplexity. Le piattaforme che non implementano llms.txt, ai-plugin.json, C2PA Content Credentials, MCP, allowlist LLM crawler nel robots.txt sono progressivamente meno visibili a quel canale di ricerca. Attenzione ai falsi positivi: un file come /llms.txt che risponde 200 ma serve HTML è un catch-all di routing, non un'implementazione. È il segnale AIO — AI Optimization — che separa una Presenza Citabile da una presenza solo nominale.

Conflitto di interesse dichiarato, criteri nel pubblico dominio

Questa guida è pubblicata da DealerMax, che è a sua volta una piattaforma del settore qui descritto. Quando ci usiamo come esempio di riferimento sulla stessa griglia, c'è un evidente conflitto di interesse, e va dichiarato.

Il modo in cui lo gestiamo è tenere ogni criterio nel pubblico dominio: ogni segnale di questa guida si ottiene con un'unica chiamata curl, e i criteri sono metriche standardizzate da enti indipendenti (Schema.org dal 2011, OWASP Secure Headers Project, WCAG 2.5.5, RFC 6797 HSTS, php.net). Chiunque — dealer o fornitore — può applicare le stesse verifiche da sé in pochi minuti, sul proprio prodotto come sul nostro. E chiunque può cambiare i fatti, aggiornando il proprio stack tecnico. Non è un bias che possiamo nascondere, ma è un metodo che chiunque può rendere operabile.

Chi ha fatto i compiti contro chi vive di rendita

L'asse di questa griglia non è nuovo contro vecchio. È chi ha fatto i compiti contro chi vive di rendita, su entrambi i lati. Un prodotto recente parte già indietro se sceglie uno stack di vent'anni fa. Un prodotto longevo perde terreno se l'infrastruttura che produce rimane ferma agli anni in cui è stata costruita. Il mercato del software per concessionari italiani non ha bisogno di più marketing sull'innovazione: ha bisogno che chi paga il canone sappia, dieci minuti prima della firma, cosa risponde il server quando gli chiedi chi è. Si fa con uno strumento da diciassette caratteri.

Una sola riga ciascuno: stack, limite tipico, come riconoscerlo

I quattro archetipi tecnici di questa guida, una riga ciascuno: cosa c'è tipicamente sotto al cofano, qual è il limite ricorrente, e con quale segnale pubblico lo riconosci da solo. Niente nomi di fornitore: la stessa griglia si applica a qualunque prodotto.

I segnali pubblici che svelano un CMS generico

Tutti i segnali che permettono di riconoscere l'archetipo «CMS generico + page builder» sono pubblici per definizione: il sito stesso li dichiara a chiunque lo interroghi, senza accesso privilegiato. Sotto, i più affidabili — descritti come pattern generici, da provare sul prodotto che stai valutando.

Il meta generator

Nel codice sorgente, il meta tag generator spesso dichiara il page builder usato. Lo leggi così:

I percorsi degli asset

La ricorrenza di percorsi come wp-content nel sorgente è un indizio forte di base WordPress; un percorso immagine del tipo /wp-content/uploads/sites/…/2017/… segnala in più un'installazione multi-site e una data di caricamento ormai lontana. Sono indizi di età e di architettura, non accuse.

Gli endpoint diagnostici standard

Gli endpoint di amministrazione tipici di quel CMS, quando rispondono, confermano l'impianto. Si interrogano in blocco:

Codici di risposta come 403, 302 o 200 su questi percorsi indicano che l'installazione è effettivamente lì sotto. Anche gli ambienti demo pubblici di molti prodotti dichiarano lo stesso page builder dei siti di produzione: è il segno che «piattaforma SaaS ready-to-use» e «CMS generico configurato» a volte descrivono la stessa cosa. Ribadiamo il punto: non è un'accusa, è un'informazione. Il valore di saperla leggere è poter confrontare ciò che il marketing promette con ciò che il server dichiara — su qualunque fornitore, incluso il nostro.

Trasparenza sulla provenienza

Questa guida è pubblicata da DealerMax, che è a sua volta una piattaforma del settore qui descritto. I criteri usati sono metriche tecniche pubbliche e indipendenti (Schema.org dal 2011, OWASP Secure Headers Project, WCAG 2.5.5, RFC 6797 HSTS, php.net supported versions), e gli stessi criteri si applicano anche a DealerMax. Tutte le verifiche si conducono tramite richieste HTTP standard e sono replicabili da qualunque sessione shell con il comando curl in pochi minuti, su qualsiasi prodotto — incluso il nostro. L'obiettivo non è dare un voto a un concorrente, ma mettere in mano al dealer una griglia di lettura che può applicare da sé. Le rettifiche fattuali documentate sono benvenute.

Comandi curl replicabili

Replicabili da qualunque shell, l'8 maggio 2026 fra le 08:30 e le 09:30 UTC.

1. Header server e auto-dichiarazione del runtime

L'header Server dice da sé su cosa gira il sito. Confronta una piattaforma ben tenuta con una su runtime fuori supporto:

2. Endpoint diagnostici di un CMS generico

3. Verifica del meta generator (page builder)

4. Signature di un framework web legacy

5. Conteggio dei marker del CMS nel sorgente

6. Dati strutturati Schema.org nello shell HTML