/gr%C3%B6ssen/ looks different from /grössen/. That alone does not prove that two pages exist. Browsers may display encoded characters in a readable form. Compare the requested URL and the server response rather than their appearance alone.
Follow one accented character through the system
Fictional example: a CMS stores “grössen”, the sitemap outputs the UTF-8-encoded path, and the browser displays the umlaut again. If each route reaches the same page with the same canonical URL, the display difference is not itself a fault.
Copy the request URL from the network panel and compare it with the sitemap and canonical. Check the final destination after any redirects too. This separates a display difference from a genuinely separate path.
Double encoding is a different issue: %C3%B6 can become %25C3%25B6. The server no longer receives the same character value.
Reserved characters can affect a URL’s meaning. %2F represents an encoded slash; decoding it without care may introduce a new path boundary. Investigate those cases in the actual application before applying a global cleanup.
Use a URL library and decide which layer performs encoding. A useful handover includes the original CMS value, the generated URL and the observed server response. “Accented characters are broken” does not identify the failing step.
Related check: Check a canonical redirect destination.
If an identified frontend function causes the encoding fault, Frontend optimisation may be a suitable implementation route.