SEO-Friendly URL Checker

What makes an SEO friendly URL, and what it cannot do for a page.

An address is the one piece of a page that shows up everywhere: in results, in link previews, in emails and on printed brochures. Here is what Google actually recommends for it, what is convention rather than rule, and why a slug deserves the same review as a headline.

URL structure and SEO: what Google asks for

Google's URL structure documentation asks for three things, and none of them is about ranking. Use descriptive words: "use readable words rather than long ID numbers in your URLs." Use your audience's language, so a German audience gets German words. And keep the structure simple enough that a crawler does not find thousands of addresses for the same content. A good SEO URL is one a person can read aloud and roughly predict the page from:

# readable: words, hyphens, one case
https://yourfirm.com/estate-planning/revocable-trusts/

# hard to read, and one template can mint thousands of these
https://yourfirm.com/index.php?id=4471&cat=12&sessionid=6EE2BF1A

The anatomy matters for what follows. After the host comes the path, the slash-separated part that names the page; the slug is its last segment. After a ? comes the query string, key and value pairs joined by = and separated by &, which is the encoding Google recommends. After a # comes the fragment, which a browser keeps to itself and never sends to the server.

Hyphens vs underscores

Google's recommendation is direct: use hyphens between words, not underscores, "as it helps users and search engines better identify concepts in the URL." The reason given is historical. Underscores are the convention for joining words that belong together, the way a programmer writes format_date, so estate_planning reads as one token where estate-planning reads as two words. Words run together with no separator at all, like /estateplanning, are the third pattern Google lists as not recommended. This checker flags underscores in the path; it cannot tell a run-together word from a real one, so that one is left to your eye.

Capital letters and duplicate addresses

Paths are case sensitive. In Google's words, it "treats both /APPLE and /apple as distinct URLs with their own content." Some servers answer both spellings with the same page, which quietly gives every page two addresses and splits the links pointing at it. Google's advice is to convert all text to one case if your server treats them the same. Lowercase is the usual choice because it is what people type. The host part is not affected: YourFirm.com and yourfirm.com are the same site, so this checker reads case in the path only.

How long a URL should be

Google publishes no maximum URL length for ranking, and the figures quoted on tool pages, 75 characters, 100 characters, are conventions. Shorter addresses are easier to read, share and trust, and Google does ask you to trim "unnecessary parameters (meaning, parameters that don't change the content)." Verand's site audit flags an address over 200 characters, because at that length something has usually gone wrong: a string of tracking parameters, a filter combination, or a slug generated from a full sentence. That line is ours, not Google's, and the card says so. The address of one Willowdale Equity article is 67 characters and passes easily; the same article reached through a newsletter link with five tracking parameters is 249 characters and fails.

Query parameters and session IDs

Parameters are not bad in themselves. A filter, a sort order or a page number that changes what the page shows is a legitimate reason for one. The trouble is volume: Google warns that "overly complex URLs, especially those containing multiple parameters, can cause problems for crawlers by creating unnecessarily high numbers of URLs that point to identical or similar content." Session IDs are the worst case, a new address for every visitor, and Google's advice is to avoid them and use cookies instead.

• Tracking parameters such as utm_source, gclid and fbclid do not change the content. Keep them on the links you share if you need the attribution, and make sure the page's canonical names the clean address, which is the row this card reads from the fetch.
• Session IDs such as sessionid, sid or PHPSESSID in a link mean every visit produces a new URL. The card flags parameter names that look like one.
• Filters and sorting multiply: every combination of values is another address for the same listing page. Canonicals and internal links that point at the unfiltered version keep that in check.

Trailing slashes and the canonical

/blog and /blog/ are two different addresses to a crawler. Most servers pick one and redirect the other, which is fine; the saved run for verand.ai/blog/ shows exactly that, a redirect to /blog. What causes trouble is a site that serves both, or links to one and redirects it to the other on every click. The redirect row on this card shows where the address you typed actually lands, and the canonical row shows which address the page claims as its own. When the two agree with the address in your links, the structure is settled. The Canonical Tag Checker goes deeper on that tag.

The slug is copy, and copy gets reviewed

For a regulated firm this is the part of URL structure that matters most, and the ranking pages on this topic skip it: they discuss keywords and length only. A slug is visible text. It appears under the title in search results, in the preview when someone pastes the link, in the address bar and in the printed version of a page. It is also the one piece of copy that usually outlives an edit. A compliance review removes an outcome claim from the headline and the body, and the page still lives at /guaranteed-monthly-income/ or /best-injury-lawyer-in-town/, because changing the address felt like a technical job for someone else.

• Review slugs with headlines. Whoever signs off the title should sign off the address in the same pass, before the page is first published. Changing a slug later costs a redirect.
• Describe, don't promise. /how-a-1031-exchange-works/ ages well. A slug that states a result or a superlative carries that claim for as long as the page exists.
• When the copy changes, check the address. If a claim was removed from the page for compliance reasons and the slug still states it, the slug needs to change too, with a 301 from the old address.

This checker does not judge the words in a slug; it has no way to know what your regulator allows. Verand's Marketing Compliance Checker reads page text against an industry rule set, so paste the headline and the slug words there if you want them read the same way as the body.

Dates, stop words and keywords

Three questions come up on every URL checklist, and Google's URL documentation addresses none of them directly. Dates in a path make sense for news, where the date is part of what the page is, and work against an evergreen guide you plan to update, because the address keeps announcing the year it was written. Stop words like the, and and of can go when the slug stays readable without them. A keyword in the URL helps a reader see what the page is about; treating it as a strong ranking lever is not supported by anything Google publishes. This checker reads none of the three, because each is a judgement about your words rather than a rule about the address.

Changing an existing URL

A URL that works and has links pointing at it is worth more than a tidier one without them, so cosmetic fixes to live pages are rarely worth making. When a change is justified, a claim in the slug, a session ID, a structure that multiplies, Google's redirect documentation is clear: "If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible." That is a 301 or a 308 from the old address to the new one. Then update the internal links, the sitemap and the canonical tag so they name the new address directly rather than leaning on the redirect, and run the old address through this URL SEO checker to see the redirect row say where it lands.