URL Contains Spaces

No Comments
Url contains spaces

Element Code: UR-002

TL;DR: A raw space inside a URL is not a legal URL character. It has to be percent encoded as %20 (or a plus in a query string). When you leave literal spaces in links, some clients break the URL at the space, others encode it inconsistently, and you end up with duplicate or dead URLs that waste crawl budget and split your link equity.
Check ID
UR-002

Severity
Medium

Encodes To
%20

Best Fix
Hyphenate

Detect With
Crawler

What "URL contains spaces" actually means

The URL specification (RFC 3986) defines a fixed set of characters that are allowed to sit unescaped in a URL. The space character is not one of them. So when a page links to something like /our team/about page.html, that space is technically illegal. It has to be represented as its percent encoded form, %20, before the URL is valid. In a query string a space is often encoded as a plus sign instead, which is a separate historical convention from form submissions.

Here is why this bites you in practice. Browsers are forgiving. Type a URL with a space into Chrome and it silently rewrites the space to %20 for you, so the page loads and everything looks fine. But the moment that link travels outside a browser, into an email client, a chat app, a CSV export, a sitemap parser, or another crawler, the tolerance disappears. Many of those tools treat the space as the end of the URL. The link gets truncated at the space and points at a URL that does not exist.

Why this matters for SEO and crawling

The damage is rarely dramatic, it is quietly corrosive. A single canonical concept ends up reachable through two different strings: the encoded %20 version and the literal space version that some parser mangled. Google can and often does crawl both, then has to decide which one is the real page. That is duplicate content you created for no reason, and it dilutes whatever link signals should have concentrated on one clean URL.

Spaces also make a mess of everything downstream. Analytics reports split one page into several rows because the path strings differ. Log file analysis becomes painful because you cannot cleanly group requests. Anchor text in a shared document breaks when the reader clicks a truncated link. And if a space sneaks into a canonical tag, an hreflang value, or a sitemap entry, you can hand a search engine a URL it simply cannot resolve. None of this is catastrophic on its own, but on a large site these small failures stack up into wasted crawl budget and confused indexing.

One link, three destinations

/our team/about page.html SOURCE LINK (has a space)

/our%20team/about%20page.html BROWSER: auto encoded, works

/our (truncated at space) EMAIL / CHAT: broken 404

/our+team/about+page.html SOME PARSERS: plus, duplicate URL

Same page, three URL strings. Search engines may crawl and index more than one.

How to detect spaces in your URLs

You do not need anything exotic to find these. A full crawl is the fastest route.

  • Screaming Frog: crawl the site, then filter the Internal tab or use a custom search for %20 in the Address column. It surfaces both the encoded links and the pages they sit on.
  • Sitebulb: flags non standard URL characters as a hint under its URL and indexability checks, and shows you the linking pages.
  • Google Search Console: the Pages report and URL Inspection will show odd encoded paths getting indexed. If you see %20 versions of pages you did not expect, that is your signal.
  • Server logs: grep your access logs for %20 in requested paths. Real crawler hits on encoded URLs confirm the problem is live, not theoretical.
  • Your sitemap: open the XML and search for spaces or %20. A sitemap should only ever contain clean, canonical, fully encoded URLs.

How to fix it, step by step

  1. Fix the file and slug names at the source. The real fix is not to encode the space, it is to remove it. Rename files and folders and slugs to use hyphens: /our-team/about-page.html. Hyphens are the web standard word separator and Google treats them as spaces between words.
  2. 301 redirect the old encoded URL to the new hyphenated one so any existing links and indexed versions consolidate onto the clean address.
  3. Update every internal link to point straight at the new hyphenated URL. Do not rely on the redirect for internal navigation, fix the source links so crawlers never hit the redirect at all.
  4. Regenerate the sitemap and canonical tags so they emit only the clean URLs.
  5. If you genuinely cannot rename (a legacy system, a locked CMS), then at minimum make sure every link emits the properly encoded %20 form and that one encoding is used everywhere, so you do not spawn duplicates.

Encoding reference

CharacterIn the pathIn a query stringBetter choice
Space%20+ or %20Hyphen -
Underscore_ (legal)_Hyphen -
Ampersand%26separator, encode literal as %26Avoid in slugs
Capital letterslegal, case sensitivelegalLowercase

DO

  • Use hyphens between words in slugs and filenames
  • Keep URLs lowercase and clean of spaces from day one
  • Rename the source, then 301 the old encoded version
  • Put only fully encoded, canonical URLs in sitemaps
  • Recrawl after the fix to confirm no %20 paths remain

DON'T

  • Leave literal spaces in href values and trust the browser to fix them
  • Mix %20 and + encodings for the same page
  • Ship uploaded files with spaces in the filename
  • Let a space slip into a canonical, hreflang, or sitemap URL
  • Assume "it loads for me" means it works everywhere

What good looks like

Every URL on the site is lowercase, hyphen separated, and contains zero spaces in any form, encoded or literal. A crawl returns no %20 paths. Sitemaps, canonicals, and internal links all point at the same clean string for each page. When you paste any URL into an email or a chat, it survives intact and resolves on the first click. That is a small, unglamorous win, and it is exactly the kind of hygiene that stops crawl budget leaking on a big site.

FAQ

Is a space in a URL always a real problem, or just cosmetic?
It is a real problem, even when it looks like it works. Browsers hide it by auto encoding, but the moment the link is handled by a non browser tool the space can truncate the URL or produce a duplicate encoded version. Both outcomes hurt you.
Should I use %20 or a hyphen?
Use a hyphen. %20 is the correct encoding if a space must exist, but the better engineering answer is to not have a space at all. Hyphens are the standard word separator, they read cleanly, and Google treats them as spaces between words for parsing.
What about underscores instead of spaces?
Underscores are legal in URLs so they will not break anything, but Google historically treats an underscore as a word joiner rather than a separator. Hyphens are still the safer choice for slugs you want parsed as separate words.
A plus sign shows up where I expected %20. Is that wrong?
In a query string, a plus sign is a legitimate legacy encoding for a space, inherited from form submissions. In the path portion of a URL it is not, and a plus there means a literal plus. The risk is inconsistency: if some links encode a space as %20 and others as +, you can end up with two URLs for one page.

Spaces in URLs are usually the tip of a bigger URL hygiene problem

If one check flagged encoded spaces, there are almost always duplicate paths, messy redirects, and canonical drift hiding behind it. A full audit finds the whole pattern, not just one symptom.

Get an Advanced SEO Audit

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!

More from our blog