These URLs are valid only when present in an HTML document, and "some online SEO tools" are sort of incorrect to report this as a problem.
What happens here is that you have used numeric HTML entities to represent various characters, but the URL format does not treat these as encoded characters that should be decoded to get the URL that will actually be used. The only permitted encoding in a URL is percent encoding.
The parser used by this online tool, however, does not take into account that HTML parsing engines are required to decode HTML entities early in document parsing, before the URL is actually used.
The ABNF grammar given in RFC 3986 makes clear that neither &
nor #
are valid at this point in the URL. And, in the most recent revision of the URL specification work in progress, all of the URLs you gave as examples are supposed to return a parse error. This means the URL is not valid generally and should never be given out as a bare link or in any non-HTML context. It only becomes valid after the HTML parser is done with it.
If you use URL percent encoding as, e.g. %2Fuser%2Fsettings
then this will be parsed correctly by everyone, and these URLs are safe to use anywhere. But note that the ?
which delineates the query string is not allowed to be percent encoded. Neither is the scheme (e.g. http
or https
) and the ://
which follow it, allowed to be percent encoded.
So, there's no real SEO impact here.
But, there's also no real reason to do this for everything. For cross-site scripting, for instance, you aren't letting users construct their own URLs. If you were, then you need to do some escaping. And as it's trivially parsed it doesn't really obfuscate anything.
&<>'"
should be enough to stop XSS. No need to encode/
. Good browsers will have no problem with your links. That should include search engine bots. Hopefully Yahoo has fixed their bugs in this area, but they didn't properly recognize my title with an&
in the HTML code.