web-dev-qa-db-fra.com

Impossible de vérifier l'URL dans Google Webmaster Tools

Je veux vérifier mon URL avec _Google Webmaster tools_ mais cela ne me le permettait pas. J'ai essayé diverses méthodes, mais aucune ne semble fonctionner, et c'est peut-être parce que l'URL est transférée vers un domaine différent. J'ai une URL _.com_ transmise à mon domaine _.ca_, je peux vérifier correctement le domaine _.ca_ mais elle ne me permet pas de vérifier l'URL _.com_. Existe-t-il une astuce que je peux utiliser pour résoudre ce problème? La méthode de vérification la plus simple consiste à télécharger un fichier _.html_ et à le télécharger sur mon ftp pour le rendre accessible.

Outils pour les webmasters dit:

Confirmez le téléchargement réussi en visitant _http://example.com/GoogleID.html_ dans votre navigateur.

J'ai copié le fichier à la racine sur le serveur FTP et lorsque j'essaie de le récupérer dans Chrome, il tente de résoudre _https://example.com/GoogleID.html_, ce qui renvoie une erreur de confidentialité (en raison de HTTPS).

Pourquoi passer à HTTPS alors que l'URL _http://www.example.com/GoogleID.html_ fonctionne correctement et affiche la page correctement.

EDIT1
Mon _.htaccess_ ressemble à:

_#
# Apache/PHP/Drupal settings:
#

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
  Order allow,deny
</FilesMatch>

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Set the default handler.
DirectoryIndex index.php index.html index.htm

# Override PHP settings that cannot be changed at runtime. See
# sites/default/default.settings.php and drupal_environment_initialize() in
# includes/bootstrap.inc for settings that can be changed at runtime.

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_flag magic_quotes_gpc                 off
  php_flag magic_quotes_sybase              off
  php_flag register_globals                 off
  php_flag session.auto_start               off
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_flag mbstring.encoding_translation    off
</IfModule>

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # Set "protossl" to "s" if we were accessed via https://.  This is used later
  # if you enable "www." stripping or enforcement, in order to ensure that
  # you don't bounce between http and https.
  RewriteRule ^ - [E=protossl]
  RewriteCond %{HTTPS} on
  RewriteRule ^ - [E=protossl:s]

  # Make sure Authorization HTTP header is available to PHP
  # even when running as CGI or FastCGI.
  RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

  # Block access to "hidden" directories whose names begin with a period. This
  # includes directories used by version control systems such as Subversion or
  # Git to store control files. Files whose names begin with a period, as well
  # as the control files used by CVS, are protected by the FilesMatch directive
  # above.
  #
  # NOTE: This only works when mod_rewrite is loaded. Without mod_rewrite, it is
  # not possible to block access to entire directories from .htaccess, because
  # <DirectoryMatch> is not allowed here.
  #
  # If you do not have mod_rewrite installed, you should remove these
  # directories from your webroot or otherwise protect them from being
  # downloaded.
  RewriteRule "(^|/)\." - [F]

  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  #
  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # uncomment the following:
  # RewriteCond %{HTTP_Host} .
  # RewriteCond %{HTTP_Host} !^www\. [NC]
  # RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_Host}%{REQUEST_URI} [L,R=301]
  #
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment the following:
  # RewriteCond %{HTTP_Host} ^www\.(.+)$ [NC]
  # RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /

  # Pass all requests not referring directly to files in the filesystem to
  # index.php. Clean URLs are handled in drupal_environment_initialize().
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^ index.php [L]

  # Rules to correctly serve gzip compressed CSS and JS files.
  # Requires both mod_rewrite and mod_headers to be enabled.
  <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding
    </FilesMatch>
  </IfModule>
</IfModule>
_

Qu'est-ce qui mène exactement au problème que je rencontre et que puis-je faire pour le résoudre? Même commenter (renommer _.htaccess_ en _htaccess~_) ne résoudra pas le problème de "résolution", c’est-à-dire que l’URL _http://_ me redirige toujours vers _https://_

domainsgoogle-search-consoleurl
2
stdcerr

Cela se produit car votre site est SSL UNIQUEMENT, car votre site Web redirige toutes les demandes via un protocole HTTP 302 vers HTTPS. Actuellement, Google demande http://example.com/file.html mais votre serveur redirige cette demande vers https://www.example.com/file.html et échoue de ce fait. En d'autres termes, votre problème ne concerne pas Google, mais la configuration incorrecte de votre hôte.

Si vous souhaitez vérifier et ajouter le http://, Google devra alors accéder au site sans devoir forcer le https://. Supprimez votre redirection et le problème sera résolu.

Ce problème est facile à détecter avec CURL:

HTTP/1.1 302 Found
Location: HTTPS://LSLIB.COM/
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Sun, 29 Nov 2015 20:35:34 GMT
Content-Length: 135

Votre besoin de supprimer la redirection dans votre configuration IIS, ou si vous envisagez d'utiliser SSL, ajoutez https://example.com et non HTTP.

1
Simon Hayter

Pourquoi passer à https alors que l’URL est http: //?

Je viens de lire des articles sur la façon dont chrome version 44 ajoute un HTTPS: 1 aux en-têtes envoyés au serveur, les incitant à penser que le client souhaite une page sécurisée.

Voir n'importe lequel de ces liens:

https://spunmonkey.design/chrome-beta-44-causing-problems-with-httpsssl/

https://ma.ttias.be/chrome-44-sending-https-header-by-mistake-breaking-web-applications-everywhere/

Une autre raison pourrait être la configuration de votre serveur. Soit vous avez un module spécial rare installé pour votre serveur qui redirige certaines URL ou vous avez une configuration spéciale configurée dans vos fichiers de configuration qui dirige la redirection de certaines URL.

Sans savoir quel logiciel votre serveur doit traiter pour les pages Web (Apache, nginx), je vous conseillerais de passer en revue tous les modules exécutés avec votre logiciel de serveur et de décharger et de supprimer ceux dont vous n'avez pas besoin, et si vous rencontrez toujours des problèmes, même après. En utilisant un autre navigateur Web, essayez ensuite de désactiver vos fichiers de configuration un par un jusqu'à ce que le problème disparaisse. Par exemple, si vous utilisez Apache, essayez de renommer tous les fichiers .htaccess en un nom non reconnu par Apache, tel que htaccessbackup.

0
Mike