Un breve aggiornamento sugli ulteriori sviluppi per completare il quadro con tutte le informazioni.

L'assistenza mi ha spiegato che i loro nameserver non "parleranno" con quelli di enom ma saranno scelti a caso una volta gli uni e una volta gli altri (perciò in caso di down di uno dei due servizi qualche risposta potrebbe essere negativa lo stesso), e ha consigliato di sostituirli tutti o nessuno nelle impostazioni del pannello.
Così ho sostituito i nameserver di enom ai loro e a questo punto il sito è servito interamente dai nameserver di enom.

In pratica, alla fine ho solo affidato il servizio DNS a un provider diverso da quello che ha registrato il dominio. Può sembrare una differenza da poco ma in realtà rappresenta esattamente la soluzione che cercavo, tanto che me la sentirei di consigliarla.

Infatti in questo modo un eventuale down dei nameserver del provider che ha registrato il dominio non avrebbe conseguenze e d'altra parte un down dei nameserver realmente utilizzati, pur bloccando temporaneamente l'accessibilità dei siti, potrebbe essere facilmente risolto resettando i nameserver di default dal pannello del provider che ha registrato il dominio.

In conclusione, al costo di circa 5 euro all'anno mi sono messo al riparo dal rischio di ritrovarmi nella brutta situazione descritta all'inizio (brutta, fidatevi) coi siti irraggiungibili senza sapere se e quando torneranno online e senza poter fare nulla per migliorare le cose, che era lo scopo di questa discussione.

Concordo totalmente e nel corso di questa istruttiva discussione mi sembra di aver trovato una buona soluzione che voglio condividere.

In pratica ho acquistato il servizio DNS hosting di enom, che al costo di circa 5 € all'anno mette a disposizione i suoi 5 nameserver anche a domini registrati presso altri registrar, e ne ho aggiunti due dei loro (uno del Kansas e uno del Canada) ai DNS presso il registrar italiano.
Così, al costo di 17 € all'anno ogni dominio ha i DNS su 6 nameserver di due provider diversi (e anche questa è una cosa che mi piace): uno a Roma, tre in Umbria, uno in Kansas e uno in Canada. Dovrei essere veramente in una botte di ferro.

Sì ho controllato i domini che ho con enom: sono su 5 nameserver, tre risultano in Kansas e due in Canada. Al costo annuo di 17 USD (15 €) a dominio, inclusa ovviamente la registrazione annuale.
Ma anche il registrar italiano che ha avuto i problemi all'origine di questa discussione (a quanto pare superati) fornisce 4 nameserver di default, uno a Roma e tre in Umbria, al costo di 12 € all'anno inclusa registrazione.

Di norma i registrar assegnano 4 o 5 nameserver a tutti i domini senza chiedere se siano parcheggiati o popolari, perché evidentemente assegnarli a tutti di default non rappresenta un costo aggiuntivo particolarmente gravoso, probabilmente gli costerebbe di più decidere a chi assegnarne solo due e a chi cinque.
I nameserver stanno lì, se il dominio è parcheggiato non arriva nessuna query e quindi non c'è neanche utilizzo di cpu, lo spazio per i record DNS è trascurabile, non vedo lo spreco di risorse.

Anche a me non sembra poi così strano che google metta dei quality rater umani a vigilare le serp più importanti e che le loro valutazioni possano portare ad aggiustamenti degli algoritmi.
Nei panni di google farei esattamente lo stesso.

Ovviamente non possono vigilare sulla selezione operata dagli algoritmi sui miliardi di pagine in rete, se non a campione, ma a valle di questa, sull'ordinamento delle pagine migliori già eseguito dagli algoritmi nelle varie serp, non vedo perché no.

Quello che succede veramente non lo sappiamo ma non mi sembra così inverosimile, 10.000 qr nel mondo non sono neanche pochi. Metti che in proporzione possano essere un centinaio in Italia: suddivisi in gruppi per settore di competenza e impegnati a tempo pieno a controllare le serp principali un certo effetto qualitativo potrebbero averlo.

