@kal ha detto in Redirect senza catene e .htaccess:

@pinguinone ha detto in Redirect senza catene e .htaccess:

Rimane il fatto però che facendo fino a 5 redirect il crawler impiega risorse che se gli faccio risparmiare è meglo per tutti no?!?

No, non impiega risorse.

Funziona così:

Crawler richiede URL --> HTTP 301: nuova URL 2 inserita in lista di scansione con priorità 0
Crawler richiede URL 2 --> HTTP 301: nuova URL 3 inserita in lista di scansione con priorità 0
Crawler richiede URL 3 --> HTTP 301: nuova URL 4 inserita in lista di scansione con priorità 0
Crawler richiede URL 4 --> HTTP 301: nuova URL 5 inserita in lista di scansione con priorità 0
Crawler richiede URL 5 --> HTTP 200: download della risorsa e "consumo" delle risorse di scansione

Di fatto il crawler consuma "risorse" solo quando scarica (essenzialmente banda e tempo) e quando fa il parsing/rendering... ma sono tutte cose che il crawler fa solo ALLA FINE.

E comunque considera che oggi arriva UFFICIALMENTE fino a 10.

@pinguinone ha detto in Redirect senza catene e .htaccess:

E' possibile trovare un metodo secondo te?

Non hai bisogno di trovare alcun metodo. Come detto, il tuo problema è un non-problema

Chiarissimo....e grazie mille. Spiegherò a chi produce il tool SEO che è un non problema e che non è giusto segnalarlo

@kal chiaro e grazie. Rimane il fatto però che facendo fino a 5 redirect il crawler impiega risorse che se gli faccio risparmiare è meglo per tutti no?!? E' possibile trovare un metodo secondo te?

Buongiorno,
non so se è la sezione giusta perché si tratta di un test SEO ma anche di codice sistemistico....nel caso sorry. Sto impazzendo da stamattina per la scrittura di una regola in un .htaccess. In pratica un tool SEO mi indica quanto segue:

"Controlla i tuoi reindirizzamenti
I reindirizzamenti gestiti correttamente sono quelli che indirizzano correttamente la pagina di origine verso la sua nuova versione esatta. Una serie di reindirizzamenti, chiamata catena di reindirizzamenti, si verifica quando una risorsa punta a un'altra, che punta a un'altra ancora e così via, fino a raggiungere la destinazione finale."

Che, a pensarci bene, ha molto senso come concetto perché una "catena di reindirizzamenti" da sprecare risorse a Google e ai suoi robottini oltre a rendere (anche se di pochissimo) il sito più lento.
Ora la mia necessità è quella che:

• Le richieste http vengano reindirizzate a https
• Le richieste non www vengano reindirizzate a www
• le richieste con finale "/index.html" vengano reindirizzate a "/"

Ho scritto pertanto questa regola in .htaccess

# http to https and non-www to www
RewriteCond %{ENV:HTTPS} off 
RewriteCond %{HTTP_HOST} !^www\.
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$
RewriteRule ^.*$ https://www.%1%{REQUEST_URI} [NE,R=301,L]
# remove index.html
RewriteRule ^index\.html$ / [R=301,L]
RewriteRule ^(.*)/index\.html$ /$1/ [R=301,L]

Che per andare va ma crea catene. Analizzando con questo tool le varie possibilità di redirect questo è il risultato (in grassetto quelli errati):

https://www.dominio.com >>> https://www.dominio.com >>> 0 redirect
https://www.dominio.com/index.html >>> https://www.dominio.com >>> 2 redirect
http://www.dominio.com >>> https://www.dominio.com >>> 1 redirect
http://www.dominio.com/index.html >>> https://www.dominio.com >>> 3 redirect
https://dominio.com/ >>> https://www.dominio.com >>> 1 redirect
https://dominio.com/index.html >>> https://www.dominio.com >>> 3 redirect
http://dominio.com/ >>> https://www.dominio.com >>> 1 redirect
http://dominio.com/index.html >>> https://www.dominio.com/ >>> 3 redirect

