Modello di contenuto del sito web: dalla descrizione del servizio ai dati strutturati

Un modello di contenuto per siti web descrive quali oggetti di contenuto esistono, quali campi possiedono, come sono interconnessi e secondo quali regole il contenuto viene convalidato. Per la tua PMI, questo significa: una descrizione del servizio difficile da riutilizzare viene trasformata in un contenuto strutturato che puoi rivedere professionalmente, tradurre e quindi rendere disponibile in modo controllato per il sito web, i servizi Google o un'API.

Nei miei progetti di siti web per piccole imprese a conduzione familiare, riscontro spesso lo stesso punto di partenza: i servizi sono chiaramente definiti dal punto di vista tecnico, ma sparsi tra testo, PDF, email, modelli di preventivo e singole sottopagine. Non appena cambia un nome, un numero di telefono o la disponibilità, inizia la ricerca di tutte le occorrenze di quelle stesse informazioni.

Un buon modello di contenuto non memorizza le informazioni nel punto in cui vengono visualizzate, ma in un luogo dove possono essere gestite professionalmente e mantenute in modo affidabile.

Dalla descrizione del servizio al modello di contenuto del sito web

Per il nostro esempio, prendiamo un'azienda artigianale altoatesina che offre servizi di interior design personalizzati. Il loro sito web attuale contiene il seguente paragrafo:

"Progettiamo e realizziamo interni su misura per privati, hotel e ristoranti in tutto l'Alto Adige. Offriamo consulenze in tedesco e italiano. Il prezzo varia in base alla portata del progetto, ai materiali e alla complessità dell'installazione. Per informazioni, non esitate a contattarci telefonicamente o tramite il modulo di contatto."

Il paragrafo è comprensibile per gli esseri umani. Tuttavia, presenta uno svantaggio per la modellazione dei contenuti: nomi dei servizi, gruppi target, regione, lingue, logica dei prezzi e metodi di contatto sono tutti mescolati. Se in seguito si desidera visualizzare solo i servizi disponibili in italiano o trasferire i servizi alberghieri a un'altra applicazione, il testo deve prima essere interpretato.

Pertanto, suddividiamo il catalogo dei servizi in oggetti tecnicamente identificabili. Tale entità è un oggetto di contenuto univocamente descrivibile e dotato di una propria identità.

• Leistung: ad esempio, “Progettazione d'interni personalizzata”
• Destinatari: come ad esempio privati ​​cittadini, hotel o ristoranti
• Località o area di servizio: ad esempio Alto Adige, Bolzano o Merano
• Contatto: la persona responsabile della materia
• Metodo di contatto: Telefono, email o modulo di richiesta
• Industria: come il turismo, la gastronomia o l'edilizia residenziale privata
• di riferimento: un progetto completato che dimostra le prestazioni
• Domanda e risposta: Una domanda frequente sulle prestazioni

La pagina visibile non è quindi più l'oggetto dati effettivo. La pagina è un output che combina informazioni provenienti da più entità. Il modello di contenuto del sito web descrive il contenuto sottostante; la struttura della pagina ne determina la presentazione visibile.

Campi nel modello di contenuto del sito web: l'entità "performance"

Uno schema di campi utilizzabile contiene più dei semplici nomi dei campi. Per ogni campo, è necessario definirne lo scopo, il tipo di dati, lo stato di obbligatorietà, i valori consentiti e almeno una regola di validazione. Ogni regola deve avere una giustificazione aziendale: deve prevenire errori, chiarire le responsabilità o consentire un utilizzo successivo.

ID univoco

• Nome del campo: performance_id
• scopo: L'ID univoco collega in modo affidabile lo stesso servizio a traduzioni, riferimenti, metodi di contatto e sistemi esterni.
• Tipo di dati: Corda
• Campo obbligatorio: Ja
• Regola di convalida: L'ID deve essere univoco, immutabile e privo di spazi, ad esempio "performance-interior-construction-001".
• Vantaggi per l'azienda: Un successivo cambio di nome non interrompe alcuna relazione o collegamento API.

Nome della performance

• Nome del campo: Nome
• scopo: Descrizione chiara e comprensibile del servizio.
• Tipo di dati: stringa traducibile
• Campo obbligatorio: Sì, a seconda della lingua di pubblicazione
• Regola di convalida: Il nome non deve essere vuoto, non deve essere identico a quello di un altro servizio ed è limitato, ad esempio, a 80 caratteri.
• Vantaggi per l'azienda: I nomi brevi funzionano bene nella navigazione, nella ricerca, nei campi di selezione e nelle visualizzazioni per dispositivi mobili.