Non volevo nominarla ma mi riferivo proprio a gidinet nella frase "Non vorrei che fosse solo un'operazione commerciale di Godaddy e pochi altri.".

Il fatto è che cercando "DNS premium" ho trovato solo godaddy e gidinet che offrono questa opzione (e dato che gidinet non figura tra i registrar accreditati ICANN sembra probabile che si appoggi a godaddy). Non ho trovato nessuno degli altri registrar più importanti a livello mondiale, tra cui appunto enom, che offra la stessa opzione.
Il che non vuol dire, a mio parere, che gli altri servizi non abbiano una ridondanza di nameserver tale da offrire le medesime garanzie di sicurezza, semplicemente non se la fanno pagare a caro prezzo perché nei DNS il massimo livello di sicurezza dev'essere implicito, di default.

Insomma, in base alle informazioni che ho potuto reperire in rete mi sono fatto l'idea che questa offerta sia soprattutto la trovata commerciale di qualche top manager di godaddy per farsi pagare i domini quattro o cinque volte il giusto. Naturalmente sono pronto a cambiarla in presenza di nuove informazioni, sempre gradite.

Io me l'aspetto che un server o il Vps noleggiato anche presso un buon provider possa andare incontro a un down, perciò ci sono le offerte con una certa percentuale di up garantita ma i DNS no, devono essere sempre attivi al 100% del tempo di default, il numero massimo di down tollerabili per un servizio DNS è zero (a parte i down storici famosi ma è un altro discorso). Un servizio a pagamento per la ridondanza dei nameserver mi fa l'effetto di un taxista che mi chiedesse un supplemento per il servofreno.

Ciao 2018, ma no non è avarizia, figurati il costo dei domini, premium o no, è sempre abbastanza irrisorio rispetto ai danni se qualcosa va storto.
Questi sono domini che tenevo da più di dieci anni con un registrar italiano di buon livello senza mai un problema. Quelli nuovi di solito li registro con enom, il secondo registrar a livello mondiale e mi sono sempre sentito tranquillo.

Ora vedo che godaddy, e mi pare qualcun altro, ha questa opzione DNS premium con più nameserver.
Sinceramente mi stupisce: io l'ho sempre dato per scontato che anche il registrar più scarso avesse i nameserver ridondati, perfino io tengo sempre i miei siti su due server in parallelo, in caso ne andasse giù uno cambio i record dns e via, m'è capitato più di una volta.
Non credevo si dovesse pagare un plus per avere la ridondanza dei nameserver ma vedo che per godaddy è davvero così, addirittura scrive "Le interruzioni dell’alimentazione e i problemi di routing internet possono causare l’inattività del tuo DNS primario, rendendo il tuo sito web non disponibile e piantando in asso i visitatori.", e grazie, dico io, che scoperta, e per evitarlo bisogna pagare un supplemento? Eppure appunto pare che sia proprio così.

Sul sito di enom dove ho gli altri miei siti non mi sembra che ci sia nessuna opzione premium, per cui tendo a pensare che i nameserver siano ridondati il giusto di default, come mi pare dovrebbe essere.

Grazie dell'info, comunque. Se sarà necessario, ammesso che enom abbia l'opzione perché non l'ho proprio trovata, attiverò i dns premium, anche se la cifra che vedo su godaddy, di 2,99 usd/mese non mi sembra una frazione del costo del dominio ma mi pare che lo triplichi.

Aggiungo che anche il registrar italiano, quello che sta avendo i problemi, a quanto pare forse in via di superamento, non offre nessuna opzione DNS premium, per cui anche volendo non avrei potuto farla senza trasferire il dominio.
Non vorrei che fosse solo un'operazione commerciale di Godaddy e pochi altri.

