Google URL Structure Update: Hyphens for SEO and GEO

Google's October 23 URL structure update clarifies why hyphens are preferable to underscores for separating words. Treat it as guidance for understandable addresses, not a new ranking announcement or an AI citation shortcut. Review new URL templates, preserve useful existing addresses, and prioritize access and content quality before cosmetic changes.

What changed in Google's URL guidance?

Google recorded the clarification on October 23, 2026. Its documentation changelog says the revision explains word separation with hyphens versus underscores and aligns the text with its Non-Canonical Cabinet video series. The entry describes a documentation update, not an announced change to ranking systems. Google Search documentation updates.

This distinction matters for a team deciding what to ship on Monday. A clearer recommendation can improve a publishing convention without justifying a rewrite of every working address. First identify whether the problem concerns a new template, a confusing link, or an actual access failure. Those situations need different decisions and different evidence.

The practical opportunity is governance: decide how your CMS creates readable new addresses, how editors review them, and when an address should remain unchanged. This article focuses on that naming decision. Moving pages that already have links and citations is a separate operational task covered in our AI citation URL migration guide.

Why does Google recommend hyphens over underscores?

Google recommends hyphens as word separators because they make word boundaries clearer. It explains the historical use of underscores for concepts intended to stay together, including programming identifiers. That is an explanation of a URL convention, not a promise that adding a separator will improve a page's position. Official word-separator guidance.

For a new editorial page, /guides/city-breaks is a straightforward convention. It is also easier to discuss in an editorial checklist than a mixture of joined words, inconsistent capitalization and automatically generated identifiers. A clear convention reduces avoidable decisions across writers, developers and localization teams.

Do not turn that convention into a rule that destroys meaning. Product identifiers, API routes and application state may have requirements unrelated to an editorial slug. Keep a useful distinction between a human-facing content address and a technical identifier. Review each route's contract before applying a broad replacement rule.

Does this create a new optimization for AI search?

No new AI-specific URL requirement is established by this clarification. Google's AI-features documentation says supporting pages must be indexed and eligible for a Search snippet, with no additional technical requirements. It continues to recommend the established SEO foundations. Google's guidance for AI features and websites.

Our recommendation for GEO teams is therefore modest: use addresses that people can understand and your publishing system can maintain. Then verify that the page actually answers its intended question. A tidy path cannot supply missing evidence, correct a misleading product description, or make an inaccessible document available.

The distinction also protects reporting. A successful URL-template release is an engineering outcome. A new citation is an observation from an answer engine under particular conditions. Neither should be substituted for the other. Our GEO hub explains how technical readiness fits into the broader visibility workflow.

Which URL issues deserve attention first?

Start with the defect that prevents a useful page from functioning, not the easiest string to edit. The following table is a proposed triage framework, not a Google ranking formula or a measured GEOCARA result.

Situation	First action	Evidence to retain
A new article template creates joined words	Adopt a readable hyphen convention before launch	Approved slug and generated link
A working older page uses underscores	Assess benefit and change risk before renaming	Existing links, destination and decision owner
A navigation link leads to an error	Repair the link or route before naming cleanup	Actual response and final destination
A content change exists only after a URL fragment	Review routing and distinct page availability	Address, returned document and rendered content
Filters generate many near-identical addresses	Define useful views and review parameter behavior	Example combinations and expected content
A localized slug is encoded inconsistently	Test the published link through the full stack	Editor value, HTML link and received path

Google's URL guidance separately discusses fragment-based content, parameter syntax, encoding and excessive URL combinations. These are different concerns from word separation; classify them separately in a ticket rather than calling every failure a hyphen problem. URL structure requirements and common issues.

How should you review a new slug before publication?

Write the page's intended question in plain language before choosing its address. Pick a short description of that subject rather than copying the entire headline, inserting every secondary keyword, or adding a year without a real need for a dated edition. These are editorial maintenance choices, not claims about an ideal Google URL length.

Check the proposed address against existing routes and content. Two teams may use different wording for the same intent. A readable new slug does not resolve duplication between two articles answering the same question. Assign one primary page to the intent and decide whether the second draft adds a genuinely different use case.