Riassunto

• Nome del campo: breve descrizione
• scopo: Spiega in una o due frasi cosa viene offerto.
• Tipo di dati: testo traducibile
• Campo obbligatorio: Ja
• Regola di convalida: Imposta la lunghezza minima e massima, ad esempio da 80 a 240 caratteri; i numeri di telefono e i prezzi vanno inseriti in campi separati.
• Vantaggi per l'azienda: La stessa versione abbreviata può essere utilizzata nelle panoramiche, nella ricerca interna del sito web e in alcune interfacce selezionate.

Vantaggio

• Nome del campo: uso
• scopo: Descrive il risultato specifico per il cliente.
• Tipo di dati: Elenco di frammenti di testo traducibili
• Campo obbligatorio: Almeno una voce
• Regola di convalida: Ogni voce contiene esattamente un utilizzo e rimane al di sotto di una lunghezza di caratteri specificata.
• Vantaggi per l'azienda: È possibile selezionare i singoli argomenti a favore del prodotto in base al gruppo target, senza dover riscrivere l'intero testo.

Gruppi target e settori industriali

• Nomi dei campi: ID del gruppo target e ID del settore
• scopo: Assegnare un servizio ai gruppi target e ai settori appropriati.
• Tipo di dati: Elenco delle relazioni con altre entità
• Campo obbligatorio: Almeno un gruppo target; il settore è facoltativo e dipende dal tipo di attività.
• Regola di convalida: È possibile selezionare solo gli ID esistenti e approvati.
• Vantaggi per l'azienda: Il target di riferimento "settore alberghiero" viene coltivato una sola volta e può essere combinato con diversi servizi.

Logica dei prezzi

• Nome del campo: logica dei prezzi
• scopo: Descrive come viene generalmente determinato un prezzo.
• Tipo di dati: Valore di selezione
• Campo obbligatorio: Sì, se vengono comunicati i prezzi o le informazioni sui prezzi.
• Valori consentiti: Prezzo fisso, prezzo di partenza, basato sull'impegno, offerta personalizzata o su richiesta.
• Regola di convalida: Non è consentito inserire testo libero; le informazioni aggiuntive devono essere inserite in un campo di testo separato.
• Vantaggi per l'azienda: Le informazioni sui prezzi rimangono comparabili e non si contraddicono tra la pagina di riepilogo e quella di dettaglio.

Disponibilità e area di servizio

• Nomi dei campi: disponibilità e ID di posizione
• scopo: Determina se e dove il servizio viene offerto.
• Tipo di dati: stato definito più relazioni con luoghi o aree
• Campo obbligatorio: Ja
• Valori di stato consentiti: disponibile, disponibilità limitata, temporaneamente non disponibile o fuori produzione
• Regola di convalida: Qualora la disponibilità sia limitata, è necessario specificarlo in una nota o indicare un periodo di tempo.
• Vantaggi per l'azienda: I servizi non disponibili possono essere nascosti in modo controllato senza essere eliminati definitivamente.

sprachen

• Nome del campo: lingue disponibili
• scopo: Specifica in quali lingue è possibile la consulenza o l'implementazione.
• Tipo di dati: Elenco dei codici linguistici standardizzati, ad esempio de e it
• Campo obbligatorio: Ja
• Regola di convalida: Utilizzare esclusivamente i valori linguistici definiti; non mescolare la lingua della consultazione con la lingua del testo del sito web.
• Vantaggi per l'azienda: Una descrizione in italiano non implica automaticamente che il servizio sarà fornito anche in italiano.

Modalità di contatto e aggiornamento

• Nomi dei campi: ID_percorso_contatto, aggiornato_su e stato_rilascio
• scopo: Collega il servizio a opzioni di contatto valide e documenta il suo stato editoriale.
• Tipo di dati: Relazioni, data e valore di selezione
• Campo obbligatorio: Ja
• Valori di rilascio consentiti: Bozza, revisionata tecnicamente, revisionata editorialmente, approvata o archiviata
• Regola di convalida: La pubblicazione è consentita solo previo contatto attivo tramite almeno un canale di comunicazione e completamento della procedura di approvazione.
• Vantaggi per l'azienda: I visitatori non riceveranno un numero di telefono obsoleto e le traduzioni incomplete non verranno pubblicate online per errore.