Sì, hanno risposto che sono sotto attacco. Sono tornati attivi per un po' e adesso sono di nuovo down, per fortuna in quel frattempo ho recuperato gli auth code e ho già chiesto il trasferimento ad altro registrar, che non partirà prima di lunedì. Ora qualche sito è accessibile e qualcun altro no, credo dipenda dalla diversa propagazione dei DNS nelle cache delle reti.
Comunque è un sistema terribilmente vulnerabile, in pratica siamo nelle mani del registrar: possiamo solo sperare che sia sempre ok e che se qualcosa non va ci sia almeno il tempo di recuperare gli auth code come in questo caso, altrimenti è una sentenza definitiva, fa paura pensarci.

Io d'ora in poi richiederò gli auth code periodicamente in modo da averne sempre uno aggiornato: mai più senza auth code.

Ciao, sono .com ma stamattina c'è qualche segnale di vita: il loro sito è tornato visibile e anche uno dei miei siti, il pannello dà ancora un errore perl e nessuno risponde alle mie mail ma l'impressione è che stiano remando per mettere a posto le cose. Speriamo bene, anche perché non me l'aspettavo e non avevo neanche preso gli auth code, non vedo l'ora che il pannello sia accessibile per recuperarli, consiglio a tutti di annotarseli per bene.

Uno dei registrar dove tengo i record DNS dei miei siti è down da oggi e il suo stesso sito non è accessibile, tutti i miei siti con DNS da loro sono down da ore, non riesco a contattarli e sono francamente preoccupato.

Ho deciso di chiedere il trasferimento dei .com ad altro registrar ma pare siano necessari circa 14 giorni, un tempo che mi sembra lunghissimo. Nel frattempo i miei siti rischiano di uscire da tutte le serp e temo che google potrebbe anche interpretarla come una sospensione definitiva e non provvisoria.
Qualcuno sa se c'è un modo più rapido per cambiare registrar o se è prevista qualche tutela nel caso che i DNS presso un registrar diventino inaccessibili da un giorno all'altro? Ma questi registrar qualche garanzia non la dovrebbero offrire?

Mi è capitato spesso di avere problemi coi servizi che fornivano il server ma bastava portare il backup su un altro server di un'altra società e ripuntare i DNS per ripristinare i siti, questione di qualche ora al massimo. Un down dei DNS del registrar non mi era mai capitato in tanti anni, sembra decisamente più catastrofico e non so cosa fare.

@444523 said:

Cliccando dalla serp una pagina finta https si finiva comunque su una pagina con l'indirizzo https:// ma solo nominale, infatti non appariva il lucchetto del criptato... ma appariva https:// all'inizio della stringa, sono davvero tante pagine, quasi un terzo del sito.
In questo caso https dovrebbe essere rosso e barrato e il browser non dovrebbe mostrare la pagina ma dare un errore di privacy tipo "La connessione non è privata", altrimenti vuol dire che in qualche modo il dominio dev'essere collegato a un certificato.
Hai provate a fare un check ssl del dominio per esempio con SSL checker?

Se gli url sono rimasti gli stessi il calo potrebbe anche dipendere dalla minore velocità delle pagine dinamiche rispetto a quelle statiche.

Confrontando la settimana dal 12 al 18 marzo con quella dal 12 al 18 febbraio registro una crescita significativa del traffico da google su due siti: su uno del 33% e sull'altro del 90%.
L'impennata parte proprio dal 12 marzo (su uno forse più dal 13 ma con un lieve aumento anche nei due giorni precedenti).
La variazione sembra molto evidente, anche perché confrontando i primi 11 giorni di marzo con i primi 11 giorni di febbraio uno dei siti era in crescita solo del 3% e l'altro stava addirittura calando del 5%, comunque oscillazioni nella norma.
Mi pare anche che l'aumento si sia subito stabilizzato.

@hub said:

