Internal links contain non-ASCII characters that aren't percent-encoded
unencoded_url_linksShort answer
Some href values contain characters like é, ş or ü directly instead of %C3%A9, %C5%9F, %C3%BC. Browsers encode them on the fly and Google copes, but Google's guidance is to percent-encode non-ASCII characters in links. Fix it when you touch the templates; it is informational.
Why it matters
Different clients encode differently, which can produce two URL spellings for the same page and the occasional broken link in tools that do not normalise. Google recommends UTF-8 percent-encoding for non-ASCII characters in URLs and link attributes.
How Glimana detects it
The crawler scans href attributes of internal links for raw non-ASCII characters; the evidence shows how many such links the page has.
How to fix it
- Find the affected pages in Glimana. Open Issues › Internal links contain non-ASCII characters that aren't percent-encoded. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Encode link targets when generating them:
encodeURIin JavaScript,rawurlencodeper path segment in PHP,urllib.parse.quotein Python. Most CMSs already do this for slugs; hand-written links in content, spaces and non-ASCII characters in file names, and URLs pasted from a browser's address bar are the usual sources.Search the affected page's content for the raw link (often a media file uploaded with spaces or Turkish characters in its name). Rename the file (Media Library › Edit › file name, or the Media File Renamer plugin) or re-insert the link so WordPress encodes it. For links built in theme code use
esc_url().Links written in product descriptions or blog posts with spaces or special characters; edit the rich text and use the link dialog rather than pasting raw HTML. Use
| url_encodefor values inserted into URLs in Liquid.Build URLs with the framework's URL helper (
route(),url_for,reverse) instead of string concatenation, and percent-encode user-supplied segments. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the page's links are all valid, encoded URLs. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the page's links are all valid, encoded URLs.