URLs Are a Light Ranking Signal: How to Audit Yours Without a Pointless Migration

Key takeaways

Google confirmed keywords in URLs are a light ranking signal. Run this 60-minute audit to set slug rules, skip needless migrations, and keep URLs clean for AI citations.

URLs became a talking point again this week. In the first episode of The Non-Canonical Cabinet, a new Google Search Central video series, Cherry Prommawin and Gary Illyes walked through what a URL can actually contain and how much any of it matters for ranking. The short version: keywords in a URL or domain are an "incredibly small signal" that "won't do much," hyphens beat underscores, Google can detect spam stuffed into slugs, and emoji domains cannot exist at all. Search Engine Roundtable's Barry Schwartz covered the video on October 14, 2026.

If you stopped sweating URL structure years ago, this video is reassurance, not a to-do list. But there is a small set of decisions worth making deliberately: what your slug rules are going forward, which existing URLs to leave alone, and how your URLs look when an AI engine cites them. This article gives you a 60-minute audit that settles all three. You will finish with written slug rules, a clean scan of your current URLs, and no pointless migration.

What you will finish with

  • Written slug rules your team can apply to every new page.
  • A scan result for your existing URLs, with a keep-or-fix decision for each pattern Google mentioned.
  • A decision record that shows why you are not migrating anything (or a defensible plan if you genuinely must).
  • A check of how your URLs render inside AI citations.

Who this is for

Site owners, SEO leads, and developers who control CMS slug defaults

Prerequisites

Access to your XML sitemap, your CMS admin, and optionally Google Search Console

Time

60-90 minutes for a site up to a few thousand pages

Done means

The rules exist in writing, the scan passes, and no migration has been triggered on a hunch

What Google actually confirmed

Four facts from the video, and none of them is new, but on-record is on-record:

  1. Keywords in URLs are a ranking signal, but a very light one. Illyes described keywords in the URL or domain as an incredibly small signal. His example: a slug like best-grilled-chicken-cheap-delicious-amaze-amaze-amaze will not keep you at #1 forever. Google can also detect spamming in URLs, so stuffing is not just useless, it is visible.
  2. Hyphens vs underscores is settled. Use hyphens to separate words. Google's own explanation is mechanical, not mysterious: "we can't easily segment at underscore, and that's why we are recommending dashes." An underscore joins words into one token a crawler cannot split.
  3. Emoji domains cannot exist, and emoji paths get percent-encoded. An emoji-only domain like the video's joke example cannot be registered. Internationalized domains work but display as punycode, the xn-- form, which looks alarming and is not a hack.
  4. None of this changes rankings much. That is the through-line. The series title is a joke about non-canonical questions, and this episode's answer to most of them is "it barely matters."

The practical weight sits in what you do next, not in the signal itself.

Decide your default first: no migrations

Before touching anything, make the decision that protects you from the most expensive mistake in this topic. Changing a live URL costs you accumulated links, redirect chains, index history, and any AI-citation equity the old URL has earned. The reward for switching underscores to hyphens, or adding a keyword to a path, is a segment of one of the smallest signals Google has named.

So the default is: keep every existing URL that is indexed, linked, and converting. A URL migration is justified by a rebrand, a platform move, or a restructuring with real user value, never by a light ranking signal. Write this down as a one-line policy before the scan, because mid-audit enthusiasm is how pointless migrations start.

Pull your URL inventory

Export the URLs you actually serve, not the ones you remember:

  • Download your XML sitemap (or sitemap index) and extract every <loc> value.
  • Pull the Pages report from Google Search Console for the URLs Google actually indexes. The delta between the two lists is its own finding: URLs in the sitemap but absent from GSC are a separate problem this audit does not fix, so just note them.
  • Add slugs for pages in draft or staging, since the rules you write will apply to those first.

A quick way to get a raw list on any machine with curl and a shell:

bash
curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//'

Expected output: one plain-text file with one URL per line. Quality check: spot-check that the count roughly matches your page count; a sitemap that returns 404 or an HTML error page means fix that first, because every downstream check depends on it.

Scan for the four patterns Google named

Run each check against your URL list. Any line-matching tool works; these are the patterns and what a hit means:

#

Pattern

What to search for

What a hit means

1

Underscores in path

_ after the domain

Words merge into one token for crawlers. Note it, but see the decision table below before touching anything.

2

Keyword stuffing

Slugs with 5+ hyphenated keywords, repeated filler (best-cheap-amaze-amaze)

Google can detect spam in URLs. Rewrite the template that generates these, not the published URLs.

3

Percent-encoded characters

%20, %F0%9F, or any %XX sequence in the path

Spaces and emoji get percent-encoded. Legal for crawlers, ugly for humans and AI citations.

4

Case variants

Any uppercase letter in the path

Some servers treat /Blog and /blog as different URLs. A canonical and consistency check, not a ranking play.

