Most messy URLs are not the result of one bad decision. They pile up over years, as pages move, tools get added, and nobody owns the naming. The fix is boring but it works. Pick one clear pattern, write it down, and hold every new page to it.
We see this on almost every site we take over. The blog sits at /blog, but older posts live at /news. Service pages carry dates for no reason. Landing pages built inside a marketing tool sit on a different subdomain entirely. Each choice made sense to someone at the time.
The cost is rarely one big penalty. It is friction. Crawlers waste effort, links break, and visitors cannot guess where a page lives. Cleaning up URL structure is one of the cheapest wins on a website, because getting it right on a new build costs almost nothing.
A good URL is short, readable, and built from real words. Google Search Central tells site owners to create a simple URL structure and to use readable words rather than long ID numbers. If a person can read your URL out loud and guess what the page covers, you have done the main job.
Google's URL structure documentation is direct about the risk. It warns that overly complex URLs, especially ones stuffed with parameters, can cause problems for crawlers. The result is wasted crawling and pages that never get indexed at all.
Readable words help outside of Google too. When someone pastes a link into Slack or a text message, the raw URL is sometimes the only preview they get. A URL ending in /pricing tells the reader something useful. A URL ending in /p?id=48213 tells them nothing.
There is a second job a URL does, and it is easy to miss. It sets expectations. If your URL says /guides/webflow-cms and the page is a sales pitch, people bounce. We treat the URL as the first promise a page makes.
Use hyphens. Google Search Central states plainly that it recommends hyphens instead of underscores to separate words in URLs, because hyphens help users and search engines better identify concepts. This is not a style preference or a debate. It is written guidance from the search engine itself.
The reason is how parsers read the characters. A hyphen acts as a word boundary, so blog-post-page reads as three words. An underscore tends to join words together, so blog_post_page can be read as one long token. That difference changes which queries a URL can match.
Underscores will not sink a site on their own. Plenty of sites rank fine with them. But when you are choosing a pattern from scratch, and one option has explicit vendor guidance behind it, there is no reason to pick the other one.
Spaces and uppercase letters are the two other things we avoid. Spaces become %20, which looks broken when shared. Uppercase letters create a trap, because some servers treat /Pricing and /pricing as two different pages, which is exactly the duplicate content problem you want to avoid.
Shorter is better, but the effect is smaller than most people think. Backlinko's analysis of 11.8 million Google search results found that the average URL on Google's first page runs 66 characters, and that top-ranking URLs averaged 9.2 characters shorter than results in tenth place. That is a real pattern, not a large one.
We read that data as correlation, not instruction. Short URLs tend to belong to older, better-linked pages on well-organized sites. The shortness is a symptom of good structure, not the cause of good rankings. Trimming five characters off a slug will not move you up a page.
What length does affect is clicking and sharing. A URL that wraps onto three lines in an email looks untrustworthy. In our experience, the practical ceiling is whatever fits in the browser address bar without truncation, which lands most slugs in the range Backlinko measured.
The honest rule is to cut filler, not meaning. Drop words like "the", "a", and "your" from slugs. Keep the words a person would actually search. A slug of /how-do-you-choose-the-best-web-hosting-for-your-business becomes /choose-web-hosting and loses nothing.
Use folders when they reflect how the site is genuinely organized, and skip them when they do not. A folder like /blog or /work earns its place because it groups a real section. A folder that exists only to stuff a keyword into the path adds length without adding clarity.
Deep nesting is where this goes wrong. Some content management systems bury a single article several folders down, carrying the year, the month, the category, and the author in the path. Every one of those segments is a chance for the URL to break later, because categories get renamed and authors leave.
Dates in URLs are the clearest example. A URL with /2023/ in it tells every reader that the page is old, even after you rewrite the content. Platforms like WordPress default to this pattern, which is one reason we flatten paths during a migration to Webflow.
Our default on Webflow builds is one level for the collection and one for the item, so a post lands at /blog/your-slug and a case study at /work/client-name. Anything deeper needs a reason. If you are planning a platform move, our guide on how to migrate a website without losing SEO covers how to map old paths to new ones before you switch.
Keep parameters that change what the page shows, and cut the ones that do not. Google Search Central advises shortening URLs by trimming unnecessary parameters, meaning parameters that do not change the content. A filter that loads different products is content. A campaign tag is not.
Tracking parameters are the usual culprit. UTM tags from Google Analytics, click identifiers appended by ad platforms, and session tokens all create fresh URLs that show identical content. Left alone, they multiply into thousands of near-duplicate addresses for the same page.
The fix is a self-referencing canonical tag on every page, pointing at the clean version of the URL. Google's own canonicalization documentation ranks rel="canonical" links as a strong signal for which version should become canonical, and notes that sitemap inclusion is only a weak one. We cover the setup in detail in our guide to canonical URLs and duplicate content.
Faceted navigation on ecommerce sites deserves extra care. When color, size, and price filters all become parameters, the number of possible URLs grows fast. Tools like Screaming Frog and Semrush will show you the real count, which is usually higher than anyone expects.
Yes, but for a different reason than ranking. Answer engines cite sources by URL, and that URL is often visible to the person reading the answer. A clean, descriptive address makes the citation look credible. A string of numbers and parameters looks like spam next to it.
There is a practical angle too. Systems like ChatGPT, Perplexity, Claude, and Google AI Overviews build answers from pages they can fetch and parse. A URL that redirects three times, or that only works with the right parameters attached, is a URL that some crawlers will give up on.
Descriptive paths also carry meaning on their own. A URL that reads /blog/core-web-vitals-seo signals the topic before a single word of the page is parsed. That is a small signal, but it costs nothing to send, and it lines up with how entity-based systems match a page to a question.
We would not restructure a whole site for AI citation alone. We would make sure the URLs you already have are stable, readable, and reachable in one hop, which is good practice regardless of who is reading.
Change a URL when it is actively wrong, and leave it alone when it is merely imperfect. A URL is worth changing if it is broken, if it contains a name that no longer exists, or if it sits in a structure you are rebuilding anyway. Cosmetic tidying is not worth the risk.
This is the part people get backwards. Every URL change is a small bet. You trade a page with existing links and history for a new address that has neither, and you rely on redirects to carry the value across. Google's redirect documentation says Googlebot follows the redirect and the indexing pipeline uses it as a signal that the target should be canonical, which works, but it is still an extra step.
So we ask one question before any rename: what breaks if we do nothing? If the answer is "the URL is a bit ugly", we do nothing. If the answer is "the path names a service the business no longer offers", we change it.
The exception is a full rebuild. When a site is being replaced anyway, the redirect work is already happening, so that is the cheapest moment to fix every path at once. Doing it piecemeal over months is what creates redirect chains.
Map every old URL to its closest new one, then set permanent redirects before launch. Google recommends using a permanent server-side redirect whenever possible when you change the URL of a page shown in search results. The work is in the mapping, not the redirect itself.
Start by exporting the full list of live URLs. Google Search Console shows what Google has actually indexed, and a crawl from Screaming Frog or Semrush shows what exists on the site. The two lists rarely match, and the gap is usually where the surprises live.
Then match each old URL to one new destination. Point it at the closest equivalent page, not at the homepage. Sending everything to the homepage is technically a redirect and practically a dead end, because a visitor who wanted your pricing page will leave rather than hunt for it.
Redirect chains are the failure we see most often after a migration. Page A points to B, B points to C, and each hop adds latency and loses a little signal. We flatten chains so every old URL points straight at its final destination in one hop. Our full walkthrough on setting up redirects without losing traffic covers the testing process we use before a launch goes live.
After launch, watch Search Console for two things: a rise in crawl errors and a drop in indexed pages. Both show up within days if the mapping missed something. Fixing it in week one is routine. Finding it in month three is a project.
Start with the URLs that are already broken, then set a pattern for everything new. Fix 404s that still receive traffic, flatten any redirect chains, and add self-referencing canonicals to pages that collect tracking parameters. Only after that should you consider renaming anything that currently works.
The reason for that order is simple. Broken URLs cost you visitors today. Ugly URLs cost you very little, and fixing them carries its own risk. We would rather spend the effort on the pages that are actually losing people.
If you are starting a new site, the whole problem disappears. Write the URL pattern down before the first page is built, keep it to lowercase words separated by hyphens, and never put a date in a path. It takes an hour and it saves years of cleanup.
If you are staring at a tangle of old URLs and are not sure which ones are safe to touch, we are happy to walk through it with you. Send us the site at phoenix.studio and we will tell you honestly what is worth fixing and what is fine to leave alone.
Tell us where you want to go. We'll tell you how we'd get you there.