• RE: Cambio struttura lingue (piccolo) sito

    @ashramcueno ha detto in Cambio struttura lingue (piccolo) sito:

    iluppato il precedente con la lingua inglese sul dominio principale, e tradotto (con plugin wordpress) in italiano su una sotto

    Ciao Nirmal,

    in generale consiglio sempre l'uso dei redirect in caso di cambio struttura degli URL.

    Come ogni cosa però, devi valutare costi e benefici.
    Se il posizionamento attuale fosse infimo, e portasse praticamente zero traffico, certo, potresti anche ignorare il problema. Ma hai detto che è un sito piccolo (poche decine di pagine?), è poi così oneroso mettere un po' di regole di redirect?

    Il caso tuo è un po' perverso perché se è possibile impostare dei redirect per tutte le pagine con un URL univoco in inglese verso l'equivalente URL nella sottocartella /en/, il caso dell'indirizzo di root non è gestibile, perché la Home Page in italiano dovrà rispondere a tale indirizzo.
    Personalmente metterei i redirect per i vecchi URL inglesi, a eccezione dell'indirizzo di root / che cambia di lingua, ma continua a esistere. Sicuramente implementerei alternate/hreflang, sia per la Home Page, che per tutte le altre pagine logiche ove esistano più versioni in lingue diverse esposte su URL diversi.

    Spero di esserti stato utile.

    postato in Posizionamento Nei Motori di Ricerca
  • RE: Aggiornamento MySQL: errore

    Aggiornamento: ho risolto! 😄
    Se attendessi l'assistenza di Aruba, diventerei vecchio.
    Posto la soluzione che magari può tornare utile a qualcuno.
    In pratica come dicevo non avevo i permessi di accesso a wp-config.php. Tramite accesso root ssh (quindi da terminale), cd .. per andare nella cartella root, var, www (ad ogni passaggio il comando ls per visualizzare il contenuto della directory), poi nomedominio.it e all'interno troviamo i file, fra cui wp-config.php. Quindi nano wp-config.php, ho sostituito l'indirizzo corretto nella stringa define('DB_HOST', '62.X.X.X');, Ctrl+S per salvare e così torna tutto funzionante!

    postato in MYSQL e altri Database
  • Aggiornamento MySQL: errore

    Da Aruba, admin.aruba.it, Database, ho fatto un upgrade dalla vecchia versione mySQL 5.5 alla consigliata 8.0. Tanto per cambiare questo ha mandato tutto in crash, inizialmente Hostname IP era 62.X.X.X, poi è diventato 31.X.X.X.
    Se accedo ad una qualunque pagina del sito web, compare "Error establishing a database connection".
    Se provo a connettermi all'area di amministrazione di WordPress, viene indicato:

    Error establishing a database connection
    This either means that the username and password information in your wp-config.php file is incorrect or we can’t contact the database server at 62.X.X.X. This could mean your host’s database server is down.

    Accedo allo spazio FTP, riesco a gestire i vari file, ma sono per qualche strano motivo sono impossibilitato a mettere mano a wp-config.php (chiaramente nemmeno mi lascia modificare i permessi a questo file)!! E non trovo da nessuna parte un accesso root. Pertanto presumo sia necessario e sufficiente modificare la stringa define('DB_HOST', '62.X.X.X'); inserendo il nuovo indirizzo, se me lo lasciasse fare.

    Ovviamente Aruba non mi consente di annullare l'operazione, tornare alla configurazione precedente (sebbene obsoleta, perfettamente funzionante) e l'assistenza che ho provato a contattare sia telefonicamente che per iscritto, è come se non esistesse.

    Avete idea di come si possa risolvere? Tutto fuori uso, quindi direi anche urgente. Grazie mille!

    postato in MYSQL e altri Database
  • RE: GA4: problema o bug nei dati Real Time

    @giulio-marchesi aggiorno: ora sembrerebbe funzionare!
    Mancava un pezzo (window.dataLayer = window.dataLayer || []; [...] gtag('config', 'G-XXX');), che poi mancava anche col vecchio ID ma funzionava ugualmente...
    Comunque confermo che così funziona, lo vedo nel real time, ho solo perso un paio di giorni di dati, pazienza.

    postato in Google Analytics e Web Analytics
  • RE: GA4: problema o bug nei dati Real Time

    @kal grazie, strano ma non ho risolto comunque. Confermo gtag.js, essendoci questo script:

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=XXX"></script>
    

    Quindi al posto del vecchio ID UA-XXX ho inserito l'ID proprietà (in GA4, dettagli proprietà), quindi del tipo 39XXX; nella sezione "assistente alla configurazione", "Raccogli i dati di siti web e app", "gestisci gli stream di dati", me lo indica come attivo e "ID misurazione" è G-C15GXXX.
    Provando a copiare sia uno che l'altro nello script, ovvero dopo id= , nessuno dei due funziona, non vedo nulla real time e anche traffico totale indicato come zero. Bo, mai successo!

    Edit. Con G-XXX qualche visita occasionale la vedo (5 minuti fa), ma ritardi a parte, il fatto che su GA vengano indicati un paio di utenti giorno quando GSC ne segna 300-400 solo di clic organici da Google, renderebbe GA4 ormai inutilizzabile. Mi pare comunque troppo strano, vedere qualche qualche singolo dato di traffico così "a random".

    postato in Google Analytics e Web Analytics
  • GA4: problema o bug nei dati Real Time

    Ho una proprietà GA4, per la quale a suo tempo avevo attivato l'opzione "Configurare automaticamente una proprietà Google Analytics 4 di base".

    Sito web con CMS WordPress, lo script di Analytics installato come semplice copia-incolla nel file header.php (mi va bene, ha sempre funzionato).

    Quando inizio una sessione giornaliera, dal login tramite analytics.google.com devo poi fare "Vai alla proprietà GA4". Fin qui tutto ok, fino a ieri. Utenti negli ultimi 30 minuti, perennemente a quota zero (cosa inverosimile, da Search Console ho circa 300-400 clic organici giornalieri). Anche simulando del traffico es. da un altro dispositivo, il Real Time non si aggiorna. Solo occasionalmente (e non comprendo il motivo!) ne compare uno, ma è molto raro e ripeto, per nulla verosimile rispetto a quelli che sono i dati reali.

    In alto nella schemata di Analytics mi compare un avviso:

    Questa proprietà è stata configurata in base alla tua proprietà Universal Analytics originale, riutilizzando i tag e le impostazioni del sito esistenti, ove possibile. Per vedere di quali impostazioni è stata eseguita la migrazione automatica, vai ad Amministrazione > Cronologia delle modifiche. Per verificare che le impostazioni migrate siano accurate, controllale nell'Assistente alla configurazione.

    Noto anche una certa lentezza nell'aggiornare i dati, ad esempio nel riepilogo, la data "ieri" ha praticamente zero traffico (cosa sempre inverosimile) e a distanza di qualche ora i dati aumentano, come se fossero mostrati in ritardo; questo in realtà l'ho già notato anche nei giorni scorsi (per capirci, si parla di 30-50 utenti e il dato poi nel corso delle ore viene "corretto" in 400, come media).

    Soprattutto è il problema del Real Time che non capisco e vorrei risolvere. Un altro sito piccolino, nato dopo e fin da subito registrato a GA4, non mi da questi problemi, Real Time e riepilogo settimanale corretto, senza un delay nell'aggiornamento dei dati.

    Vedendo lo script copiato in header.php, noto forse una discrepanza nell'ID proprietà: quello vecchio è del tipo id=UA-60*... mentre in "dettagli proprietà" di GA4 l'ID è 39*... Quindi come se precedentemente c'era un redirect che poi si è "rotto".

    Domanda, quindi copio il nuovo ID e sono a posto? Avete idea di come si possa risolvere? Grazie!

    postato in Google Analytics e Web Analytics
  • RE: Google Search Console - Robots.txt e filtri in disallow

    postato in Google Search Console e Altri Strumenti
  • RE: Google Search Console - Robots.txt e filtri in disallow

    @fcarlo93 ha detto in Google Search Console - Robots.txt e filtri in disallow:

    Facendo delle ricerche ho inteso che questo fenomeno è causato dalla direttiva del robots.txt che non permette la lettura della pagina, quindi non potendo leggere la direttiva noindex Google sta "riscoprendo"(?) e indicizzando queste pagine che però non può scansionare.

    Esatto, il problema è qui. Devi metterle noindex. Poi quando le ha viste tutte non indicizzabili metti il Disallow nel robots.txt.

    postato in Google Search Console e Altri Strumenti
  • RE: Truffa Meta

    @infermieri-attivi che i nostri siti vengano bucati, ci sta ma una multinazionale che che chiude il 2023 con ricavi record di 40,1 miliardi di dollari non credo sia comprensibile.
    Sarebbe comprensibile invece che Meta (non dico che lo agevoli) ma ne sia consapevola e non fa nulla perchè alla fine il boot gli consente di portare a casa cifra che non saprei quantificare.
    Pensa solo che un mio cliente in 2 giorni a perso 500 euro per avere email di boot, noi monitoriamo pensa a quando piccole realtà non ne siano consapevoli

    postato in Facebook
  • Truffa Meta

    Non trovo altra parola che truffa ed è molto strano che non abbia trovato nulla in giro.

    Abbiamo attivo campagne su Meta quella dei Form da compilare direttaamente su Facebook da almeno 3 anni con buoni risultati, in pratica è l'unica tipologia che ancora funziona, nel settore e con quel cliente.

    Da due mesi stiamo valutando di fermare tutto perchè stiamo pagando letteralemnte per avere dello spam, in pratica i moduli vengono compilati da Boot (un buon 50% per alcune campagne).

    Abbiamo contattato la cosidetta assistenza di Meta e ci hanno confermato che sono consapevoli del problema ma non riescono a risolvere.

    Il tutto lo trovo assurdo, ma quello he mi meraviglia è che forse se ne parla poco perchè non tutte le aziende che investono su Meta siano consapevoli del problema:
    Una soluzione temporanea è mettere in pausa quella campagne e poi rifarla, ma nel frattempo il budget investito non è rimborsabile e come si può avere fiducia in un sistema che non riesce a fermare ed impedire ai bot di compilare form o di cliccare "mi piace" ai post

    postato in Facebook