A single grep per pattern over the inventory file is enough. Expected output: a short list of URLs per pattern, usually zero or near-zero for a site with reasonable templates. Quality check: if pattern 2 hits hundreds of URLs, you have a template problem, and the fix belongs in the CMS slug generator, not in 400 redirects.

Apply the keep-or-fix decision table

For every URL that flagged, decide once, using these rules:

Finding

Decision

Why

Existing URL with underscores, indexed and linked

Keep

The segmentation benefit is tiny; the migration cost is real. Revisit only if the URL is rewritten anyway.

Underscores in a not-yet-published page

Fix

Free to change before it exists.

Stuffed slug on a published page

Keep the URL, fix the template

The spam detection risk and the ugly slug both come from the generator.

Percent-encoded characters in a live path

Keep, unless the page is being republished anyway

Encoded URLs work; they just look bad. Change at natural rewrite points.

Uppercase path with both case variants indexed

Fix with 301s

This one is a genuine duplicate-content issue, independent of the video.

Emoji or non-ASCII in a new path

Avoid by default

See the GEO section; the failure mode is citation garbling, not a penalty.

Decision matrix showing which URL patterns to keep or fix after Google's URL video

Expected output: a decision per flagged URL, with every "fix" paired to a redirect map. Recovery path: if you find a fix that requires migrating a high-value URL, stop and write the 301 plan before touching the CMS. No 301 map, no migration.

Write your forward slug rules

This is the part that actually compounds. Put these five rules where whoever ships pages will see them, whether that is a content style guide or the validation logic in your CMS:

  1. Lowercase, hyphen-separated, ASCII words.
  2. Three to five meaningful words, no filler (best, amaze, and repeated qualifiers add nothing and read as spam patterns).
  3. No dates, no stop words, no underscores.
  4. Emoji and non-ASCII characters stay out of paths; if a brand name genuinely needs an IDN, know that it will display as punycode and decide on brand grounds, not SEO ones.
  5. Slugs describe the page, not the query you want to rank. The light signal does not reward aspiration.

Quality check: generate one test draft in your CMS and confirm the default slug passes all five rules. If the CMS auto-generates from the title, that is where the validation belongs.

The GEO pass: how your URLs look inside AI citations

There's one adjustment most teams miss. When an AI engine cites your page, the URL itself becomes part of the answer the user sees. A percent-encoded path renders as %F0%9F%94%A5 soup. A stuffed slug reads as spam inside someone else's answer. And a URL you migrate after being cited becomes a dead link inside AI answers that cached the old address, which is one more reason the no-migration default is also GEO policy.

How a percent-encoded URL garbles an AI citation compared with a clean hyphenated URL

Run the check in three steps:

  1. Collect the prompts your buyers actually use, 10 to 20 of them, and run them through the AI engines your audience does. A visibility tool makes this repeatable, but a spreadsheet and a browser work. AI Search Visibility Checker tracks which answers cite you across engines, so you are not re-pasting prompts by hand each month.
  2. For every citation of your domain, read the URL as displayed. Flag anything percent-encoded, truncated mid-word, or showing a path you retired.
  3. Feed what you find back into the slug rules. If citations keep mangling a pattern, that pattern graduates from "allowed" to "avoid."

Expected output: a sample of your cited URLs, with at most a couple of pattern fixes to apply. Quality check: the same URL should appear in citations a month from now; if a pattern keeps garbling, fix the slug at the next natural rewrite, not with an emergency migration.

Verify the finished result

Confirm four things before calling the audit done:

  • [ ] Slug rules exist in writing, in a place page-shippers actually open.
  • [ ] The four-pattern scan returns zero hits on new and draft URLs.
  • [ ] Every "fix" decision has a redirect map attached; every "keep" decision has no ticket open against it.
  • [ ] No migration has been scheduled for ranking-signal reasons. If one is scheduled for a real reason, it has 301s, updated canonicals, and updated sitemaps in its plan.

Re-run the scan quarterly, or wire it into your next technical SEO review. It takes minutes once the inventory script exists.

FAQ

Should I change my underscore URLs to hyphens now? No. Google recommends hyphens because underscores defeat word segmentation, but the ranking impact is close to zero, and a migration costs far more than it returns. Change underscores only when a URL is being rewritten for a real reason anyway.

Do emojis in URLs hurt rankings? Google has not said they hurt. Emoji-only domains cannot exist, and emoji in paths get percent-encoded, so the practical cost is display and trust: encoded URLs look broken in browsers, citations, and shared links.

Should I put my main keyword in the domain? It is a signal, and Illyes described it as an incredibly small one. A keyword domain also boxes in your brand. Choose domains for the brand, slugs for the reader.

Is `xn--` in a SERP a sign a site is hacked? No. That is punycode, the standard display form for internationalized domains. It looks odd and behaves normally.

Author: Julian Mercer, 14-Year Technical SEO Practitioner at Auspia. Julian writes about crawlability, site architecture, and the technical foundations that keep content readable for search engines and AI systems.

Explore this topic

Keep following the same growth thread