603-924-9867A usual part of solving issues as they arise in the website development business is searching Google for solutions. Very seldom have I ever been the first or only individual to find a particular problem needing a solution. I don’t believe the situation I’ll describe here is a unique one. However, I was surprised that it wasn’t specifically described or answered anywhere.
The Infamous robots.txt File
There is a file called robots.txt that can be installed in the root of a website’s directory. It assists with providing information that can be useful to a website’s SEO (Search Engine Optimization).
There is a lot of debate on the web as to whether it is worth putting a robots.txt file in a site anymore. Many say it is no longer used and many say it is. The robots.txt file is a tiny text file. Text files not containing any commands are perfectly safe. My viewpoint is that if it is useful to even one search engine – and can’t hurt anything – I am in favor of installing it. I have done some testing that seems to show it helps a site to be found. On top of that, website access logs show me that the robots.txt files in sites are in fact being accessed.
I have been routinely installing robots.txt files in sites we develop here at CharlesWorks. All of the parameters that are available for use in a robots.txt file are beyond the scope of this article. You can search the web for more detailed information on robots.txt files. This one (that I usually use) is an example of a robots.txt file that allows any web crawler to look at an entire website:
User-agent: * Allow: /
As you can see it’s pretty simple.
The Ever Important Sitemap File
I was in the process of installing a sitemap statement in a robots.txt file. For some time now, WordPress websites automatically generate sitemap file named wp-sitemap.xml that can be viewed even in a browser. My entire robots.txt file for my https://TellYourStory.ws site with the sitemap statement in it looks like this:
User-agent: * Allow: / Sitemap: https://tellyourstory.ws/wp-sitemap.xml
As good programming practice would dictate, I tested the URL https://tellyourstory.ws/wp-sitemap.xml which should show me the WordPress generated sitemap. But it didn’t. Instead I was presented with the ERR_TOO_MANY_REDIRECTS redirections error.
ERR_TOO_MANY_REDIRECTS Redirections Error
Navigating to https://tellyourstory.ws/wp-sitemap.xml using Google’s Chrome browser presented me with this:
Now off to Google to troubleshoot what could be causing this ERR_TOO_MANY_REDIRECTS redirections error. I had encountered this error in the past and had a difficult time troubleshooting it.
Most suggested fixes involved clearing your computer’s cache and clearing your cookies. A quick way to do this with the required commands is on another post of mine here:
https://charlesworks.com/how-to-refresh-your-web-browser-page/
Refreshing the browser page did not affect it whatsoever. I wondered what was actually happening when these purported redirections were happening. I needed to see what sequence of events was happening when the https://tellyourstory.ws/wp-sitemap.xml was being applied to the web server. And I really didn’t want to have to dig into the web server itself for the Apache logs to search for that.
Check Your Redirects and Statuscode website
During the Google search for the redirection errors I quite accidentally stumbled across a website that allowed me to see exactly that. I found the https://www.redirect-checker.org/ website. The Redirect Checker site was very easy to use. Here, I was able to type in the the URL https://tellyourstory.ws/wp-sitemap.xml and see exactly what was happening. Here is a screen shot of their web site and the output that was generated after typing in my URL and clicking on their analyse button:
The issue was so embarrassingly silly. As many are once a solution is found. Under the Result (middle of the screen shot above) it states:
CONGRATULATION. Everything seems to be fine. https://tellyourstory.ws/wp-sitemap.xml 301 Moved Permanently https://TellYourStory.ws/wp-sitemap.xml 200 OK
Seeing that readout from https://www.redirect-checker.org/ reminded me of something I did thinking I was being fancy and cool. I couldn’t believe I had been bitten by an upper and lower case issue! Many times I have warned my team about the issues that upper and lower case can cause. I had typed the domain in that way – using upper and lower case characters – in the site’s General Settings addresses:
As a result of thinking I was being fancy, I set up WordPress to perform internal redirects causing the error!
Fixing the ERR_TOO_MANY_REDIRECTS Redirections Error
This fix was as simple as navigating to the site’s Dashboard > Settings and in the WordPress Address (URL) and Site Address (URL) replacing https://TellYourStory.ws with https://tellyourstory.ws and clicking the Save Changes button at the bottom of the page. Note that case does not matter when a domain name is typed into a web browser address bar – it is automatically converted by the browser to all lower case. But case DOES matter to any site page references AFTER the / (slash) character following the domain name.
When I did this, it made me log back in, as it should have because on Linux web servers, upper and lower case names are treated as unique. If your WordPress install is operating on a Windows based server, this issue most likely would not arise since Windows servers do not treat case as unique.