Then review the generated output rather than only the CMS field. Inspect the public link, canonical address, navigation entry and sitemap entry together. Use a normal browser to follow the exact link that readers will receive. A template may encode or normalize the value differently from the editorial preview.

Keep the release record small: page owner, approved address, expected destination, meaningful content difference and the checks performed. Our AI metadata QA guide adds the adjacent checks for titles, descriptions and structured data without confusing those fields with the URL itself.

What should multilingual teams do differently?

Choose a convention that serves the intended audience, and document who approves it. Do not automatically translate a live address just because a translation tool supplies an alternative. The localized page, navigation and maintenance process need an owner, not merely another generated string.

Google's URL guide recommends audience-language words and appropriate percent encoding. The operational work is to make those choices consistent across your CMS, links and server handling. Test the encoded public link rather than assuming that a correctly displayed browser address proves every layer handles it identically. Language and encoding recommendations.

Use a reviewed example for each supported writing system. Have an editor confirm the wording and a developer confirm the actual destination. Record how spaces, punctuation and reserved characters are handled. Avoid a last-minute batch conversion of existing addresses while also launching a translation workflow. See our multilingual SEO and AI search guide for the broader content journey.

When should existing URLs stay unchanged?

Keep a working address when the only proposed benefit is that it looks neater and no concrete user or operational problem has been established. A long-lived page may already be referenced in documents, messages, bookmarks and external answers. Renaming it introduces work that a new-page convention does not require.

If a change is necessary, create a separate migration task with an owner, mapping and verification plan. Do not quietly combine URL renaming with a content refresh and then attribute all later movement to the separator. Multiple simultaneous changes make both troubleshooting and performance interpretation harder.

For the release decision, ask what will be better for a reader and how the team will verify it. Clearer naming for a new product family is a specific benefit. A prediction that every model will cite the page more often is not a substitute for evidence. Keep the conclusion proportionate to what was tested.

What should the release checklist contain?

• Confirm that the new address describes a distinct, useful page.
• Check word separation without rewriting technical identifiers blindly.
• Follow the exact public link and inspect the returned content.
• Verify agreement between navigation, canonical and sitemap entries.
• Review localized wording and encoding with the relevant owners.
• Record old-to-new mappings if an existing address must change.
• Keep HTTP accessibility, indexing evidence and AI citations as separate outcomes.

Use the free AI visibility checker as an initial technical-readiness review, not as proof that a particular engine has indexed or cited the page. Retain the actual observations from your release checks and investigate disagreements before expanding the change to other templates.

Frequently asked questions

Is there a universal maximum number of words for a slug?

This clarification does not establish one. Set a practical editorial convention around clarity and maintenance instead of inventing a numerical ranking threshold. Review exceptions where a product name or subject needs more words to remain understandable.

Should a URL repeat every term from the title?

No. Use the address to identify the subject, while the title can express the page's full promise. Adding loosely related terms makes an address harder to review and does not demonstrate that the underlying content meets those additional intents.

Can an underscore URL still be the right destination for an internal link?

Yes, if it is the current working address of the intended page. Link to the real destination rather than manufacturing a hyphenated alternative that has never been published. Treat a proposed rename as a separate change with its own checks.

How should teams evaluate autogenerated product URLs?

Review a representative sample that includes variants, punctuation and duplicate names. Confirm that distinct products still have distinct destinations and that the naming rule does not alter required identifiers. A clean-looking sample alone is not enough to approve a whole catalog.

What should a report say after the template is fixed?

State the observed result: the convention changed, the affected pages passed specific checks, and any remaining issues are listed. Report indexing and answer-engine citations only when independently observed. Do not convert a completed technical ticket into an unsupported visibility improvement.

Turn the clarification into a controlled publishing rule

Update the convention for new pages first, test one template and record the result. Leave stable addresses alone unless a real problem warrants a migration. Google's clarification is useful because it makes a small publishing decision easier to explain; it is not permission to replace evidence-led SEO and GEO work with cosmetic URL changes.