Special and Accented Characters in URLs: Encoding, IDNs, and SEO

You can use accented letters, non-Latin scripts and most special characters in a URL and Google will crawl and index it. The catch is that the URL on the wire is not the URL on your screen: anything outside plain ASCII is converted into a percent-encoded or punycode form, and sloppy handling of that conversion is what produces duplicate pages, broken redirects and messy reports. The decision is rarely whether the characters are allowed. It is whether your stack produces exactly one spelling of each URL, every time.

This guide covers how the encoding works, what to put in slugs versus domains, how the encoded forms appear in search results and analytics, and the specific mistakes that split one page into several. The focus is character sets, not general URL hygiene such as length, parameters or trailing slashes.

What a URL Is Actually Allowed to Contain

The URL standard that browsers and crawlers follow was built around a small ASCII repertoire: letters, digits, and a handful of punctuation marks such as hyphen, period, underscore and tilde, plus reserved characters that carry structural meaning. Those reserved characters include the slash, question mark, hash, ampersand, equals sign, colon and at sign. Everything else is either not permitted raw or has to be represented indirectly.

That indirection is percent-encoding. Each byte of the character is written as a percent sign followed by two hexadecimal digits. A space becomes %20. The letter é, which takes two bytes in UTF-8, becomes %C3%A9. The Japanese word 日本語 becomes %E6%97%A5%E6%9C%AC%E8%AA%9E, nine bytes for three characters. This is why a slug that looks short to a human can be long in the address bar if you copy it out.

Two distinctions matter for SEO. First, encoding a reserved character changes its meaning. A slash inside a path is a separator, while %2F is a literal slash character inside a single segment, and servers may treat the two differently. Second, encoding an unreserved character such as a plain letter does not change meaning in theory, but in practice many systems compare URLs as strings, so %61 and a can be treated as different addresses even though they should be equivalent.

Modern browsers hide most of this. You type or see café in the address bar, and the browser sends caf%C3%A9 in the request line. Crawlers do the same, which means the canonical, indexable form of your URL is the encoded one, whatever the page looks like to a person.

Accents in Slugs: Keep Them or Transliterate?

For a site written in Spanish, French, German, Portuguese or Polish, the practical choice is between a slug that keeps the accent, such as /guia-de-envio-rapido versus /guía-de-envío-rápido, and one that strips it to plain ASCII. Both are valid and search engines can handle both. The difference is in the side effects.

A transliterated slug is predictable. It survives being pasted into chat apps, spreadsheets, email clients and older plugins that do not recognise percent-encoding, and it is easy to type from memory. Most large sites in accent-heavy languages use it for exactly that reason. The cost is that it occasionally changes the word: in Spanish, año and ano are different words, and a slug that drops the tilde can read awkwardly or comically. German has a convention, ä to ae and ß to ss, which keeps the word recognisable.

A slug with real accents matches what readers actually type and read, and it looks correct in the address bar and in the search result. The cost is operational. Every tool in the chain, from the CMS to the log parser to the redirect map, has to treat the encoded form consistently. If you keep a hundred accented URLs alive on a platform that occasionally emits lowercase hex or a decomposed accent, you will eventually meet a duplicate.

A sound rule of thumb: pick one policy for the whole site, write it down, and apply it at the point where slugs are created, not afterwards. Changing an existing policy means changing live URLs, which means redirects for every page. If you are launching, transliteration is the lower-risk default for Latin scripts. If your language has no sensible ASCII equivalent, use the native script in full and accept the operational care it demands.

Never mix the two within one site for the same page. A page that is reachable as both /envio and /envío is two URLs competing for the same query unless one redirects to the other.

• Decide the slug policy once: keep accents, or transliterate with a fixed mapping table.
• Generate the slug in code from the title, never by hand, so two editors cannot produce two spellings.
• Keep the mapping for ß, ñ, ø, æ and similar letters explicit rather than relying on whatever a library does by default.
• Lowercase everything, because paths are case-sensitive on most servers.

Non-Latin Scripts in Slugs

Arabic, Cyrillic, Chinese, Japanese, Korean, Hindi and Thai pages can use native-script slugs, and Google documents that non-ASCII characters in URLs should be percent-encoded as UTF-8. Whether you should depends on audience behaviour more than on any ranking effect. There is no documented ranking boost for native-script URLs, and none for romanised ones. The URL is a weak relevance signal in either case, and the page title and content do the real work.

Native-script slugs help users who read the address or see it displayed in a result, because the path is legible to them. They hurt when links are shared through tools that show the raw encoded string: a Russian headline turned into a two-hundred-character run of percent signs looks suspicious in an email and is hard to verify. Some teams therefore keep the visible page in the native script but use a short ASCII ID in the slug, such as /articles/4821-envio-rapido, where only the number is used for the lookup and the readable suffix is decoration.

That ID-plus-suffix pattern has a second advantage: the lookup depends on the number, so a typo or a changed title does not produce a 404. Just make sure the server redirects to the one canonical suffix, otherwise every variant becomes a separate indexable URL.

Whatever you choose, keep the language of the slug aligned with the language of the page. An English slug on a Japanese page is not penalised, but it makes reports harder for the team reading them and confuses the expectations of anyone who sees the URL in a result.

Internationalized Domain Names and Punycode

Domain names follow a different mechanism. The DNS itself only carries ASCII labels, so an internationalized domain name, or IDN, is stored in a form called punycode. The label münchen becomes xn--mnchen-3ya, so münchen.de is resolved as xn--mnchen-3ya.de. The xn-- prefix marks the label as encoded. Browsers convert it back for display, subject to their own anti-spoofing rules: if a label mixes scripts in a way that could imitate another domain, the browser may show the punycode form instead of the native one.

