Quando le pagine di marketing promettono ciò che il prodotto non fa

In breve. Le pagine di marketing di Arvo promettevano cose che il prodotto non faceva: AI che gira in locale, nutrizione senza limiti, prezzi in euro non verificati, parità completa su Wear OS, risultati con nome e cognome senza provenienza. Le ho corrette in un unico batch, dopo aver classificato ogni pagina. La tesi, che è mia e va letta come interpretazione, è che una claim non provata è debito di affidabilità come un bug: si accumula in silenzio e si paga con un audit. I fatti vengono dalla PR #2149 di Arvo, merge del 20 settembre 2026. Non porto dati di traffico: non ho un export di Search Console da citare.

Cosa prometteva il copy

Non era un'unica bugia grossa. Erano promesse piccole, scritte in momenti diversi, che nel tempo avevano smesso di corrispondere al prodotto:

• AI locale e offline. Le FAQ lasciavano intendere che l'AI funzionasse senza connessione.
• Nutrizione senza limiti. Descritta come illimitata, mentre esistono limiti di piano e un consenso esplicito.
• Prezzi in euro. Cifre scritte a mano nel hero, nelle schede dei piani e negli schema, senza una verifica che le tenesse allineate.
• Parità completa su Wear OS. Una promessa più larga di ciò che il percorso verificato supporta.
• Risultati Lite con nome. Testimonianze senza provenienza.

Nessuna di queste cose rompe un test. Un utente però le legge e decide in base a esse.

Come l'ho corretto

Il lavoro è una sola PR, con regole di perimetro dichiarate in apertura.

• Classificazione prima della modifica. Le rotte toccate erano classificate come SAFE_TO_IMPROVE o DECAY_OR_OUTDATED. Home, generatori e le altre pagine PROTECTED_WINNER non sono state toccate.
• Cosa resta fermo. URL, canonical, title e H1 invariati, e il copy della home pure. Ho verificato che generateMetadata e gli href fossero identici alla base sulle rotte modificate.
• Cosa cambia. Pagine come /features, /pricing, /pro, /lite, /ai-workout-app e /ai-coaches, più public/llms.txt. Le claim sul prezzo sono state neutralizzate invece di aggiornate: meglio nessuna cifra che una cifra che invecchia.
• Le testimonianze. Quelle di Lite con nome sono diventate schede di capacità, senza risultati attribuiti a persone.
• Overlay per rotta. Le FAQ sull'offline sono sovrascritture limitate alla singola rotta, per non modificare le traduzioni condivise con la home.

Sono 20 file in sette lingue: la stessa promessa sbagliata viveva in più punti, e correggerne uno solo avrebbe lasciato incoerenze.

La revisione ha trovato quello che io non avevo visto

Due revisioni indipendenti hanno dato FAIL sul primo commit (dce96cba0). I problemi erano concreti: euro rimasti nel hero e nelle schede, una FAQ sul rimborso in disaccordo con lo schema, risposte francesi sull'offline non corrette, un mix di lingue nel copy di Lite e residui in llms.txt. Un commit di correzione li ha chiusi, poi un terzo ha tolto gli ultimi riferimenti a GPT e ai «60 secondi» in llms.txt.

Il punto per me è questo: avevo fatto l'audit e credevo di aver finito. Il difetto di una claim non provata è che la cerchi con lo stesso sguardo con cui l'hai scritta. Serve qualcuno che non lo condivide.

Prima del push sono passati 1.237 controlli di contratto OpenAI e 19.070 test unitari del core. Dicono che il codice non si è rotto. Non dicono che il copy sia vero: per quello servono la lettura e la revisione.

Il residuo che non ho nascosto

Resta un €4 storico dentro generateMetadata della pagina /pricing. Il title è congelato per ragioni SEO e la PR lo documenta come residuo: non compare nel corpo né nelle FAQ, ma esiste. Lo scrivo qui perché un articolo sulle claim non provate che nasconde la propria claim residua sarebbe incoerente.

Fatto e interpretazione

Fatto (dalla PR #2149): le pagine e i file modificati, le due revisioni FAIL sul primo commit, i controlli passati, il residuo sul metadata di /pricing.

Interpretazione (mia):

• che le claim non provate siano debito di affidabilità comparabile ai bug;
• che si risolvano con un audit periodico e una classificazione delle pagine, non con una riscrittura estemporanea.

Il lavoro precedente di audit, la PR #2142, è il contesto: documentava le capacità reali del prodotto e le contraddizioni pubbliche da cui questo batch è partito. Sull'idea di trattare i problemi veri come lavoro da chiudere ho scritto in Backlog Zero; sul caso di un test che mentiva per colpa dell'ambiente in il test rosso che dipendeva dalla shell.

Domande frequenti

Una claim di marketing non provata è davvero un problema di affidabilità?

Per me sì, nel senso pratico: promette un comportamento che il prodotto non garantisce, e l'utente agisce su quella promessa. È un difetto come un altro, solo che nessun test lo vede.

Perché neutralizzare i prezzi invece di aggiornarli?

Una cifra scritta a mano in più punti (hero, schede, schema, FAQ) invecchia in modo diverso in ciascuno. Togliere la cifra dove non c'è una fonte unica evita che le versioni divergano.

Un audit del copy basta?

Nel mio caso no: due revisioni indipendenti hanno bocciato il primo commit trovando incoerenze che l'audit non aveva colto. L'audit trova le claim, la revisione di terzi trova quello che l'autore non vede più.