Come stabilire correttamente le relazioni nel modello di contenuto del sito web

Una relazione collega due entità tramite i loro ID. Ad esempio, il servizio "Progettazione d'interni personalizzata" può essere associato ai gruppi target "Privati", "Hotel" e "Ristoranti". Lo stesso servizio può anche essere assegnato a più sedi, referenze, contatti e domande frequenti.

Il vantaggio diventa evidente quando si apportano modifiche: se una persona di contatto lascia l'azienda, è sufficiente modificare la persona o il link una sola volta. Non è necessario cercare in ogni pagina dei servizi. Lo stesso vale per numeri di telefono, aree di servizio, nomi di settore e moduli di contatto.

In oltre 20 anni di lavoro su siti web e sistemi digitali, ho imparato che l'errore più comune nella modellazione non è dimenticare un campo. Più spesso, la struttura risultante riflette solo il sito web attuale. Un modello estensibile tiene conto anche di canali aggiuntivi, multilinguismo, competenze specifiche e trasferimenti di competenze tecniche.

Modella l'argomento e le sue relazioni, non solo la struttura del sito web attuale.

Prima e dopo: un testo di performance come insieme di dati

Il paragrafo originale è ora suddiviso in singoli elementi:

• Nome del servizio: Progettazione d'interni su misura
• Breve descrizione: Progettazione, produzione e montaggio di arredi interni su misura per spazi privati ​​e commerciali.
• Uso: Una soluzione d'arredo perfettamente su misura, una scelta coordinata dei materiali e un canale di comunicazione responsabile.
• Gruppi target: Privati, hotel, ristoranti
• Logica dei prezzi: offerta individuale
• Disponibilità: verfügbar
• Area di competenza: Alto Adige
• Lingue parlate per la consultazione: tedesco e italiano
• Modalità di contatto: Telefono e modulo di richiesta
• Data di aggiornamento: 2026-03-15
• Stato della versione: aperto

Un possibile output JSON tramite un'API potrebbe apparire così:

{
  "id": "leistung-innenausbau-001",
  "name": {
    "de": "Individueller Innenausbau",
    "it": "Arredamento d'interni su misura"
  },
  "kurzbeschreibung": {
    "de": "Planung, Fertigung und Montage individueller Innenausbauten für private und gewerbliche Räume.",
    "it": "Progettazione, produzione e montaggio di arredamenti su misura per spazi privati e commerciali."
  },
  "nutzen": {
    "de": [
      "Passgenaue Raumlösung",
      "Abgestimmte Materialwahl",
      "Ein verantwortlicher Kontaktweg"
    ]
  },
  "zielgruppen_ids": [
    "zielgruppe-privat",
    "zielgruppe-hotellerie",
    "zielgruppe-gastronomie"
  ],
  "preislogik": "individuelles_angebot",
  "verfuegbarkeit": "verfuegbar",
  "standort_ids": [
    "gebiet-suedtirol"
  ],
  "beratungssprachen": [
    "de",
    "it"
  ],
  "kontaktweg_ids": [
    "kontakt-telefon-zentrale",
    "kontakt-formular-projektanfrage"
  ],
  "aktualisiert_am": "2026-03-15",
  "freigabestatus": {
    "de": "freigegeben",
    "it": "freigegeben"
  }
}

JSON non è il modello di contenuto in sé. JSON è una rappresentazione tecnica di un set di dati che è stato acquisito secondo il modello. Il modello definisce quali campi sono consentiti, quali relazioni si applicano e quando il set di dati può essere pubblicato.

Il modello di contenuto del sito web come base centrale dei contenuti

Quando lo stesso set di dati condiviso alimenta più canali, si crea un'unica fonte di verità per la tua PMI . Questo non significa che ogni canale adotti ogni campo senza modifiche. Il repository centrale dei contenuti fornisce dati di origine affidabili; le regole specifiche di ciascun canale determinano la selezione, il formato e la condivisione.

Edizione sul sito web

La pagina del servizio può includere il nome del servizio, la descrizione, i vantaggi, i riferimenti, le domande frequenti e le informazioni di contatto. Una pagina di panoramica, invece, potrebbe utilizzare solo il nome, una breve descrizione e un'immagine. Entrambe le pagine accedono allo stesso servizio anziché mantenerne copie separate.