https://www.dominio.com/subdirectory/ >>> https://www.dominio.com/subdirectory/ >>> 0 redirect
https://www.dominio.com/subdirectory/index.html >>> https://www.dominio.com/subdirectory/ >>> 2 redirect
http://www.dominio.com/subdirectory/ >>> https://www.dominio.com/subdirectory/ >>> 1 redirect
http://www.dominio.com/subdirectory/index.html >>> https://www.dominio.com/subdirectory/ >>> 3 redirect
https://dominio.com/subdirectory/ >>> https://www.dominio.com/subdirectory/ >>> 1 redirect
https://dominio.com/subdirectory/index.html >>> https://www.dominio.com/subdirectory/ >>> 3 redirect
http://dominio.com/subdirectory/ >>> https://www.dominio.com/subdirectory/ >>> 1 redirect
http://dominio.com/subdirectory/index.html >>> https://www.dominio.com/subdirectory/ >>> 3 redirect

C'è qualche anima pia che mi da una mano per capire come risolvere questa cosa?

Grazie mille

Buongiorno a tutti,
dopo il mega corso "html per SEO" di @giorgiotave sto, poco per volta, implementando tutti gli utilissimi consigli imparati. Tra questi ci sono anche questi "benedetti" dati strutturati che, onestamente, mi stanno dando parecchi grattacapi. Tuttavia...se gli forniamo informazioni certe e ben strutturate al nostro googlebot quest'ultimo sarà più felice ma, soprattutto, fornnirà dati più pertinenti ai potenziali ricercatori/visitatori quindi....facciamo questi dati strutturati.
Dopo aver implementato

• Organization (in una singola pagina...la home)
• Website (dentro ad organization)
• Logo (dentro ad organization)
• Breadcrumb
• WPHeader (dentro qualsiasi pagina abbia il menù di navigazione)

