Search Console showed me 1,387 URLs under “Blocked due to access forbidden (403)” on a community radio station website I run, and nearly all of them looked like this: /wp-login.php?redirect_to=.... If you’ve got the same thing, here’s what was going on, what I changed and – the bit nobody tells you – why the number didn’t drop afterwards!
What the 403 means here
A 403 is the server saying “I know what you’re asking for, and no”. It isn’t a 404 (page missing) or a 500 (server broke). On my site wp-login.php refuses to show itself to strangers, which is exactly what I want from a login page. I checked on 15 October 2026 by fetching a login URL with a redirect_to parameter twice, once pretending to be Googlebot and once as an ordinary Firefox browser. Both got a 403. Fine for security, but it means that every time Googlebot follows a link to the login page, Search Console files it under errors.
Why Googlebot was there at all
Honestly, I’m not certain. The redirect_to bit is what WordPress adds when it bounces a visitor to the login page and wants to send them back afterwards, so something on the site was linking to login URLs and Googlebot was following them. I haven’t tracked down every link that does it (and with about 32,000 posts, I’m not sure I’ll ever manage it!). I decided to stop caring where the links came from and tell Google not to bother.
The fix: one line in robots.txt
On 1 September 2026 I added this for Googlebot, Bingbot and everyone else (*):
User-agent: Googlebot
Disallow: /wp-login.phpThe rule is the same under each user agent. Disallowing the file path also covers every ?redirect_to= variation, because robots.txt rules match from the start of the URL. If you already have a block for a particular crawler, remember that a crawler with its own named group ignores the * group, so the line has to go in each one (that’s why I repeated it).
What happened to the number
Nothing! On 1 October it was 1,387 and it had been 1,387 since early September. When I opened the examples in Search Console, the last-crawled dates were all between 1 and 12 September. So these were not new errors, just old ones that Google hasn’t got round to re-checking, and since robots.txt now says “don’t crawl this”, it’s unlikely to re-fetch them to find out they’ve gone.
That’s the useful lesson. A robots.txt block stops new crawling, but it doesn’t make Search Console forget what it already found. Expect the stale ones to sit there for a good while. Don’t keep fiddling with the file because the count hasn’t moved (I nearly did).
Should you do this?
Only if the URLs in your report really are login URLs. Open 20 of them first, same as I did with my other indexing problems. If any are real pages you want indexed, a robots.txt block is the wrong answer and the 403 is a bug you need to fix. Also remember a login page shouldn’t be in Google at all, so blocking it costs you nothing.
My next look is 1 November, when I’ll see whether the 1,387 has started to fall. I’ll add the result here.