Google clarified URL separators. Should you rename pages that AI already cites?

Use hyphens when creating new descriptive URLs. Treat renaming an established page as a separate decision: what benefit justifies the move, and how will you verify that existing links still lead to the right answer?

That is our editorial recommendation following Google's latest URL guidance clarification. It is not a claim that a different separator will earn AI citations.

What Google clarified

Google's October 23, 2026 documentation changelog records a clarification about separating URL words with hyphens versus underscores. It says the change synchronizes the documentation with its video series. The entry does not announce a ranking update.

The URL structure guidance recommends hyphens rather than underscores to make word boundaries clearer to users and search engines. That is a useful default for a new publishing template. It does not, by itself, establish a business case for moving a working library of pages.

The practical AEO question is narrower than “which separator is better?” It is “if we change the address of a source page, can someone following an existing citation still reach the intended evidence?” The workflow below is AEO Landscape's proposed operating procedure, not a Google requirement or a description of every answer engine's behavior.

1. Separate a new-slug rule from a migration request

Write two tickets, not one blanket URL cleanup.

For new content, set a readable hyphenated slug convention. For existing content, require a decision note naming the problem, the proposed replacement, an accountable owner, and the acceptance checks.

Our suggested threshold is a concrete reason beyond cosmetic consistency: perhaps a planned information-architecture change, a confusing public address, or a publishing-system constraint. These are examples for your team's judgment, not proven citation factors.

If the only reason is “the documentation changed,” leave the established URL in place while improving the answer on that page. Use the time to verify its claims, sources, and usefulness. For a separate editorial checklist, read how to structure an answer page; changing the address is not a substitute for that work.

2. Build an old-address ledger before editing routes

Start with the pages actually in scope, not a global replacement of every underscore. For each, record:

• The exact old URL and the proposed new URL.
• The question the page answers and the evidence it contains.
• Known internal links and any observed external or AI citations.
• The intended final destination and the person who will test it.
• A dated pre-change response check and a rollback decision owner.

Keep the literal cited address. Do not normalize it into the proposed new URL in your notes: that would remove the distinction you need later.

For a short list of pages, a spreadsheet and saved answer captures are sufficient. The aim is traceability, not buying another dashboard. Prioritize addresses with known readers or observed citations for manual checks, while remembering that an incomplete observation log is not a complete inventory of how engines use your site.

3. Preserve the answer, not just a redirect response

Before launch, compare the old page's purpose with the replacement. Does the target still answer the same question? Are the cited explanation, supporting source links, and important section anchors available? Assign these as human acceptance checks.

Avoid treating a generic category page as an acceptable replacement merely because it returns a successful response. In this workflow, success means reaching the relevant answer, not merely reaching any page.

For Google's documented handling of permanent moves, its redirect guidance recommends server-side permanent redirects such as HTTP 301 or 308. Test the actual response from the old address and the final page; don't infer behavior from a CMS setting's label.

Our preferred release check is one direct old-to-new hop for each mapping, with no loop and no accidental detour through a homepage. Treat that as an engineering acceptance criterion, not a promised ranking benefit.

4. Check the signals together

Google's canonicalization documentation describes redirects and canonical annotations as strong signals, and sitemap inclusion as a weaker one. It also warns against conflicting canonical preferences. These are signals, not a guarantee that Google will select your preferred URL.

Turn that into a small release checklist: inspect the replacement's canonical annotation, its sitemap entry, and the internal links you control. Write the intended address once in the migration ticket, then compare every output against it. Test the rendered page as well as the route configuration.

If the site already sends change notifications, keep that process distinct from validation. Our IndexNow workflow covers that separate task. Notification is not this migration's acceptance test.

5. Recheck citations without rewriting the baseline

After the move, repeat the relevant question sample. CiteCue offers prompt monitoring and citation tracking for this kind of observational follow-up. AEO Landscape and CiteCue have common ownership; see our ownership disclosure. Check the supported engines and coverage for your account before choosing the sample.

For every observation, save the question, engine, date, literal cited URL, and the destination reached when you open that link. Keep the before-and-after sample definition stable. Our citation measurement protocol explains the broader measurement discipline.

Report these as different outcomes:

• An old address is still cited and correctly reaches the replacement.
• The new address is cited and opens the intended page.
• A cited address fails or reaches unrelated content.
• The page is not cited in that particular answer sample.

The first outcome is not the same operational problem as the third. The fourth does not identify a cause. CiteCue observations are sampled outputs, not first-party engine crawl or indexing records; they cannot establish that the move caused a change in citations.

A sensible stopping rule

Close the migration ticket when the agreed mappings, destination content, and on-site signals pass their checks. Keep unresolved citation observations in a separate monitoring log rather than repeatedly changing URLs in response to individual answers.

For a small team, the useful result is a defensible change record: why the move happened, what was preserved, what was tested, and what remains unknown. Neither cleaner separators nor successful redirects promise mentions, rankings, traffic, or revenue.

Sources and verification

Verified on October 26, 2026. Google's documentation supports the stated separator recommendation, redirect handling, and canonical signals. The migration decision threshold, ledger, acceptance checks, and observation categories are AEO Landscape editorial recommendations.

• Google Search documentation updates: October 23 clarification and its stated rationale.
• Google URL structure best practices: hyphens and word boundaries.
• Google redirects and Search: permanent server-side moves.
• Google canonical URL guidance: signal strengths and conflicting preferences.
• CiteCue's product description: prompt and citation monitoring scope, not independent evidence of outcomes.