For SEO, the practical points are these. The two forms are the same domain, and search engines treat them as such, but you should still pick one for canonical tags, sitemaps, hreflang annotations and internal links, and use it consistently. Google Search Console property entries and some third-party tools display one form or the other, so do not be alarmed when the same site appears under both names in different reports.

The harder questions are commercial and technical rather than algorithmic. IDN domains are harder to type on a keyboard that lacks the relevant characters, harder to read aloud, and sometimes mangled by email systems or social platforms that do not handle the encoded form. For a market where the native script is the everyday way of writing, those costs may be worth paying. For a brand that will be shared across borders, an ASCII domain with native-script pages underneath is usually simpler.

TLD choice is a separate axis. Country-code and generic TLDs work for geotargeting as they always have, and an IDN does not change how hreflang or country signals behave. Do not expect an IDN to substitute for proper language and region targeting.

How Encoded URLs Appear in Search Results and Analytics

In search results, Google generally displays the decoded, human-readable form of the URL where it can, so an accented slug usually looks normal under the title. Breadcrumb-style display replaces the path with site structure anyway, which further reduces the visibility of the slug. The link itself still points at the encoded address.

Reports are where the difference surfaces. Server logs record the request line exactly as received, so you will see caf%C3%A9 rather than café, and a parser that decodes some lines but not others will split one page into two rows. Analytics platforms record the page path as the browser supplied it, and depending on the tool and the collection method you may see the encoded form, the decoded form, or both for the same page. A mixed report is a signal that either two URL spellings really exist or that your reporting layer is normalising inconsistently.

Test this before drawing conclusions. Take one accented URL, request it in the browser, in a command-line fetch and through a crawler, and compare what each one logs. If the tools disagree with each other but the server only ever receives one spelling, the problem is presentation. If the server receives two, you have a real duplicate to fix.

Filters and segments are a common casualty. A rule that matches pages containing the word envío will miss rows stored as env%C3%ADo. When you build a report filter on accented text, test it against the encoded form, or use an ID-based slug to avoid the question entirely.

How Duplicate URLs Are Born, and How to Prevent Them

Most duplication from character sets comes from a short list of causes. The same page is reachable under several valid spellings, and nothing tells crawlers which one is preferred.

• Hex case. %c3%a9 and %C3%A9 are equivalent under the standard, but a server or cache that compares strings may treat them as different. Always generate uppercase hex.
• Unicode normalisation. An é can be stored as one character or as a plain e followed by a combining accent. They look identical but encode to different bytes. Normalise slugs to one form, usually NFC, at creation time, and watch for text pasted from documents and Mac file names, which can arrive decomposed.
• Over-encoding. A generator that also encodes safe characters, or encodes a slash that should remain a separator, produces a second spelling of the same path.
• Encoded and decoded links side by side. Editors paste the accented form, a plugin emits the percent form, and a third-party site links to whichever it saw. All of them may resolve to one page with no redirect.
• Plus versus %20 in queries. In a query string, a plus sign commonly represents a space, while in a path it is a literal plus. Inconsistent handling creates parameter duplicates.
• Case and accent folding on the server. Some servers are lenient and serve the page for /Envio, /envio and /envío, all with a 200 status.

A Checklist for One Canonical Spelling

The fix is a chain of small controls rather than one setting. Start at the source: generate slugs in one place, normalise to NFC, lowercase them and encode with uppercase hex. Then enforce it at the edge: when a request arrives with a different spelling of a URL you already serve, answer with a 301 to the canonical form rather than serving the page twice. A rel=canonical tag is a backup for the cases a redirect cannot reach, not a substitute for it, and it should itself contain the properly encoded address.

Next, align everything that names the URL. The sitemap should list only the canonical spelling, internal links should point to it, and hreflang annotations should use it on both sides of each pair. If you are migrating from accented to transliterated slugs, or the reverse, treat it like any URL change: map every old address to its new one with a one-hop 301, including the encoded variants that have accumulated in logs, and keep the redirects in place long enough for crawlers and linking sites to catch up.

Finally, audit. Crawl the site and look for URLs that differ only after decoding or normalisation; export the list of URLs from your logs and group them by decoded, NFC-normalised, lowercase form. Any group with more than one member is a duplicate waiting to be consolidated. Search Console's page indexing report can also show alternates and duplicates, and cases where Google has chosen a different canonical than you declared are worth inspecting for exactly this kind of spelling split.

• Pick one slug policy and encode it in the code that creates slugs.
• Normalise to NFC, lowercase, uppercase percent-hex.
• 301 every alternate spelling to the canonical one.
• Use the same spelling in canonicals, sitemaps, hreflang and internal links.
• Re-crawl after a change and group URLs by their normalised form.

Other Special Characters Worth Avoiding

Accents are the visible case, but ordinary punctuation causes as many problems. Spaces should never appear in a slug; use hyphens, which Google documents as the preferred word separator, rather than underscores, which can be read as joining words. Avoid commas, parentheses, quotation marks, the ampersand and the percent sign itself in paths. Each one is either reserved, awkward to encode or likely to be mangled by an editor or chat app.

Emoji technically work in URLs, since they are just more Unicode that gets percent-encoded, but they offer little and break easily in tools that assume simple text. The same goes for symbols like the trademark sign or currency marks in slugs. They add encoding complexity without adding meaning.

One character deserves special mention: the hash. Everything after it is a fragment, processed by the browser and not sent to the server, so two URLs that differ only after the hash are the same page for crawling purposes. Do not put content-bearing words after it and expect them to be indexed as separate pages.