!, *, @, &, or # creates crawl waste, duplicate-content variants, and broken sharing. Stick to lowercase letters, numbers, and hyphens, and let your CMS handle the rest.What counts as a special character in a URL
A URL is technically a restricted text format, not free text. Per RFC 3986, the specification that governs URI syntax, only a small set of characters are "unreserved" and safe to use anywhere without encoding: uppercase and lowercase letters, digits, hyphens, periods, underscores, and tildes. Everything else falls into one of two other buckets: "reserved" characters that have structural meaning in a URL (things like /, ?, #, &, =, :, @, ;, and ,, which separate paths, queries, and fragments) or characters that are simply not allowed raw and must be percent-encoded, including spaces, quotes, brackets, carets, backticks, and any non-ASCII character such as accented letters, Cyrillic, Arabic, or CJK text.
When someone says a URL "has special characters," they usually mean one of three situations: a raw space (often visible as %20 once encoded, or literally left as a space in a sloppy export), a reserved character used outside its structural role (like an unencoded & inside a path segment instead of a query string), or raw non-ASCII text that the CMS didn't transliterate or encode. All three are fixable, and all three cause real, measurable problems once a site has enough pages for the pattern to compound.
Why this actually hurts SEO
The damage is not abstract. It shows up in several specific ways:
Crawl inefficiency. Every character in a URL that has to be percent-encoded turns a short readable slug into a long escaped string. Crawlers still have to fetch, parse, and log those URLs, and if your site generates multiple encoded variants of what is functionally the same page (say, a filter or search results page with special characters in a query parameter), you are spending crawl budget on near-duplicates instead of your actual content.
Duplicate content from encoded and unencoded variants. A browser might normalize café-guide and caf%C3%A9-guide to look the same to a user, but a crawler treats them as two distinct strings unless your server explicitly redirects one to the other. If internal links, sitemaps, and third-party links point to different encodings of the same URL, you have split signals across multiple URLs that should be one page.
Broken sharing and copy-paste. Special characters, especially raw spaces or quotes, break when pasted into Slack, email, or a text field that doesn't auto-encode. A URL that gets mangled the moment someone tries to share it is a URL that loses links, social shares, and referral traffic you'll never see in your analytics because the click never happened.
Tracking and analytics breakage. Unencoded ampersands or equals signs inside a path (not a query string) can confuse query-string parsers, causing your analytics or attribution tooling to misread a page as a set of parameters rather than a single URL. That fragments your reporting and makes deduplication in GA4 or Search Console harder than it should be.
Canonicalization confusion. If your canonical tag points to an encoded version of a URL but internal links point to the unencoded (or differently encoded) version, you are asking Google to reconcile signals that should have been consistent from the start. Canonicalization already has enough edge cases; special characters just add more surface area for it to go wrong.
Poor readability and click-through rate. A URL like /shop/men's-jackets?size=L&color=navy renders as a wall of percent-codes in a browser address bar or in search results when Google chooses to display the URL instead of breadcrumbs. Users trust clean URLs more, and a string of %27 and %26 reads as broken even when it technically resolves fine.
How to detect it
You don't need to eyeball every URL on the site. A handful of tools will surface the problem quickly:
- Screaming Frog: crawl the site and check the URL column for percent-encoded sequences, spaces, or non-ASCII characters. Screaming Frog also flags "Non-ASCII Characters in URL" and "Underscores in URL" under its URL issues reporting, which is exactly the signal you want.
- Sitebulb: its URL audit hints surface similar issues with visual grouping, which is useful if you're trying to show a client or stakeholder a pattern rather than a raw list.
- Google Search Console: the Page Indexing report and URL Inspection tool will show you exactly how Google fetched and canonicalized a URL. If you see indexed variants that differ only by encoding, that's your special-character duplication showing up in the index.
- Server log analysis: pull raw access logs and grep for
%20,%27,%22, or other encoded sequences in the request path. This tells you what crawlers are actually requesting, which sometimes differs from what your sitemap or internal links claim exists. - Manual spot checks: open your XML sitemap and search for
%characters directly. A sitemap full of percent-encoded paths is a strong hint that slugs are being generated from raw titles instead of a cleaned slug field.
Reference: common characters and what happens
| Character | RFC 3986 class | What happens if used raw |
|---|---|---|
| Space | Not allowed | Browsers auto-encode to %20 or +; links break if copied before encoding |
Apostrophe ' | Sub-delimiter (reserved) | Often breaks when embedded in HTML attributes or JS-built links |
Ampersand & | Sub-delimiter (reserved) | Fine in a query string as a parameter separator, breaks parsing if used in a path segment |
Question mark ? | General delimiter (reserved) | Starts the query string; anything after it is treated as parameters, not path |
Hash # | General delimiter (reserved) | Starts a fragment; everything after it is typically never sent to the server or crawled as a separate URL |
At sign @ | General delimiter (reserved) | Used for userinfo in the authority component; confuses parsers if left in a path |
Percent % | Escape character | Must itself be encoded as %25 when used literally, or the whole URL misparses |
| Accented or non-Latin letters | Not ASCII | Must be UTF-8 percent-encoded; raw bytes in a URL are undefined behavior across servers and clients |
Hyphen - | Unreserved | Safe everywhere, Google's preferred word separator in slugs |
How to fix it, step by step
- Audit first. Run a full Screaming Frog or Sitebulb crawl and export every URL containing a percent-encoded sequence, a raw space, or non-ASCII bytes. Cross-reference against your XML sitemap and Search Console's indexed URL list so you know the full scope before touching anything.
- Fix the source, not just the symptom. If your CMS is generating slugs directly from page titles without sanitization, that's the root cause. Configure the slug generator to lowercase everything, strip or transliterate accented characters, replace spaces and underscores with hyphens, and drop any character outside the unreserved set.
- Redirect old URLs to the cleaned versions. Once you rename a slug, put a 301 redirect from every old encoded or messy variant to the new clean URL. Do this before you change internal links, not after, so there's no window where the URL exists in two forms with no redirect.
- Update all internal links and the sitemap. Search and replace internal links pointing to the old URLs, and regenerate your XML sitemap so it only lists the clean, canonical form. Leaving old links in place forces an unnecessary redirect hop on every crawl and every click.
- Set canonical tags to match. Make sure the canonical tag on each page points to the exact clean URL you want indexed, not an encoded variant. This is your backstop if any encoded version still gets discovered somewhere.
- Handle query parameters separately. If special characters are coming from filter or search parameters rather than the path, decide whether those parameter combinations should be indexable at all. If not, use canonical tags pointing to the clean base URL, or block low-value parameter combinations in Search Console's URL parameter handling where appropriate.
- Re-crawl to confirm. After deploying fixes, run Screaming Frog again and confirm zero URLs contain raw spaces, non-ASCII bytes, or unnecessary percent-encoding. Check server logs a week later to confirm crawlers have picked up the redirects and aren't still hitting old encoded paths repeatedly.
None of this is glamorous work, and cleaning up years of accumulated messy slugs on a large site can be a genuinely tedious slog. But it's a one-time fix with a permanent payoff: once your slug generation is sanitized at the source, the problem doesn't come back.
What good looks like
A clean URL uses lowercase letters, digits, and hyphens as the only separator, contains no raw spaces, no unencoded reserved characters outside their structural role, and no raw non-ASCII bytes. Query strings, when needed, use standard key-value pairs joined with & and =. Per Google's URL structure documentation, this kind of simple, descriptive, human-readable URL is both easier for users to trust and easier for Google to parse and canonicalize correctly. If you can read a URL out loud without saying "percent" more than zero times, you're in good shape.
- Use lowercase letters, digits, and hyphens only in slugs
- Sanitize slugs at generation time, not after the fact
- 301 redirect every old encoded or messy URL to its clean replacement
- Keep canonical tags, sitemaps, and internal links pointing to one consistent form
- Re-crawl after fixes to confirm zero remaining special-character URLs
- Let raw titles with spaces and punctuation flow straight into slugs
- Mix encoded and unencoded versions of the same URL across your site
- Use reserved characters like
&or@inside a path segment - Leave non-ASCII characters unencoded and hope browsers sort it out
- Skip redirects when renaming a slug to a cleaner version
FAQ
Does Google actually penalize URLs with special characters?
Are underscores considered special characters here?
What about non-English characters in URLs, like accented letters?
Can I just leave old encoded URLs alone if they're already indexed?
Is a query string parameter like ? and & a problem?
Our Advanced SEO Audit covers URL structure, crawl budget waste, duplicate content, and canonicalization issues end to end, with a prioritized fix list your dev team can actually act on.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