Dati strutturati sul sito web

Per i dati sulle prestazioni leggibili automaticamente, è possibile fare riferimento alle proprietà e ai tipi previsti ufficialmente per il tipo Service in Schema.org . Questi includono proprietà come serviceType , provider , areaServed e availableChannel.

Un markup Schema.org tecnicamente corretto, tuttavia, non garantisce la visualizzazione in un prodotto Google o un miglior posizionamento. I contenuti strutturati e il relativo markup possono aiutare i sistemi a classificare significati e relazioni. Spiego quali dati strutturati sono più rilevanti per la tua PMI nell'articolo sulle priorità per i dati strutturati dei siti web.

Profilo aziendale Google e interfacce Google

I dati aziendali presenti sul tuo sito web, i dati strutturati del sito web e le informazioni del tuo profilo Google My Business rappresentano tre livelli diversi. Le prestazioni del tuo modello di contenuti non vengono trasferite automaticamente e completamente al tuo profilo Google My Business.

Google documenta aree funzionali separate per le sue API del profilo aziendale, come informazioni sull'azienda, attributi, categorie, contenuti multimediali, post, recensioni e dati specifici del settore. Le informazioni che possono essere gestite dipendono dall'interfaccia specifica, dalle autorizzazioni del profilo, dalla categoria aziendale e dalle linee guida vigenti. La documentazione ufficiale delle API del profilo aziendale di Google rimane la fonte autorevole.

In pratica, è quindi necessaria la mappatura dei canali. La mappatura dei canali definisce quale campo interno corrisponde a quale campo Google consentito, chi approva il trasferimento e cosa succede se il canale di destinazione non supporta un determinato campo.

Output tramite un'API personalizzata

Un'API può fornire servizi approvati in formato JSON per un'app, un negozio, un sito web secondario o un sistema interno di preventivazione. Un approccio "API-first" separa i contenuti aziendali dall'interfaccia utente visibile. L'API dovrebbe restituire solo i campi obbligatori e approvati, non l'intero set di dati interno senza verifica.

Implementazione del modello di contenuto del sito web in otto fasi

1. Inventariare il contenuto esistente

Raccogli pagine di servizio, PDF, listini prezzi, moduli di offerta, informazioni del profilo, informazioni di contatto e traduzioni. Evidenzia duplicati, incongruenze e contenuti privi di un responsabile chiaramente identificabile.

2. Definire le entità

Identifica gli oggetti ricorrenti come servizio, luogo, persona, gruppo target, settore, riferimento e metodo di contatto. Per ciascun oggetto, verifica se possiede un'identità propria e se può essere utilizzato più volte.

3. Definire i campi

Definisci quali informazioni sono necessarie per ciascuna entità. Separa i contenuti che devono essere controllati, tradotti, filtrati o visualizzati in modo diverso.

4. Stabilire relazioni

Documenta quali entità possono essere collegate tra loro. Specifica anche il numero: ad esempio, un servizio ha almeno un canale di contatto, ma può avere più gruppi target e riferimenti.

5. Documentare le regole

Per ogni campo, definire il tipo di dati, lo stato di obbligatorietà, i valori consentiti e la regola di validazione. Inoltre, spiegare quale errore la regola previene. Senza una chiara finalità aziendale, le regole vengono spesso aggirate nella pratica quotidiana.

6. Raccogliere i dati campione

Non testare il modello con un solo servizio semplice. Includi almeno un servizio multilingue, un'offerta personalizzata e un servizio temporaneamente non disponibile. Questi casi estremi riveleranno fin da subito se il modello è valido.

7. Revisione editoriale e tecnica

La revisione tecnica risponde alla domanda: l'affermazione è corretta? La revisione editoriale risponde alla domanda: l'affermazione è comprensibile, coerente e appropriata nella lingua di riferimento? Solo a questo punto segue l'approvazione editoriale.

8. Implementazione e controllo tecnico

Passa i dati condivisi ai componenti del sito web, al markup dei dati strutturati o a un'API. Quindi controlla l'output effettivo, non solo il modulo di input.

Multilinguismo nel modello di contenuto del sito web

Per le PMI altoatesine, il multilinguismo non è un aspetto secondario. Nel modello, i dati indipendenti dalla lingua e i contenuti traducibili devono essere separati.

