• User

    Tutta colpa del server?

    La prendo larga, perdonatemi: il mio lavoro è scrivere e sono un po' capra, sul fronte tecnico. La domanda riguarda un progetto personale, un piccolo blog.

    In Search Console ho trovato questo avviso, riguardo gli ultimi tre articoli pubblicati sul mio bloggino: "Rilevata, ma attualmente non indicizzata. Stato: Pagina esclusa".
    Non mi era mai capitata una cosa del genere e gli altri articoli vanno come al solito. Ho cambiato tema, è vero, ma solo dopo la comparsa del problema di indicizzazione. Tra l'altro, il tema nuovo è più leggero di quello vecchio e non ho nè fatto redirect nè modificato impostazioni.

    In Search Console, Google mi dice che praticamente tutte le pagine del sito hanno la LCP troppo alta da mobile. In effetti, PageSpeed mi dice che tutti i segnali web essenziali sono perfetti, tranne la LCP. Dato che Google sta privilegiando sempre di più il mobile, mi viene il dubbio che la causa della mancata indicizzazione sia quella.

    Ho provato in tutti i modi a correggere il parametro (ho cambiato tema anche per quello), ma niente. A questo punto mi chiedo se non sia colpa di hosting e database, entrambi Aruba. Lo so, Aruba non è propriamente un top di gamma (anzi), ma ero convinta fosse sufficiente per le mie esigenze.

    Grazie a chiunque vorrà darmi una mano e scusate per il papiro. Se dovesse essere colpa dell'hosting, si accettano suggerimenti per il cambio.


    SeoWebCoach kal sermatica 3 Risposte
  • User

    @lucia-zambrano Ciao! io controllerei:

    sitemap.xml
    robots.txt
    Il Canonical

    Controlla se la pagina è inclusa nella sitemap.xml e che nel robots.txt (o nel codice della pagina non sia inserito un meta tag robots con un noindex) non sia stata esclusa dall'indicizzazione. Secondo mè Google ha trovato un pò di confusione in uno di questi passaggi e potrebbe aver trovato un contenuto bloccato "all'indexing" o momentaneamente non raggiungibile.

    Sarebbe l'unico modo per così dire "dare la colpa al server" perchè se lo spider passa e non trova lo stato 200 OK della pagina "passa avanti" e sei costretta ad aspettarlo al prossimo passaggio (di conseguenza rimane congelato fino alla prossima scansione).

    Attribuisci il rel canonical per una maggiore precisione sulla genitorialità del contenuto in questione...

    Io farei così 😉


    L 1 Risposta
  • User

    @SeoWebCoach prima di tutto, grazie mille. Ho controllato sia la sitemap sia i robots e sono entrambi a posto, salvo sviste (ma non credo).
    Per quanto riguarda il canonical, ma non serve in caso di contenuti duplicati o molto simili ad altri contenuti sul sito? Forse ricordo male.


  • Moderatrice

    Ciao Lucia, non posso aiutarti, anche io sono in attesa dello spider di Google. Situazione analoga alla tua, tutto ok sitemap, robots, canonical e permessi del server. Dopo un cambio di layout per un progetto che gestisco, alcuni url senza redirects, attualmente online, veloci da caricare, senza no index, comunicati con sitemap, mi giocano questo scherzo.


    L 1 Risposta
  • User

    @lulu3 mal comune...

    Avevo già accennato al problema in un'altra discussione, però mi chiedevo se hosting e segnali web essenziali potessero avere un ruolo. Da questo punto di vista, com'è messo il tuo sito? I segnali web essenziali sono buoni?
    Sto cercando di capire se è colpa mia, in qualche modo, o devo aspettare che "papà Google" posi il suo occhio benevolo su di me.


  • Moderatrice

    Putroppo a parte due pagine, i segnali web essenziali sono buoni. P.s. non è il mio sito 🙂 Ho modo però di accedere alla console. Appena risolveremo la questione, passerò da queste parti. Spero presto.


  • User

    Bà... parliamo di indicizzazione quindi niente di preoccupante... (intendo dire che è risolvibile assolutamente) se è tutto corretto e la pagina non ha nessun blocco voluto o non voluto allora si potrebbe tener traccia del lavoro del server con un server monitor che ti avvisa quando c'è un down e quanto tempo è durato.

    Un Hosting, qualsiasi esso sia, può avere dei down + o meno brevi e questo può essere un limite se accade proprio quando lo spider passa a trovarci.

    Quindi se la pagina non è bloccata agli spider (nè sul robots nè con un meta tag) è inclusa nella sitemap e non ci sono contenuti simili (quì il mio consiglio per raggiungere il rel canonical) allora si tratterebbe, sempre secondo me, della poca importanza della pagina nel venire scansionata con maggiore frequenza oppure il server ha avuto un down e non ha reso la pagina disponibile e raggiungibile.

    Per la questione dei segnali web, non gli darei troppa importanza per questa "storia" qualsiasi sito può essere indicizzato (cioè semplicemente incluso nel data-center di Big G) anche se ha delle performance incredibilmente scarse. Ciò influirebbe se avesse degli obiettivi di posizionamento... 😉


    lulu3 2 Risposte
  • User Attivo

    @lucia-zambrano ha detto in Tutta colpa del server?:

    Rilevata, ma attualmente non indicizzata.

    Questo messaggio significa molto probabilmente che Google ha rilevato il tuo URL, sa che la pagina esiste, ma non l'ha ancora scansionata.

    In parole povere: è Google che è pigro.

    Non me ne curerei molto, in questo periodo succede a tutti.


    lulu3 1 Risposta
  • User

    @lulu3 sì, "tuo" in senso lato :d:

    @SeoWebCoach vediamo se cavo fuori qualcosa dal server monitor: tanto vale tentare.

    @kal eh, lo so, ma quasi quasi speravo di aver combinato io qualche casino tecnico.


  • Moderatrice

    @kal ha detto in Tutta colpa del server?:

    @lucia-zambrano ha detto in Tutta colpa del server?:

    Rilevata, ma attualmente non indicizzata.

    Questo messaggio significa molto probabilmente che Google ha rilevato il tuo URL, sa che la pagina esiste, ma non l'ha ancora scansionata.

    In parole povere: è Google che è pigro.

    Non me ne curerei molto, in questo periodo succede a tutti.

    succede a tutti è molto rassicurante e vero.


  • Moderatrice

    @SeoWebCoach grazie comunque per queste best practice condivise.


  • Moderatrice

    @SeoWebCoach ha detto in Tutta colpa del server?:

    Bà... parliamo di indicizzazione quindi niente di preoccupante... (intendo dire che è risolvibile assolutamente) se è tutto corretto e la pagina non ha nessun blocco voluto o non voluto allora si potrebbe tener traccia del lavoro del server con un server monitor che ti avvisa quando c'è un down e quanto tempo è durato.

    Un Hosting, qualsiasi esso sia, può avere dei down + o meno brevi e questo può essere un limite se accade proprio quando lo spider passa a trovarci.

    Quindi se la pagina non è bloccata agli spider (nè sul robots nè con un meta tag) è inclusa nella sitemap e non ci sono contenuti simili (quì il mio consiglio per raggiungere il rel canonical) allora si tratterebbe, sempre secondo me, della poca importanza della pagina nel venire scansionata con maggiore frequenza oppure il server ha avuto un down e non ha reso la pagina disponibile e raggiungibile.

    Per la questione dei segnali web, non gli darei troppa importanza per questa "storia" qualsiasi sito può essere indicizzato (cioè semplicemente incluso nel data-center di Big G) anche se ha delle performance incredibilmente scarse. Ciò influirebbe se avesse degli obiettivi di posizionamento... 😉

    intendo queste, devo ancora imparare bene a usare il tasto cita.


  • Moderatore

    @lucia-zambrano ha detto in Tutta colpa del server?:

    "Rilevata, ma attualmente non indicizzata. Stato: Pagina esclusa".

    Ciao, che url sono? A volte mi è successo quanto sotto. Hai provato a fare una scansione con Screaming Frog?

    • Sito con gestione errata delle Url che generava contenuti Duplicati
    • Sito che generata Url "Infinite"
    • Google che non sapendo cosa fare mette li Url a caso

  • Moderatore

    Ciao Lucia, per quanto riguarda le performance è fondamentale andare a suddividere l'analisi di chi è lento in 2 macro famiglie:

    • server
    • client

    (qui scrissi 2 righe in merito https://blog.merlinox.com/server-client-e-tempi-di-risposta/)

    Considera che FCP e LCP sono tempi client, che ovviamente sono la sommatoria del tempo server + il tempo client.
    Cosa significa: che se il server è lentissimo (tempi di risposta sopra i 1000 ms) FCP e LPC partiranno aggravati, anche se hai un frontend velocissimo.

    Se invece i tempi server sono veloci (tempi di risposta sotto i 500 ms) bisogna lavorare su layout (html, js, css, immagini).

    I tempi di risposta li puoi vedere da GSC o da Chrome UX (dato TTFB).

    Per quanto riguarda lo stato "l'ho letta ma non indicizzata" può essere uno stato temporaneo: da mesi Google soffre di una grossissima crisi e ho numerosi progetti con problemi di re-indicizzazione, nuova-indicizzazione, migrazione.

    Accertata che tutte le cose sintattiche siano ok (robots vari e canonical) verifica che i contenuti (intento di risposta) siano diversificati tra le pagine e non ci sia dubbio di contenuti troppo simili.

    Ciao


    L 1 Risposta
  • User

    @sermatica ho fatto fare un giro a Screaming Frog e sembra tutto a posto: a quanto pare, ho fatto le cose a modino.

    @merlinox questa risposta continua a venire fuori e non so se esserne sollevata: quando la colpa di un problema è mia, quanto meno posso agire per risolverlo. Se invece è colpa di Google... Beh, in quel caso mi attacco.
    Ad ogni modo, è l'occasione per verificare la velocità di questo benedetto server, per capire quanto e se parto svantaggiata e agire di conseguenza. Grazie mille per la spiegazione molto chiara.


    merlinox 1 Risposta
  • Moderatore

    @lucia-zambrano ha detto in Tutta colpa del server?:

    Se invece è colpa di Google

    In questo momento la colpa di Google può essere la comprovata lentezza a indicizzare/reindicizzare.
    Non possiamo farci nulla... anche Index API è abbastanza light... diciamo.
    Quello che puoi controllare (dai log) è se Google a letto-riletto le pagine coinvolte.
    Eventualmente valutare il "link score" di quelle pagine, tipo proprio con Screming Frog.

    A questo punto esci le metriche di velocità:

    • ttfb
    • tempi di risposta
    • tempi FCP / LCP / OnLoad

  • User

    Prendendo ad esempio il primo degli articoli caricati, che non ha né immagini né video, per il mobile PageSpeed mi dice:

    First Contentful Paint: 2,9 s
    Speed Index :6,8 s
    Largest Contentful Paint: 4,6 s
    Time to Interactive: 4,7 s
    Total Blocking Time: 180 ms
    Cumulative Layout Shift: 0
    First Input Delay: 23 ms

    Pingdom invece mi attribuisce un performance grade di 90, con un tempo di caricamento di 448 ms. Mi sa che però è tarato sul desktop, che risulta bello scattante anche con PageSpeed.


    merlinox 1 Risposta
  • Moderatore

    @lucia-zambrano ok quello è un tempo istantaneo e cmq su LCP siamo alti.
    Chrome UX che ti dice?
    https://web.dev/chrome-ux-report-data-studio-dashboard/
    (considera che per ora DICONO non siano considerati a livello di rank)

    Lato tempi risposta GSC di Googlebot?


    L 1 Risposta
  • User

    @merlinox GSC come valore LCP aggregato mi dà 4,3 secondi, quindi abbastanza una schifezza.
    Chrome UX mi dà questi valori:

    • First Contentful Paint: 2.8 s
    • Time to Interactive: 4.6 s
    • Speed Index: 5.3 s
    • Total Blocking Time: 130 ms
    • Cumulative Layout Shift: 0
    • Largest Contentful Paint: 4.5 s

    Il tempo di risposta del server è 750 ms. Il resto non è nemmeno male: mi intima di "Does not use passive listeners to improve scrolling performance", ma nient'altro di serio.


    merlinox 1 Risposta
  • Moderatore

    @lucia-zambrano Tematica del sito? 750 ms non sono proprio pochi.
    Com'è messa la concorrenza?
    (lì lo misuri con il Chrome UX report, prendendo i dati da BigQuery o personalizzandoti il report Data Studio)


    L 1 Risposta