• User

    Quindi come posso risolvere?


  • User Attivo

    correggendo la gestione degli errori lato server. a pagine inesistenti deve corrispondere un errore 404.


  • User

    Ok, approfondirò questo argomento tramite google ma se digitando quell'indirizzo il browser mi visualizza sia il file di google per la verifica sia la home digitado il dominio senza index non capisco cosa centri questa destione lato server.
    Vorrei capire come percepisce questo errore google se non ci incorre.


  • Moderatore

    @Derbai said:

    Ok, approfondirò questo argomento tramite google ma se digitando quell'indirizzo il browser mi visualizza sia il file di google per la verifica sia la home digitado il dominio senza index non capisco cosa centri questa destione lato server.
    Vorrei capire come percepisce questo errore google se non ci incorre.
    Secondo me, il processo di verifica si compone di due accessi.

    1. Un accesso al file di verifica, quello di tipo google_XXXXX326426.html, che deve riuscire (codice 200)
    2. Un tentativo di accesso a un file inesistente, con un nome di tipo noexist_XXXXX326426, che deve fallire (codice 404)
      Infatti è frequente trovare nei log tentativi di accesso a file sicuramente inesistenti, costruiti come il file di verifica ma con il prefisso noexist_ invece di google_, vedi giorgiotave.it/forum/google/86928-google-noexist_08943xxxxxxxxx-html.html.
      Per completare la verifica deve andare a buon fine l'accesso al file di verifica google_XXXXX326426.html e deve fallire l'accesso al file inesistente noexist_XXXXX326426.html.
      Infatti, se una particolare gestione degli errori restituisce un codice valido anche per gli accessi a file inesistenti, allora la riuscita dell'accesso al file di verifica non può essere considerata prova dell'effettiva esistenza del file di verifica sul sito da verificare, e quindi la verifica, giustamente, non va a buon fine.
      Naturalmente si tratta di una ricostruzione, ma mi sembra l'unica che possa spiegare i tentativi di accesso a file (certamente inesistenti) di tipo noexist_XXXXX326426 che si ritrovano nei log e il fatto che, effettivamente, in presenza di una gestione degli errori che non restituisce errore 404 sugli accessi a files inesistenti, la verifica del sito tramite file diventa impossibile.

  • User

    Ok, ma nel mio case se provo ad accedere ad un file inesistente ho una risposta 404 quindi dovrebbe andare bene.

    La tua spiegazine potrebbe andarmi bene per la verifica (anche se poi i fatti nel mio caso non confermano) ma per la home senza index? Potrebbero le 2 cose essere collegate?


  • Moderatore

    @Derbai said:

    Ok, ma nel mio case se provo ad accedere ad un file inesistente ho una risposta 404 quindi dovrebbe andare bene.
    Sì, dovrebbe andare bene.

    @Derbai said:

    La tua spiegazine potrebbe andarmi bene per la verifica (anche se poi i fatti nel mio caso non confermano) ma per la home senza index? Potrebbero le 2 cose essere collegate?
    Sembra che interpreti il robot.txt come se l'accesso alla home fosse abilitato solo per certi file specifici, tra cui appunto l'index, e disabilitato per tutti gli altri. Questo potrebbe forse spiegare e collegare i 2 fenomeni.
    Hai provato ad analizzare il robot.txt in wmt? Puoi postarlo?


  • User

    Non so cosa sia wmt ma di seguito il mio robots.txt con i dovuti aggiustamenti perchè altimenti non me lo fà inviare:

    User-agent: *
    Sitemap: http //www-miosito-com/sitemap.xml

    Lo spazio prima // ed i - a posto del . non ci sono nel file originale.


  • Moderatore

    @Derbai said:

    Non so cosa sia wmt
    Intendevo il WebMaster Tools. Nella sezione "Strumenti" c'è la funzione "Analizza robots.txt"

    @Derbai said:

    ma di seguito il mio robots.txt con i dovuti aggiustamenti perchè altimenti non me lo fà inviare:

    User-agent: *
    Sitemap: http //www-miosito-com/sitemap.xml

    Lo spazio prima // ed i - a posto del . non ci sono nel file originale.

    Che io sappia, in genere si inserisce anche la riga
    Disallow:
    per indicare che non ci sono restrizioni, come si spiega per esempio qui: giorgiotave.it/guida_posizionamento_nei_motori_di_ricerca/file_robots.php .
    Non è detto che sia quella la causa del duplice problema, ma potrebbe.
    Per accertarlo puoi provare ad aggiungere la regola Disallow: in robots.txt e ripetere il tentativo di verifica del sito attraverso il file di verifica.


  • User

    Ho aggiornato il robot ma guardando su WMT 😉 mi consiglia

    Allow: /

    Metto quello?


  • Moderatore

    @Derbai said:

    Ho aggiornato il robot ma guardando su WMT 😉 mi consiglia

    Allow: /

    Metto quello?
    Probabilmente ti riferisci al tool di wmt per la generazione del robot.txt, che effettivamente crea un robot.txt con Allow: / .
    In teoria le due regole
    Disallow:
    e
    Allow: /
    dovrebbero avere lo stesso effetto di consentire l'accesso a tutto il sito, in quanto la prima specifica che non c'è nessun file che non deve essere prelevato e la seconda che tutti i files possono essere prelevati.
    Probabilmente il Disallow: riflette meglio lo scopo naturale del robots.txt, che è quello di indicare agli spider i files da non prelevare, e in genere viene consigliato, però questa indicazione di usare Allow: / viene da fonte indubbiamente autorevole.
    Non so, io uso Disallow: e mi trovo bene, suppongo che vadano bene tutte e due le forme ma non saprei consigliarti.