• Indipendente dalla lingua: ID univoco, logica di prezzo, disponibilità, relazione con la posizione e data di aggiornamento
• Traducibile: Nome del prodotto, breve descrizione, vantaggi, note e domande frequenti
• Da pubblicare in base alla lingua: Qualità del testo, terminologia, URL, titolo della pagina e stato editoriale
• Da non confondere con: Lingua del contenuto e lingua in cui è disponibile una consulenza o un servizio.

La versione tedesca potrebbe essere già stata pubblicata mentre quella italiana è ancora in fase di revisione. Questo garantisce che il sito web non mostri una traduzione incompleta. Per la pianificazione SEO e degli URL, puoi consultare anche la mia guida alla struttura SEO dei siti web multilingue.

Definire chiaramente ruoli e passaggi di consegne

Un modello di contenuto rimane affidabile solo se a ogni decisione importante viene assegnata una persona responsabile. Soprattutto nei team di piccole dimensioni, i ruoli dovrebbero essere semplici e chiaramente definiti.

• Direzione o persona professionalmente responsabile: Conferma l'ambito dei servizi, la logica di determinazione dei prezzi, la disponibilità e l'accuratezza tecnica.
• Redazione: è responsabile della comprensibilità, della terminologia, della lunghezza dei caratteri e della coerenza delle traduzioni.
• Sviluppo: Implementa la struttura dei dati, la validazione, le autorizzazioni, le interfacce e gli output tecnici.
• Persona designata per il rilascio: Decide quando un set di dati viene pubblicato e ne monitora l'attualità.

In Berger+Team, le persone che si occupano di modellazione, scrittura e sviluppo comunicano direttamente con il cliente. Questo coordinamento diretto è fondamentale per un modello di contenuto: un campo tecnicamente corretto è utile nella pratica solo se è chiaro chi gestisce il contenuto e perché quel campo è necessario.

Errori tipici di modellazione

• Un campo di raccolta per l'intera esecuzione: Il target di riferimento, il prezzo e il metodo di contatto rimangono nascosti nel corpo del testo e non possono essere verificati singolarmente.
• Testo libero per le logiche di prezzo: “Su richiesta”, “Prezzo su richiesta” e “Offerta personalizzata” diventano tre opzioni difficili da confrontare.
• Documenti d'identità mancanti: Le relazioni si basano sui nomi visibili e si interrompono quando un nome viene modificato.
• Lingue miste: I contenuti in tedesco e in italiano finiscono nello stesso campo di testo oppure non hanno uno stato di approvazione separato.
• Pagine anziché entità: Ogni sottopagina memorizza le proprie copie delle persone di contatto, delle sedi e dei dettagli di contatto.
• Campi tecnici obbligatori senza finalità operativa: I dipendenti inseriscono dei segnaposto semplicemente per poter salvare i dati.
• Nessuna giurisdizione: La data di aggiornamento esiste, ma nessuno è responsabile della prossima revisione.
• Acquisizione diretta del canale senza mappatura: Le informazioni interne o i valori di campo non idonei vengono trasmessi a sistemi esterni senza essere verificati.

Lista di controllo per il modello di contenuto del tuo sito web

Qualità e struttura dei dati

• Sono stati compilati tutti i campi obbligatori?
• Ciascun valore corrisponde al tipo di dati previsto?
• Vengono rispettate le lunghezze minime e massime?
• Ogni servizio possiede un ID univoco?
• Sono presenti voci duplicate o modi diversi di descrivere lo stesso risultato?
• Tutte le relazioni sono valide e collegate a entità esistenti?

Rilascio e distribuzione

• I dati di contatto corrispondono a livello di prestazioni, posizione e azienda?
• Le informazioni relative ai prezzi e alla disponibilità sono ancora aggiornate?
• Sono disponibili e approvate le traduzioni necessarie per ciascuna lingua?
• I servizi disattivati ​​vengono archiviati anziché essere eliminati senza controllo?
• È documentato quali campi possono essere inviati al sito web, ai servizi Google e alle API?
• Esiste una data di revisione o di aggiornamento per ogni risultato pubblicato?

Implementare il modello di contenuto del sito web in 90 giorni

Dal giorno 1 al giorno 30: Modello e pilota