Ciao, siamo sicuri che il test con Pagespeed, che di recente ha cambiato metodo di analisi, sia realmente ciò che percepisce l'utente?
Probabilmente no ma per me la questione è un'altra: se sia realmente ciò che percepisce google.

Mi spiego, io non ho dubbi che le mie pagine siano veloci per l'utente, le ho provate su smartphone veri, sugli emulatori e sui vari tools: sono sostanzialmente immediate sia come caricamento che interattività e in assenza di banner lo stesso pagespeed assegna a tutte un punteggio di 100 o poco meno anche su mobile.
Ma se ci sono i banner (asincroni, da sempre) pagespeed giudica le stesse pagine molto lente, e pagespeed è google.

Il punto è che pagespeed calcola e memorizza i dati sul campo di velocità degli ultimi 30 giorni sia delle singole pagine che dell'intero sito e dato che la velocità è un fattore di ranking mi sembra ragionevole pensare che una valutazione "slow" di questi dati possa influire sul posizionamento. A voi no?
Immagino che ci siano delle soglie a tale scopo, non necessariamente le stesse dei colori verde giallo e rosso dei punteggi ma insomma preferirei vedere i dati sul campo nella fascia gialla average che in quella rossa slow (intendo quelli dei dispositivi mobili, i dati su desktop temo che non siano significativi).

Ciao crocgames, confermo la tua osservazione: la presenza dei banner porta la velocità di una pagina da "elevata" o "media" a decisamente "bassa" su pagespeed e anche l'origine, ossia l'intero sito, in presenza di banner su tutte le pagine può venire etichettato come "Slow" (in "Origin Summary"). Non è possibile dire se questo possa avere effetti negativi sul posizionamento ma dato che la velocità di caricamento rientra nei fattori di ranking sembra ragionevole occuparsene.

Nel tentativo di risolvere il problema, che sto seguendo da qualche tempo, ho ottimizzato tutto il possibile fino ad arrivare a un punteggio di 100 sia su dispositivi mobili che su desktop, poi però inserendo i banner la velocità di caricamento torna subito "bassa", con pagespeed che suggerisce una serie di ottimizzazioni su elementi interni ai banner (no comment).

Personalmente non credo che google scorpori la velocità dei banner da quella degli altri elementi della pagina: la velocità di caricamento è quella che è in base a tutti gli elementi presenti, se i banner sono lenti la pagina diventa effettivamente lenta (ho provato con annunci sincroni e asincroni senza notare alcuna differenza).

In conclusione mi pare che per restare almeno nella fascia media di velocità si dovrebbe limitare il numero di banner a un massimo di uno per pagina, scelta che però in certi casi può portare una drastica riduzione delle entrate.

Terribile, aggiungo che cercando per esempio il nome del sito nel primo riquadro rosso esce la home page con la scritta "Questo sito potrebbe essere compromesso.".
Quindi sanno che il sito ha dei problemi, mettono in guardia l'utente sulla home page (che appare regolare) e mostrano le pagine abusive in prima pagina nelle serp competitive senza nessun avviso: non dà l'impressione di un gran controllo.

@korkal, confermo in pieno: neanch'io ho notato conseguenze negative apparentemente riconducibili al fenomeno, perciò tendo appunto a pensare che sia "normale". Metto anch'io le virgolette a normale perché comunque la risposta non raggiungibile da parte del bot di google mi rende nervoso.

@Sermatica, le risorse esterne sono spesso inaccessibili (generalmente con riferimento al file robots.txt) ma in tal caso considero la scansione della pagina perfettamente eseguita, anche se parziale: a me interessa solo che scansioni le mie pagine. Il fatto è che nella mia search console ultimamente risultano spesso inaccessibili anche le pagine interne con la ragione "Temporaneamente non raggiungibile". A volte ho notato anche pagine esterne (di googlead) non scansionate per la stessa ragione "Temporaneamente non raggiungibile" ma lo dicevo solo come indicatore che il problema sembrerebbe esteso anche ad altri server.

