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.
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 forexample.com
, not for the bare IP address.