Your "SEO expert" might be a lying bastard, but this probably isn't the reason. He's absolutely right about this. This is a little known edge case in URL construction.

[RFC 3986][1] is the official definition of the URL format and rules on how to encode and decode URL. Any URL parser should be following this as closely as possible to avoid errors and be interoperable with the rest of the Internet. That includes search engines which, if they apply the rules incorrectly, won't actually be able to crawl or index certain resources at all (e.g. they will get a 404 because they screwed up your URL, or your application will misinterpret the URL or query string).

The RFC gives rules on _how_ to do the percent encoding and decoding, which we're all familiar with, but it also explains _when_ to do the encoding and decoding, and _to which characters_.

Note that search engines _normalize_ URLs (so that they can be compared) but they do not _dereference_ them. Web servers dereference URLs to locate documents and to pass decoded data to your web application. When a URL is normalized, only a subset of percent encoded characters are decoded; when it is dereferenced, _all_ of them are decoded.

In particular it specifies how to compare two URLs for equivalence (all of section 6) and which characters must be percent decoded before doing so (section 6.2.1 and 6.2.2). Here we find out that the _only_ characters to be decoded before comparing URLs for equivalence are the so-called unreserved characters. These are defined (in section 2.3) as "uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde." Percent encoding is meant to _prevent_ browsers, search engines, and the like from misinterpreting special characters in URLs, but since none of the unreserved characters have special meanings in a URL, these can be decoded by anyone at any time.

**So, the `%3A` is _not_ decoded to a colon `:` before two URLs are compared for equivalence.** The colon actually has some unusual rules that apply to its use in the path component of a URL (explained in section 4.2); it cannot appear in the _first_ path component of a _relative_ URL (but is allowed in subsequent components) because it could be confused for a URL scheme.

To construct valid relative URLs with a colon as the first path component, we would either have to encode it some of the time and not others, prefix all such relative URLs with `./`, or forgo relative URLs entirely (which is usually what happens, but relative URLs are much more common than you might think).

This part of the URL spec could use some clarification, but given the circumstances I would strongly recommend that if you are going to use colons in your URLs that you **always** encode them. This removes any possible ambiguity with respect to URL equivalence and ensures that you won't hit this edge case even if you use relative URLs.


  [1]: https://www.rfc-editor.org/rfc/rfc3986