Ciao korkal, ho notato anch'io lo stesso problema che non si era mai presentato prima, comparso improvvisamente, direi da settembre su siti dove non è stato toccato niente.
Nel mio caso succede questo:

1. La funzione "Recupera" (senza visualizza) funziona sempre regolarmente, esegue la scansione completa di qualsiasi pagina senza problemi;
2. Con "Recupera e visualizza", la risposta può presentare tre diverse diciture nella colonna "Stato":
   2.a) "Temporaneamente non raggiungibile" e non scansiona nulla;
   2.b) "Parziale", scansiona la pagina ma specifica "Impossibile per Googlebot recuperare tutte le risorse per questa pagina" ed elenca le risorse non recuperabili con la ragione "Temporaneamente non raggiungibile";
   2.c) "Fine" ("Complete" nella versione inglese) scansiona perfettamente la pagina e le risorse collegate.

La risposta sembrerebbe totalmente random: ripetendo la scansione della stessa pagina a distanza di pochi minuti è possibile ottenere tutte e tre le diverse risposte. Statisticamente, all'inizio capitava più spesso che non scansionasse nulla, adesso succede più raramente, il caso più frequente è il secondo di scansione parziale ma fortunatamente anche quello di scansione completa.
In pratica, se voglio inviare una pagina all'indice insisto finché ottengo una scansione completa con stato "Fine" e a quel punto la invio all'indice.
Non so quale possa essere la ragione di questo comportamento, ho notato che tra le risorse collegate "Temporaneamente non raggiungibili" figurano a volte anche pagine di googleads, perciò dubito che si possa risolvere con interventi sul server.
D'altra parte, se le pagine risultassero "Temporaneamente non raggiungibili" anche durante la normale attività automatica di scansione del bot, la cosa potrebbe avere conseguenze sull'indicizzazione e sul posizionamento perciò il problema meriterebbe di essere approfondito e possibilmente risolto ma finora non ho trovato spiegazioni o soluzioni.

Ciao Gabriella Poggiali, bisogna distinguere tra url che esistono sul tuo sito e url che, pur non esistendo più sul tuo sito, compaiono ancora in serp perché sono negli indici e nelle cache di google. In quest'ultimo caso anche "Visualizza come Google" darebbe la pagina inesistente, se invece mostra una pagina con i redirect vuol dire che quella pagina esiste tuttora sul sito.

A parte questo, in ogni caso anche "ripulire" il sito, nel senso di eliminare le pagine collegate agli url indesiderati, non è sufficiente perché può essere necessario un certo tempo, anche lungo, prima che siano rimosse dagli indici, e quindi continueranno a comparire in serp.
In un caso simile ho creato una pagina vuota o dal contenuto innocuo per ogni url indesiderato, con un metatag <robots="noindex">: quando il crawl di google carica la pagina, trova il noindex e rimuove l'url dalle serp. Per velocizzare il processo le inviavo agli indici via "Visualizza come Google".

Per verificare la rimozione bisogna poi controllare sulle serp vere e proprie e non con site: perché ho notato che a volte, pur essendo una pagina rimossa da tutte le serp, continua a comparire per un po' nel comando site, che probabilmente segue regole diverse.

La stessa pagina della guida, nel paragrafo successivo "Mettere in pausa le richieste di annunci" alla voce "Se utilizzi il codice dell'annuncio asincrono AdSense o Ad Exchange:" fornisce uno schema in 5 punti con le istruzioni, che richiedono una certa conoscenza di javascript per essere comprese e applicate ma non comportano modifiche del codice adsense.

Ciao massimodefilippo,
non mi risulta che "Bisogna modificare l'ultima riga del codice di ogni ads".

Sulla guida c'è scritto "Imposta il valore (adsbygoogle=window.adsbygoogle||[]).requestNonPersonalizedAds=1", che è cosa diversa e non comporta modifiche del codice adsense.