if this difference of ampersand in URL and sitemap will cause any issue.
tl;dr No issue, because the URLs are the same.
Since in sitemap
& has to be escaped I replaced
Your sitemap is an XML document. As with any XML document, the data values must be stored XML-entity encoded. The
& character is a special character (it itself denotes the start of an XML-entity) and therefore must be encoded to negate its special meaning. This is just the way data is stored inside an XML document.
When the XML document is read by an XML parser the data values are XML-entity decoded, back to the actual value. So,
& when the XML document is read.
So, a URL of the form
/page?foo=1&bar=2 stored inside an XML document is identical to the URL
/page?foo=1&bar=2 in your HTML5 document.
My actual page URLs contain just
In HTML5 that is perfectly OK, providing there is no ambiguity. However, in HTML4.1 (and earlier) you would have needed to correctly HTML-entity encode the
& in your HTML source code for valid HTML. However, browsers are very tolerant and your HTML document would most probably have still "worked".
In HTML5 you only strictly need to HTML-entity encode the
& if there is an ambiguity. Take the following contrived example. We want to pass the literal string "$" in the
foo URL parameter.
<!-- In an HTML document (WRONG) -->
The desired URL is
http://example.com/page?foo=$, however, the above HTML anchor results in sending the user to
http://example.com/page?foo=$ - which is not the intention. To create the desired result, the
& must be HTML-entity encoded to negate its special meaning, resulting in the following (correct) HTML:
<!-- In an HTML document (CORRECT) -->
It is always safer to consistently HTML-entity encode the
& in your HTML-document. If you are generating your content through a CMS, then this should be automatic.
I am able to access the site after replacing
& in the URL.
Presumably you mean "in the URL, in your HTML"? Because if you were to HTML-entity encode the
& in the browsers address bar (for instance), ie. outside of an HTML context, then you will not get the expected results. For example, if you typed the following directly into the browser's address bar:
Then you would get the two URL parameters
[foo] => 1 and
[amp;bar] => 2, which is clearly not the intention.