Ora sto per implementare "Article". Premettiamo che non uso Wordpress ma ho un motore lato mia macchina parecchio performante in parte sviluppato da me come verticalizzazione su un cms headless.
Le immagini dentro ad ogni pagina del sito vengono elaborate dal mio motore e per ogni immagine (in funzione della risoluzione dell'immagine) il motore crea fino 20 immagini diverse per risoluzione tutte in formato .webp e le serve come scrset con, ovviamente, la visibilità in funzione delle dimensioni dello schermo del browser. In questo modo gestisco ottimamente tutte le visualizzazioni mobile e Google sembra gradire.
Detto questo arrivo, finalmente, alla domanda. Google qua indica:

image >>> Proprietà ripetuta ImageObject o URL
L'URL per un'immagine rappresentativa dell'articolo. Utilizza immagini pertinenti all'articolo, anziché loghi o didascalie.
Ulteriori linee guida per le immagini:

• Ogni pagina deve contenere almeno un'immagine (indipendentemente dal fatto che includa markup o meno). Google sceglierà l'immagine migliore da mostrare nei risultati della Ricerca in base alle proporzioni e alla risoluzione.
• Gli URL delle immagini devono poter essere sottoposti a scansione e indicizzazione. Per verificare se Google può accedere agli URL, utilizza lo strumento Controllo URL.
• Le immagini devono rappresentare i contenuti con markup.
• Le immagini devono essere in un formato file supportato da Google Immagini.
  é Per ottenere risultati ottimali, consigliamo di fornire più immagini ad alta risoluzione (minimo 50.000 pixel moltiplicando larghezza e altezza) con le seguenti proporzioni: 16 x 9, 4 x 3 e 1 x 1.

Qua mi permette di mettere un set...ma poi specifica 3 proporzioni...quindi ipotizzo che non voglia le immagini in funzione della risoluzione dello schermo come fa, invece, per i siti ma qua "ragiona" a proporzione (e, imho, ha anche molto più senso)....il mio scrset del sito si basa sulle proporzioni ma non è detto che abbia queste esatte proporzioni e comunque avrebbe fino a 20 varianti. Voi come vi comportate? Date più immagini 16 x 9 con diverse risoluzioni o solamente 1 e poi "ci pensa Google immagini"?

Grazie

Grazie a te @alepom per il supercorso

@alepom ha detto in Dubbi su dati strutturati tramite GTM:

Grazie @dozpav per la risorsa in cui si trovano i motori di riferimento per i diversi paesi.
I dati che ho proiettato nel corso sono di Statista. Anche lì trovi tutti i dati di riferimento.

Puoi mettere il link per piacere?

Per quanto riguarda i dati strutturati..
Prima di tutto attenzione ai termini. Quando diciamo: "il dato strutturato idealmente andrebbe servito direttamente in DOM", credo si intendesse dire che sarebbe preferibile renderizzarlo lato server. Perché il DOM è una struttura che prende vita nel client. Scusate se ho fatto l'appunto, ma è davvero importate per la comprensione di tutti.

Comunque sono d'accordo con il messaggio che si voleva dare. Come ho detto ne video, ciò che è importante per la strategia va renderizzato lato server. Così avremo un'arma universale, indipendentemente dal client e dai tempi di rendering dei motori di ricerca.

Sospetttavo che fosse così ma speravo in una risposta diversa

@pinguinone, visto che usi dei framework così interessanti, se fossi in te, invece di consigliare agli utenti di aggiungersi i dati strutturati via GTM, potresti creare una struttura in backend che permette loro di inserirli (poi vedi tu il grado di automazione che vuoi dare) e quando fai il build delle pagine, renderizzi i dati strutturati lato server.

Purtroppo non credo sia facilmente fattibile. L'infrastruttura che utilizzo è uno sviluppo lato PC del sito e poi faccio un push su GitHub e da lì parte una github action che crea il sito e lo deploya tramite SSH sul server di destino. Ovviamente ottimizzando il codice e migliorando le risorse....per fare quanto dici te credo che dovrei:

• Creare un repository per ogni singolo progetto
• Creare un qualcosa lato server (asp.net core in questo caso potrebbe aiutarmi) per i dati strutturati
• L'utente modifica lato app asp.net core i dati e poi si scatena un aggiornamento in GitHub del singolo progetto
• Con una github action copio i dati sul codice principale facendo un altro push e poi si riscatena ancora l'action di deploy

Macchinosetto direi....o hai qualche soluzione alternativa?

@dozpav ha detto in Dubbi su dati strutturati tramite GTM:

@pinguinone

I dati sui motori di ricerca utilizzati per Paese si trovano su diverse fonti ma nessuna attendibile al 100%, puoi provare a dare un'occhiata qui:

https://gs.statcounter.com/search-engine-market-share

Per quanto riguarda i dati strutturati iniettati via tag manager ho avuto alcune esperienze abbastanza contoproducenti in passato.

Secondo me Il dato strutturato idealmente andrebbe servito direttamente in DOM non solo per i vari motori di ricerca meno avanzati di google (esempio naver o yahoo).

Da quello che ho avuto modo di notare, capitava che su alcune pagine il crawler di google non riuscisse a rilevare il dato strutturato, questo magari veniva corretto nella 'second wave' del crawler ma non era un comportamento consistente.

Su alcune pagine search console mi indicava che il dato strutturato era presente, dopo spariva e poi ricompariva oppure no...

In generale tenderei a non fornire via javascript delle info che possono risultare utili al motore di ricerca se non e' proprio necessario...ma immagino di essere 'all'antica'

Ciao e grazie per la risposta. Tutto estremamente chiaro....ora mi devo solo mettere a creare un motore per i dati strutturati nel template che ho creato per il framework JS

Grazie ancora

Buongiorno a tutti,
ho appena finito il "Corso HTML per SEO", risorsa ottima e splendidamente costruita per cui posso solo ringraziare @giorgio-tave
Nella parte advanced ogni singola parola detta da @alepom ha aperto un mondo quindi posso solo ringraziare anche lui; tuttavia ho un dubbio. Nel test che è stato fatto è stato definito un rendering lato JS dal client verificando che:

• Google indicizza quasi subito le parti aggiunte da JS (ok in realtà qualche giorno dopo il first wave index)
• Yandex ci mette un po' di più ad indicizzare le parti aggiunte da JS (ma alla fine lo indicizza)
• Bing (anche se la documentazione ufficiale dice il contrario) decide per i fatti suoi di non indicizzare un bel niente.

Ora, non utilizzo per niente Wordpress o sistemi similari e, solitamente, uso framework JS (per intenderci...Hugo, Jekyll e mi devo studiare Qwik). un'idea malsana che mi è venuta in mente è quello di mettere i dati strutturati principali direttamente nell' HTML generato dal framework mentre permettere al singolo utente di aggiungersi i propri dati strutturati tramite GTM.
Questi secondi dati struttuarti "iniettati" tramite GTM avrebbero lo stesso problema di cui sopra per cui Bing "non se li calcola proprio"?
Inoltre nel corso è stato indicato che in funzione del mercato di riferimento per ogni progetto ha un senso capire se il tal motore di ricerca viene usato o meno....è possibile avere un link o un tool che indica per singolo mercato quali sono i motori di ricerca più utilizzati?

Grazie

Buongiorno a tutti,
premetto che sono uno sviluppatore e sto sviluppando una soluzione custom con motore #Hugo. Il tema che sto usando utilizza tantissimi file JS di terze parti (mega menù, JQuery, slider, popup ecc. ecc.)
In ottica SEO ho scritto un codice per fare in modo che in ogni pagina vengano richiamati solo i riferimenti ai file dei codici JS utilizzati per quella singola pagina.

Quindi, ad esempio, la pagina_A utilizzerà:

• JQuery
• Slider

mentre la pagina_B utilizzerà:

• JQuery
• Slider
• Popup
• Carosello

Dopodiché unisco tutto in un unico file, minimifico e servo alla pagina.
Facendo così ottengo il fatto che ogni pagina carica un unico file (e poche richieste al server solitamente piacciono a Google Page Speed e ai Core Web Vitals) ma questo file, ovviamente è pesantissimo (contiene tutto). Inoltre ad ogni cambio di pagina il file ovviamente cambia e il browser (e il google bot) deve riscaricarsi un nuovo file dove una buona parte del codice (JQuery ad esempio) è sempre la stessa. Quindi ho un vantaggio (poche richieste al server) ma uno svantaggio, secondo me, per l'utente perché non sfrutto per niente la cache del browser senza considerare che la pagina carica, per forza di cose, un po' più lentamente (un conto è elaborare diversi file JS un conto è elaborare un unico file enorme)

Potrei mettere i singoli file (minimificati ovviamente) così sfrutterei la cache del browser tuttavia avrei il problema che farebbe molte più richieste al server...ora cosa è meglio lato SEO? Quanto influisce sui Core WebVitals questo aspetto?

Grazie a chi mi risponderà

@massj grazie mille.
Finalmente dati un po' precisi e che hanno un senso.

@sermatica ha detto in Google Page Speed....per me ha qualche problema:

@pinguinone ha detto in Google Page Speed....per me ha qualche problema:

1 Sia LightHouse che Google Page Speed fanno la verifica mobile emulando un cellulare di fascia medio-bassa con una banda infima...ora ok che bisogna essere restrittivi però così mi sembra, francamente, troppo. Ad ogni modo "pecco" nel tempo di elaborazione del JS e ci posso fare poco.

Ciao
per quanto riguarda il punto 1 devi aspettare 30 giorni, ed avere abbastanza traffico, che vengano raccolti i dati reali degli utenti sulla velocità del tuo sito. Li potrai trarre le tue conclusioni ed intervenire.

Ciao e grazie della risposta. Questo significa che Google Page Speed e Lighthouse non fanno semplicemente una verifica tecnica applicando algoritmi ecc ma considerano e incrociano i dati anche con l'utilizzo effettivo del sito da parte degli utenti?

Buongiorno,
sto per mettere on-line un nuovo sito basato su una sorta di CMS sviluppato da me off-line con utilizzo di Hugo sotto il cofano. Ho cercato, per quanto possibile, di realizzare un template e del codice che rispetta tutti i criteri di Google Page Speed oltre, ovviamente, ad essere utile e ben visible per l'utente (che per quanto mi concerne è la prima cosa).
Ora, analizzando il sito con Google Page Speed trovo delle incongruenze. Nel dettaglio:

1 Sia LightHouse che Google Page Speed fanno la verifica mobile emulando un cellulare di fascia medio-bassa con una banda infima...ora ok che bisogna essere restrittivi però così mi sembra, francamente, troppo. Ad ogni modo "pecco" nel tempo di elaborazione del JS e ci posso fare poco.
2. Entrambi mi dicono che non ho messo la meta description mentre invece è presente (ho provato anche a verificare con Screaming Frog)
2. Entrambi mi dicono che non ho messo il tag meta viewport mentre invece è presente

Considerando che uno dei mille mila fattori della SEO è anche il punteggino che si trova in Google Page Speed (che ho letto da qualche parte che ora è motivo di ranking) vorrei capire come mai succede quanto sopra indicato. C'è qualcuno che possa aiutarmi?

Grazie

@giancampo ha detto in Google Tag Manage Server side [GTM] - Dubbi e perplessità:

@pinguinone credo che il punto davvero interessante possa essere il 3 sempre che lo si rilevi come un problema per il business.
Ad es. nel caso di un B2B dove un cliente singolo fa potenzialmente un'alta quota di revenue rischi che se questo ha un adblock attivo ti perdi una grossa fetta di fatturato nel tuo monitoraggio.

Su quanto questo sia etico è un altro paio di maniche e in effetti concordo con te che se è un'esigenza espressa dell'utente sarebbe più corretto tenerlo in considerazione.
Tuttavia, su questo ho il dubbio se davvero un utente medio che usa un adblock lo stia utilizzando conoscendo bene cosa sta bloccando, non ne sarei così certo.

Tutto il tuo ragionamento fila perfettamente, tuttavia che sappia cosa faccia o meno se ha messo un adblock allora l'ha fatto e bisogna rispettare la sua decisione (secondo me) quindi non mi sembrerebbe corretto "fregarlo" con il servr-side. E considerando, che era solo quel punto la parte più importante dire che Server side, almeno per il momento, è da mettere in disparte.

@massj molto ma veramente molto interessante. Io dopo averci pensato su ho pensato bene di non usare Server side e la tua esperienza non fa altro che confermare questa mia idea. Grazie, se vuoi condividere altre informazioni per quanto mi concerne...che ben vengano.

Buongiorno, chiedo un aiuto perché ci sto pensando da qualche giorno e la logica nel mio cervello sta facendo una sorta di fight club dando cazzotti fortissimi a sé stessa.

Premessa:
Ho un template che sto costruendo/modificando per Hugo. Questo template usa una pletora di componenti JS (che si tirano dietro ovviamente i rispettivi CSS).
Ho diverse pagine che vengono generate e, ovviamente, non tutte implementano ogni componente JS ma tutte implementano Bootstrap e JQuery.

Soluzione 1
Lascio nel codice HTML riferimenti a ogni singola libreria CSS e JS che viene usata in ogni pagina. Pagespeed mi dice "Ciccio fai troppe richieste al server riducile che così non va bene"

Soluzione 2
Unisco quindi tutti i file CSS e JS all'interno di due distinti file...lì minimifico, risolvo qualche conflitto e carico. Page speed mi dice "Eh Ciccio non va bene manco così perché è vero che sei bravo a fare so le richieste minime ed indispensabili per il tuo sito però il file pesa tanto (ndg ma va?!?) e soprattutto dentro ha codice che non utilizzi...eliminalo"

Soluzione 3
Allora ho pensato....cerca di capire per singola pagina quali siano i componenti JS di utilizzo e poi unisci solo loro. Non l'ho ancora fatto però non mi sembra una genialiata perché alcune parti di CSS e JS non utilizzate rimarebbero comunque (poche ma esistenti)....basti pensare a Bootstrap. Inoltre ogni pagina avrebbe un unico file CSS e JS...quindi non potrei far sfruttare per niente la cache del browser...e, onestamente, mi pare u a cavolata dando all'utente (ma anche al Google bot) un disservizio piuttosto che un servizio.

Prima che la mia logica si ammazza a suon di pugni...avete qualche idea per risolvere?

@kal ha detto in Google Tag Manage Server side [GTM] - Dubbi e perplessità:

@pinguinone ha detto in Google Tag Manage Server side [GTM] - Dubbi e perplessità:

Grazie per la tua risposta. Rispetto al mio dubbio di un blocco lato sistema operativo degli invii a servizi terzi (da parte ad esempio di Apple)? Ne sai qualcosa?

No, questo non può succedere. Perché se GTM lavora server side, è completamente invisibile al client. L'unica cosa che browser e sistema operativo vedono è la connessione al tuo server proprietario.

Lì la scelta se tracciare o non tracciare è lasciata completamente alla responsabilità del proprietario del sito.

Che ci può anche stare: con GTM server side, è il proprietario del sito ad essere in prima linea nella gestione delle scelte di privacy degli utenti.

No...non mi sono spiegato. Uno dei vantaggi di Server Side (secodo me unico) è proprio il fatto che non vi è modo per bloccare i tracciamenti perché essendo lato server, correttamente, non vi è modo per il pc dell'utente di capire cosa bloccare o meno.
Il dubbio che ho è in merito a GTM Classic (o client side) lì il tracciamento è bloccato se l'utente lo blocca di sua volontà (e ok) ma mi domandavo se Apple o altri invece hanno implementato lato browser o lato sistema operativo un blocco "a prescindere" di tutti i dati inviati in post a domini che non siano quello del sito (per cui bloccano di fatto i tracciamenti)

@kal ha detto in Google Tag Manage Server side [GTM] - Dubbi e perplessità:

Le tue osservazioni sono corrette.

A mio parere, vista le non triviali richieste tecniche per l'installazione, è realmente utile solo in casi d'uso abbastanza ristretti (principalmente in ambito enterprise).
Grazie per la tua risposta. Rispetto al mio dubbio di un blocco lato sistema operativo degli invii a servizi terzi (da parte ad esempio di Apple)? Ne sai qualcosa?

Gianluca

Buongiorno a tutti,
uso da un po' di tempo GTM e mi trovo piuttosto bene. Da qualche tempo Google ha messo a disposizione degli utenti GTM Server side ove le richieste a servizi di terze parti vengono inviate direttamente dal server e non dal client.
Ho seguito un webinar di @matteo-zambon proprio su GTM Server side e come al solito ha dato preziose e utili informazioni. Tuttavia ho parecchi dubbi sull'effettiva possibilità e uso di GTM Server side e volevo avere la vostra opinione in merito.
In dettaglio, nel webinar prima di addentrarsi nella configurazione e in tutti i casini del caso si è giustamente domandato il "perché" andare su GTM Server side; la cosa simpatica è che ha indicato essenzialmente dei motivi che ho trovato in un suo vecchio articolo. Questi motivi sono:

1. Con GTM server side si ha un incremento di velocità del sito quindi si ha a tutti gli effetti un aumento a livelo di ranking SEO.
2. Con GTM "classic" sono possibili delle alterazioni degli script da parte dei browser mentre con GTM Server side no
3. Con GTM "classic" sono possibili dei blocchi delle richieste da parte dei browser (adBlock, Ghostery)
4. C’è la problematica del Cookiegeddon

Io ci ho pensato a fondo e non sono del tutto d'accordo.
Per quanto concerne il punto 1 è vero che vengono caricati meno JS per l'invio dei dati (perché tutto passa dal server) tuttavia parliamo di script JS solitamente impostati come deferred quindi poco impattanti, inoltre tutti gli attivatori di GTM ci sono in ogni caso....quindi sì...si ha un'aumento delle prestazioni ma è veramente di poco conto a meno che non ci si appoggi a 500 servizi terzi.
Per quanto concerne il punto 2 è verissimo tuttavia parliamo di computer compromessi dove gira del codice malevolo quindi...ci dobbiamo preoccupare anche se gli utenti installano antivirus et similia? Inoltre, non credo proprio che il codice malevolo si interessi di non segnalare a Facebook (ad esempio) il tracciamento di un carrello o altro...quindi boh...per me è un falso problema
Per quanto concerne il punto 3 è assolutamente vero, tuttavia se è un utente ha installato adBlock allora consenzientemente ha deciso di non far passare alcuni dati e non essere tracciato...non è la stessa cosa che non dare il consenso per la GDPR? Discorso diverso se a livello di sistema operativo o browser il produttore di turno (ad esempio Apple) ha deciso di implementare un AdBlock nativo...allora il ragionamento ci può stare. A me non risulta però che sia così, mi sbaglio?
In ultimo il 4° punto e cioè la Cookiegeddon c'è a prescindere sia che parliamo di GTM classico che di Server Side

Se quanto indico è vero allora mi domando....chi me/ce lo fa fare di impazzire dietro GTM server side?
Mi scuso per il post fiume ma è per una giusta condivisione, ovviamente sono aperto a confronti o smentite costruttive

Gianluca

@giovanni-bertagna ha detto in Ghost in Italiano: chi ci ha lavorato?:

@pinguinone No, scusa. Ho migrato il blog che avevo su WordPress a Ghost grazie a un plugin per quest'ultimo.
Per ora il sito statico che ho con Hugo è sempre li ma l'idea è di chiuderlo e mantenere solo il Blog su #Ghost.
Copiare gli articoli da #Hugo a Ghost è piuttosto facile visto che sono già scritti in #Markdown che è supportato anche da Ghost. Basta fare un copia/incolla.

Chiaro, grazie della tua risposta ma, come al solito accade, da risposta nasce nuova domanda e, in questo caso, dovrebbe anche aiutare alla community.
Da quel poco che ho capito di Ghost (lo sto studiando) questo può diventare anche solo il backend per un sito fatto in Hugo quindi, se quanto dico è corretto, si può mantenere il sito fatto "così-com'è" in Hugo, cambiare solo il template (dicendo di prendere i contenuti tramite remoto e non dai file) e usare Ghost come backend.
Dico castronerie o per la tua esperienza può avere un senso?

@giovanni-bertagna ciao e grazie per la risposta, quando indichi "migrato a Ghost" intendi che Ghost aggiorna il sito fatto in Hugo?

@giovanni-bertagna ha detto in Ghost in Italiano: chi ci ha lavorato?:

Attualmente ho un blog su WordPress e un diario personale realizzato con #Hugo, volevo valutare se di spostare uno dei due.

Ciao, resuscito questo post. Ho creato un tema piuttosto complesso con che sto utilizzando su diversi siti in produzione. Stavo pensando di utilizzare #Ghost per rendere "semplice" la fase di aggiornamento contenuti e/o inserimento di nuovi contenuti. Tu hai poi migrato? Se sì come ti sei trovato?
Grazie