I want to verify my URL with Google Webmaster tools but it wouldn't let me, I've tried various methods but none seem to work and the reason maybe, that the URL forwards to a different domain. I have a .com URL forwarded to my.ca domain, I can properly verify the .ca domain but it wouldn't let me verify the .com URL. Is there a trick I can use to get around this problem? The easiest verification method, is to download a .html file and upload it to my ftp to make it accessible.

Webmaster Tools says:

Confirm successful upload by visiting http://example.com/GoogleID.html in your browser.

I copied the file into my root on the FTP server and when I try to pull it up in Chrome, it attempts to resolve https://example.com/GoogleID.html instead which returns some privacy error (due to HTTPS).

Why would it switch to HTTPS even though the URL http://www.example.com/GoogleID.html works properly and pulls up the page just fine.

My .htaccess looks like:

# 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

# 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

# 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

# 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

What exactly leads to the problem I'm experiencing and what can I do to fix it? Even commenting it out (i.e. renaming .htaccess to htaccess~) won't resolve the "resolution" issue, i.e. the http:// URL still redirects me to https://

  • Your server header tells me that your server is IIS and not a compatible server that uses .htaccess, so renaming the file will not work as its not being used in the first place. Contact your hosting company. Nov 30, 2015 at 7:50
  • When you request http://example.com/<something> (note: without the www subdomain and with a non-empty URL-path) then the server is responding with a 302 redirect to HTTPS://EXAMPLE.COM/<SOMETHING> (Yes, all uppercase!) and all browsers are redirected resulting in the SSL warning. If you use the www subdomain (as in your working example) it works OK, but that doesn't appear to be the URL specified in GWT. In fact, the www and bare domains appear to point to two different servers? www is Apache/2.4.12, PHP/5.4.43, Drupal 7. Whereas the bare domain is Microsoft-IIS/7.5, ASP.NET!?
    – MrWhite
    Nov 30, 2015 at 10:43

2 Answers 2


This is happening because your site is SSL ONLY, due to the fact that your website is redirecting all requests via a 302 from HTTP to HTTPS. Currently Google is requesting http://example.com/file.html but your server redirects that request to https://www.example.com/file.html and obviously fails as a result. So, in other words your issue is not with Google, its an issue with your host being incorrectly configured.

If you want to verify and add the http:// then Google will need access to the site without being forced to the https://. Remove your redirect and the problem will be resolved.

This issue is easy to detect using 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

Your need to remove the redirect in your IIS configuration, or if you plan to use SSL then you add https://example.com and not HTTP.

  • I'm hosting with GoDaddy
    – stdcerr
    Dec 2, 2015 at 3:58

Why would it switch to https even tho the URL is http://?

I just recently read articles about how chrome version 44 adds an HTTPS: 1 to the headers sent to the server, tricking them into thinking the client wants a secure page.

See any of these links:



Another reason could be your server configuration. Either you have a rare special module installed for your server that redirects certain URLs or you have a special configuration set up in your configuration files that direct certain URLs to be redirected.

Without knowing what software your server has to process web pages (apache,nginx), what I would suggest is to review all modules running with your server software and unload and remove those you don't need, and if you still have issues even after using a different web browser, then try to deactivate your configuration files one by one until the problem goes away. For example, if you use apache, try renaming all .htaccess files to a name that apache won't recognize such as htaccessbackup.

  • I read that somewhere in RewriteCond %{HTTPS} on, the value will always be true from chrome 44 because of its HTTPS bug. There may be an environment variable that equals the complete URL being requested and you could do a scan for https:// instead. Nov 30, 2015 at 5:52
  • @Mike The bug you mentioned above did not affect the HTTPS Apache server variable (which is not dependent on the HTTP request headers). An HTTPS: 1 request header would have resulted in the PHP superglobal $_SERVER['HTTP_HTTPS'] being set and it was buggy PHP code that checked for this that broke. The Chrome bug alone did not magically force servers to HTTPS. Incidentally, that bug in Chrome was fixed in later versions of Chrome 44 (about 4 months ago).
    – MrWhite
    Nov 30, 2015 at 11:26
  • I'm hosting with GaDaddy
    – stdcerr
    Dec 2, 2015 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.