Seleziona da tre a cinque servizi tipici. Fai un inventario dei contenuti esistenti, definisci entità, campi e relazioni e raccogli dati campione reali. Il progetto pilota dovrebbe includere intenzionalmente un caso più complesso, come ad esempio più gruppi target o due lingue.

Dal giorno 31 al giorno 60: Redazione e Dipartimento Tecnico

Verifica i nomi dei campi con le persone che in seguito gestiranno i contenuti. Implementa i campi obbligatori, i valori di selezione, lo stato della traduzione e le approvazioni nel sistema in uso. Quindi crea un output iniziale del sito web e una risposta JSON controllata.

Dal giorno 61 al 90: svolgimento ed espansione

Verifica i collegamenti, le relazioni, le versioni linguistiche, i dati strutturati del sito web e le interfacce pianificate. Affina il modello in base all'utilizzo effettivo e poi espandi la gamma completa di funzionalità. Un progetto pilota testato prima della migrazione completa riduce le rilavorazioni.

Domande e risposte sul modello di contenuto del sito web

Qual è la differenza tra un modello di contenuto e una struttura di pagina?

Il modello di contenuto descrive entità, campi, relazioni e regole. La struttura della pagina determina quale contenuto è visibile e dove. Pertanto, un singolo modello può generare più tipi di pagina e ulteriori output.

Quali contenuti sono adatti a campi specifici?

Di solito, i contenuti necessitano di un campo dedicato se si desidera controllarli, filtrarli, tradurli, aggiornarli o visualizzarli separatamente. Ad esempio, il numero di telefono, le informazioni sui prezzi e la disponibilità non dovrebbero essere nascosti in una descrizione generica.

Quanto devono essere dettagliati i campi?

I campi devono essere sufficientemente dettagliati per le esigenze di manutenzione, revisione e output. Se due informazioni vengono sempre modificate e utilizzate insieme, un solo campo può essere sufficiente. Se invece le informazioni richiedono regole o responsabili diversi, è necessario separarle.

Chi si occupa della gestione del modello dei contenuti?

Il modello viene sviluppato in modo collaborativo da un punto di vista professionale, editoriale e tecnico. Il contenuto viene gestito da personale dedicato durante il funzionamento. Le modifiche alla struttura, ai tipi di dati o alle relazioni vengono implementate in condizioni controllate dal team di sviluppo responsabile.

WordPress è in grado di gestire contenuti strutturati?

Sì, WordPress può rappresentare entità utilizzando i propri tipi di contenuto, campi e tassonomie. È fondamentale, tuttavia, che il modello di business sia documentato indipendentemente dai singoli modelli di pagina e che i dati vengano esportati in modo chiaro e preciso.

Cosa succede quando un servizio cambia?

Se cambia solo il valore di un campo, il record di dati viene aggiornato, verificato e ripubblicato. Se cambia la struttura aziendale, il modello deve essere prima versionato e verificato prima di modificare i record di dati o le interfacce esistenti.

Come vengono modellate le traduzioni?

I valori indipendenti dalla lingua vengono memorizzati una sola volta, mentre i campi traducibili ricevono contenuti e stato di approvazione separati per ogni lingua. Ciò consente di revisionare editorialmente i campi in tedesco e in italiano separatamente, senza dover gestire ID, relazioni o logiche di prezzo duplicati.

Tutti i contenuti devono essere trasmessi tramite API?

No. Un'API dovrebbe fornire solo contenuti necessari e autorizzati per lo specifico caso d'uso. Note interne, bozze, informazioni personali e campi relativi all'amministrazione tecnica rimangono protetti.

Vantaggi di un modello di contenuti ben gestito

La creazione di un modello di contenuto per un sito web non è un progetto riservato esclusivamente alle grandi aziende. Per le PMI, la modellazione dei contenuti definisce chiaramente le responsabilità, riduce la duplicazione degli interventi, garantisce traduzioni coerenti e consente passaggi di consegne controllati.

Iniziate con tre o cinque servizi, modellateli in modo completo ed esaminate il percorso che va dall'idea iniziale al prodotto finale. Se desiderate costruire il vostro sito web e il catalogo dei servizi in questo modo, i nostri servizi di strategia e sviluppo web combinano la struttura aziendale con la creazione di contenuti, il design e l'implementazione tecnica.

Swell

1. Schema.org: Servizio accessibile tramite schema.org.
2. Google per sviluppatori: API del profilo aziendale di Google – Domande frequenti, accessibili tramite developers.google.com.