3

Both my website's domain name (https://example.com) and its IP address (https://123.456.789.012/) show up in Google search results. I use Let's Encrypt, who don't allow SSL certificates for bare IP addresses, so I can't get a certificate for the latter. If I understand correctly, this means that I can't set up a redirect to the correct domain name.

How can I handle this situation?

5
  • You dont have to worry about your IP address. IT is handled automatically by their browser by interrogating the DNSs. Dec 21, 2022 at 11:29
  • @RohitGupta I mean that when I google some keywords, https://123.456.789.012/ (example) shows up as a google search results. If someone clicks the result, they're given a simple "invalid certificate" error, since my SSL certificate is only valid for example.com, not for the bare IP address.
    – Anna
    Dec 21, 2022 at 11:34
  • Is this a new site ? Perhaps the update has not percolated through the DNSs Dec 21, 2022 at 11:36
  • @RohitGupta The website is two years old, and DNS records have not changed since then.
    – Anna
    Dec 21, 2022 at 11:37

3 Answers 3

2

Background

IP addresses rank from time to time in Google.

This is normally a mixture of a) a miss-configured server that exposes the IP address to Google in the first place and b) a miss-configured website that does not redirect the user and bot back to the correct version.

For Google, the IP is a new host and the bot is eager to crawl all that new content. I have even seen it happen to large websites.

Redirect & https

If I understand correctly, this means that I can't set up a redirect to the correct domain name.

I am not sure what you mean. You can redirect from http://123.456.789.012/page.html to https://www.example.com/page.html

Both cross-domain redirects and http-to-https redirects are very normal things.

What makes you think you cannot set-up a redirect without https on the origin host?

How can I handle this situation?

There are a couple of things you should do to end this situation and prevent it from ever happening again.

Here is what you do:

Measure 1: use absolute links instead of relative links.

Never link to /page1.html (relative) but rather always link to https://www.example.com/page1.html (absolute).

This way, if the bot ever reaches a page like http://123.456.789.012/page.html all the internal links will point to the correct version. If you use relative links, once Google has found a wrong host, it will crawl your whole site on the wrong host.

In this case, the wrong host is the IP address. It could also be an http version, a non-www version, something caused by your CDN, something caused by a caching system, or something else.

Measure 2: use self-referencing canonical

Add a self-referencing canonical to every page. Make it an absolute link.

This way, whenever the bot crawls http://123.456.789.012/page.htm it sees a canonical pointing to https://www.example.com/page.html

Measure 3: remove links to the IP address

Check the following parts of your website for links to the IP address:

  • All internal links
  • All header links like href-lang, canonical tags, etc.
  • All resource loading like CSS, JS, images, etc.
  • XML sitemaps

If you find one, replace it with the correct link!

Measure 4: implement a host redirect via htaccess & mod_rewrite

On Apache webserver, you can use the htaccess and mod_rewrite to check for the host and redirect if it is the wrong one. On other webservers, there are equivalent solutions.

Basically, you need to check if the current http_host is https://www.example.com and if not, redirect the user/bot to https://www.example.com.

The code should be something like this. It goes into your .htaccess file:

RewriteCond "%{HTTP_HOST}"   "!^www\.example\.com" [NC]
RewriteCond "%{HTTP_HOST}"   "!^$"
RewriteRule "^/?(.*)"        "http://www.example.com/$1" [L,R,NE]

If you set this up properly, you actually do not need any of the other measures mentioned above. But they make sense as fallbacks if this approach ever breaks.

Over time, this will lead to Google no longer crawling and indexing your IP address.

Other measures to deindex the IP address

Investing more time into removing the IP address from the Google Index and/or Cache is a waste of time.

I expect some people will recommend various measures to get the content removed. But you have zero negative effects and can solve the problem by implementing the measures above and waiting. There is no penalty for duplicate content, and you are unlikely to see many humans end up on the IP address - even if they do, the solution above will automatically redirect them.

6
  • Thank you for the answer. Unfortunately,, it's https://123.456.789.012/page.htm that ranks, not the non-https version. Since I can't get a bare-IP certificate from Let's Encrypt to actually serve that page, I can't take any of the measures you suggested. Unless I'm misunderstanding something?
    – Anna
    Dec 22, 2022 at 10:40
  • Why would you not be able to take any of these measures? Also, what does Let's Encrypt have to do with it? Your HTTPS certificate issuer is irrelevant in this scenario. 123.456.789.012 is pointing to the same folder on the same server as example.com and is serving the same HTML pages. Unless there is some proxy/cache/scraping/CDN involved you have not mentioned, you can implement all the things I have mentioned. Dec 22, 2022 at 11:25
  • 1
    My web server cannot answer the request for https://123.456.789.012/page.htm since it does not have a valid SSL certificate for 123.456.789.012. It does answer http://123.456.789.012/page.htm with a proper redirect. There is no proxy/cache/scraping/CDN involved. Am I misunderstanding, is it possible to answer the HTTPS request without a valid SSL certificate?
    – Anna
    Dec 22, 2022 at 11:31
  • 1
    Ahhhh now I get you point. Sorry, I missed that that was the part you had an issue with. What does you browser see when you open https://123.456.789.012/page.htm? And what does Google see? If it is just an error message, even less of an issue. Dec 22, 2022 at 12:01
  • I just see an "invalid certificate" error. How can I see what Google sees? I'm assuming Googlebot actually verifies the certificate. In fact I'm not sure how Google can ever have found content on this URL, since I've never had such a certificate. The non-SSL version http://123.456.789.012/page.htm did serve content a couple months ago though, before I added the redirect.
    – Anna
    Dec 22, 2022 at 13:01
1

To add to "Malte Landwehr," answer it is possible for a request to a https or SSL connection to ask for the description cipher encoding algorithm to be null ... it is the last entry on the table at https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#table1 and is a request to the server to send the page without using a certificate.

Google may have done this as they believed the invalid SSL certificate was temporary? (assumption on my part). Sometimes certificates expire before the webmaster gets it renewed and Google does not want to drop those listings. But that strongly makes Malte's measure 4 a best practice.

Additional information.

Apache "Beginning with version 2.4.7, null and export-grade ciphers are always disabled, as mod_ssl unconditionally adds !aNULL:!eNULL:!EXP to any cipher string at initialization."

1
  • 1
    Interesting hypothesis, thank you. I'll see if I can monitor and log this.
    – Anna
    Dec 22, 2022 at 22:19
-1

I have only rarely seen IP addresses in Search results. I suspect that either you have internal links or some other website(s) are using the IP address.

My suggestion would be to get Google to remove these pages using the removal tool.

Google Remove Outdated Content

  1. But you should ensure that you don't have any internal references (including the sitemap) that refer to plain IP addresses.
  2. You should also look at the backlinks to see if any websites are referring to yours. If so, you can Disavow links to your site

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.