My first guess would be this is a robot. unless your dealing with "WolframSyndrome/ACloserLookatWS.aspx" on your site?
By "not published", do you mean not visible by the public?

Looks like you created a redirect loop. Can you check the site settings: login and register page settings

We have seen similar entries in the log by scanners / hackers, tyring all kinds of urls, of which some lead to a 500 error

FYI, you see this on every site, this is not a DNN specific thing.
Most scanners seem to look for wordpress vulnerabilities (even on DNN sites), which tells me it's all automated.

I know it doesn't always make sense, but I've always found that bots of all kinds will discover your sites, even if they're on a test/staging domain.  That is, unless you literally use a WAF (or something else) to block it from happening.  

With that being said, this sounds like a bot (automated) is probably causing a redirect loop between the <code>Login</code> and <code>Register</code> endpoints after the 8→9 upgrade—not an intrusion attempt. A bot or crawler is probably hitting <code>/register</code> (or <code>/login</code>) once a minute, and because of a settings mismatch, DNN keeps tacking on another <code>ReturnUrl=</code>… as it bounces between the two, producing that long, recursive query string.

Will has a point. Look at you your "Site Settings>Site Behaviour" Settings, see if any of the pages are redirecting to a login or register page.

Our usual approach to this kind of bot problem is to add a 403 redirect to block known spam robots. We have a automated process to do this, but you can do it manually by using a list of robots and often we add new robots when we find them doing strange things. There is an overhead to this be we find it minimal.

Here is a list of know spammers: https://raw.githubusercon.../master/spammers.txt

I'll check if I have some weird redirect. I didn't create any so, unless it has weird redirects out of the box, then no.
The only thing I did is put a Registration module on the Contact us page, in order to only let authorized registered users see the feedback module and send feedback, to try and cut back on the spam feedback.
Unfortunately it looks like the Registration module doesn't come with captcha or other anti spam features so... I'll probably have to deal with spam registrations.
Those are usually easier to bulk-erase so, I guess it's the best solution.

We always use "Verified Registration" now. This really help with the spam registration.

There is also a form module on RocketCDS: https://github.com/Rocket...S/RocketCDS/releases This has anti spamming built into it, without the use of captcha. But you'll need to add the fields you need with a razor template. There is a contact template as an example. https://github.com/Rocket-CDS/AppThemes-W3-CSS