Looking at the screenshot, the page you're trying to view is on the authentication domain (auth.wikimedia.org), which is used only for authentication purposes (hence, access is denied as expected).

You should be viewing/creating the target page on the actual nl Wikipedia. I'm curious how clicking on the red link takes you to the auth domain. I couldn't reproduce that part either.

I was on nl.wikipedia.org. :)
I intentionally included the url because I also noticed it got stuck on the auth.wikimedia.org, where I should not even be when not logged in, right?

It just happened to me logged in as well:

• be logged in
• visit nl.wikipedia.org
• use the search field to go to "Help:Helpdesk/Archief/jun_2025#Weer_wat_nieuws"
• again a page with the access forbidden is shown

This time I was logged in, and my browser was FireFox 143.0.4. (new screenshot attached)
I'll add browser information to the one above as well.

Someone tried to use the search bar from the login page and ended up on an article page URL on the auth domain, which doesn't work.

The "You need to be logged in" message is confusing (the page would still not work with that URL if you were logged in) but I don't think there's an easy way to avoid that.

This 'someone' was me, and I was logged out and on a Wikipedia article page when trying to replicate the error, as described in the steps, by clicking on a red link in the article.
The second time (second screenshot) I was logged in, and navigating from a talk page to our Helpdesk by entering the words in the search bar.

(A similarity between both cases that I can see, might have been that both browsers I used (Chrome & FF) were of a slightly older version)

Seems pretty unlikely that you'd end up on auth.wikimedia.org without actually starting a login / signup, regardless of browser. Maybe if you actually tried to save an edit at the red link, as that results in temp user creation which does involve interacting with the authentication domain, but for just reading, I don't see how it could happen. All data stored in the browser is split by domain, so going to the auth page, using the search box and getting something cached can't cause that either.

Maybe you followed some link to the login page (a login link in a page protection template, or such)? Or maybe a buggy gadget or browser extension?

.... I agree it is strange, which is why I made the screenshots and filed a ticket....

• The user who reported this behavior to our Helpdesk in June used the Wikipedia search field (FF browser/not logged in).
• When I experienced it yesterday, I was not logged in and clicked on a red link in an article, and I got the same error message. As I said, because I was testing a complaint that we received via VRT (former OTRS), and I was surprised to see the auth. domain in the url, even though I was not logged in (Chorme browser this time) ànd was only clicking a red link.
• The second time I received the error message I was logged in, and used the search field (in FF).

I did not follow a link to the login page at any of the instances, and I did not try to save an edit. I was trying to visit a page.

I can't see how the choice of browser would influence the outcome, but I tried searching in Firefox just in case, in various ways (click, Enter, button) and it all works as expected.

This issue seems improbable both theoretically (I can't really imagine how the auth domain would "leak" into non-authentication workflows) and in terms of impact (if search occasionally redirected to the auth domain, it would have to happen in some very niche circumstances, otherwise it would have been reported already - search is used a lot), and the reproduction steps don't work. I don't think we can do much here, other than fixing T381096: Hide the search form in the skin during login, signup, and other auth-domain workflows (my best guess is still that you and the people reporting it somehow start a login workflow by accident, and then try to use the search bar on the authentication domain; the fact that it is present at all is certainly confusing).