Google Search Console on 13 October 2026: HTTPS robots.txt status: “Non récupéré – Erreur serveur (5xx)” at 17:09 (time displayed in GSC; timezone unconfirmed). Live URL tests for the homepage and /drawing/wave-rider-18/ failed with “Impossible d’atteindre Robots.txt” and “problème affectant tout le site”. Requesting a robots.txt recrawl also failed with “Impossible d’atteindre Robots.txt”.
Other Information
Hello, could you help diagnose why Google cannot reliably fetch this static HTTPS robots.txt? The site opens in a normal browser.
The hosting account is active with an empty suspension history. No IP blocks or protected directories are configured. The dashboard reports the current Let’s Encrypt certificate as active and installed, expiring 29 December 2026. The HTTP robots.txt was successfully fetched by Google on 29 September (124 bytes), but the current HTTPS fetch fails.
GSC crawl-statistics export shows robots.txt fetch failures of 75% on 21 September, 13.33% on 22 September, 2.94% on 23 September and 100% on 28 September. Indexed pages dropped sharply on 22 September; this is a temporal association, not proof of a single cause.
No raw access/error log viewer is visible in the free hosting control panel. Could an administrator check the HTTPS response for verified Google crawler requests to /robots.txt and any corresponding server 5xx, TLS or routing failures? Please advise how to restore reliable access without disabling security protections. The known WordPress REST/loopback 403 warnings are a separate issue.
GSC screenshots and the historical export are available if needed. Thank you.
Welcome to the InfinityFree community forum! Good to have you here.
Most people answering here are volunteers. They’re often the fastest source of help. Admin (the only staff member) checks in about once a day for issues on our end.
Volunteers can’t see your account or website. Share what you actually see, like error messages and what happens when you try something. That’s more useful than your theory of what’s wrong.
AI tools often get InfinityFree wrong. If a volunteer’s advice differs from what an AI told you, please try the volunteer’s suggestion first.
Solving an issue is a joint effort. Try the suggestions you get and report back what happened.
Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look.
I can’t diagnose this one from here. A person on our staff needs to check the server side for the HTTPS requests to /robots.txt from Google’s crawler, because that’s not something you or I can see from outside.
I found one older topic with a similar symptom: GSC reporting 5xx errors and robots.txt fetch failures on a site that opened fine in a browser. The answer there was that a 5xx is a whole category of errors rather than one specific error, so GSC alone can’t say what failed. It also said a roughly 1-in-10 failure rate isn’t expected behaviour for our hosting. It never found the cause, so I can’t say yours is the same thing.
Here is the topic:
Your timeline and the fact that the HTTP fetch worked on 29 September while HTTPS fails are useful details for whoever looks.
Thank you. Could you clarify whether the security-system block applies only to the live URL Inspection test (Google-InspectionTool), or also to the robots.txt report and the historical robots.txt fetch failures shown in Crawl Stats?
Is any specific change needed on this site to let the main Google crawler reliably fetch HTTPS /robots.txt, or should we leave the file and hosting settings unchanged? We would appreciate an administrator checking the server side if the historical failures concern the main crawler. The goal is a concrete fix, rather than disabling any security protection.
Regarding the failed checks from 21st to the 23rd of September: we were having some issues back then due to DDoS attacks. It’s very likely that this caused some of the Google crawls to fail.
Those issues shouldn’t have happened, but mitigations were implemented after those attacks and they work, so the issues are solved.
No, we can’t. If we had logs, we’d have shared them with you already, because nobody prefers a situation where staff has to get the logs for you. The reason you don’t have access to the logs is because we’re not storing them.
So no, I cannot see what happened exactly with the search console requests.