Information Architecture
URL Structure: Keep Article Addresses Clear and Stable
This guide is part of the King of AEO learning library.
The short answer
A useful URL structure gives each article a readable, durable address and avoids unnecessary variants. Choose slugs that describe the subject, separate stable identity from changing editorial categories, and use consistent conventions. Keep working URLs unless a real migration need justifies the change, then handle legacy addresses and internal references as part of that move.
In this guide
Treat the address as a durable referenceSeparate article identity from flexible categoriesSet conventions before variants accumulateDistinguish content parameters from tracking parametersKeep links aligned with the preferred routeMake international routes represent real versionsChange URLs only with a complete migration pathSourcesTreat the address as a durable reference
A URL is used in bookmarks, citations, messages, browser history and links from other websites. Changing it therefore affects more than the label visible in your own navigation. Start with a route that can remain useful while the article's title and content evolve. An explanatory guide about pagination can keep the same subject address when examples or implementation details change. A date or promotional phrase in that address may become misleading even though the underlying reader question remains the same.
A concise descriptive slug helps people recognise the subject, but it does not need to reproduce the entire headline. A title can explain the benefit while the URL identifies the topic. Google's URL guidance supports readable, simple structures. Use that as a practical design principle rather than a reason to repeatedly rename established routes for marginal wording changes. Once an address is in use, the possible benefit of a slightly shorter slug needs to be weighed against the work and risk of maintaining its old references.
Separate article identity from flexible categories
Putting categories into paths can make a hierarchy visible, but it also ties addresses to editorial organisation. If the category is likely to change, a flatter article route may be easier to maintain. A library can use /learn/subject-slug while storing the category separately. Breadcrumbs and category listings then communicate the structure without forcing a URL move whenever editors reorganise the collection. Neither flat nor nested routes are universally correct; choose based on how durable the hierarchy is and how the application manages content.
For an illustrative library, a guide to customer permissions might begin under Getting started and later belong under Security. If its address includes the first category, moving it creates a redirect requirement. If the article has a stable independent route, only the navigation relationship needs to change. The breadcrumb guide explains that relationship. A deeply nested URL should reflect meaningful stable levels, not every administrative tag, ownership team or temporary campaign assigned to the article in the content system.
Article subject: Durable identity
Preferred route: Readable stable address
Category metadata: Can change independently
Legacy route: Retained entry point
Current article: Consistent destination
Article identity can remain stable while navigation changes. A URL move requires preserving meaningful legacy entry points.
Set conventions before variants accumulate
Choose consistent handling for letter case, trailing slashes and word separation. Then make the application, internal links and preferred URL references follow the same choice. Inconsistent conventions can create several working addresses for the same content. Some variants may be unavoidable because old links already exist, but new content should not multiply them casually. Test the actual server behaviour rather than assuming that two visually similar paths are treated identically. The route parser and hosting configuration determine what a request receives.
A convention should also explain collisions. Two proposed articles cannot share the same preferred address, so use the editorial intent to resolve whether they need separate pages. If they answer different tasks, choose slugs that name that difference. If they answer the same task, a numeric suffix may hide a content planning problem. Refer to content consolidation when duplication already exists. URL naming works best when it follows a clear ownership boundary between answers instead of compensating for an unclear library structure after publication.
Distinguish content parameters from tracking parameters
Parameters can legitimately represent different content states, such as a later collection page. Others merely describe how someone arrived. Do not assume every parameter should be stripped, nor that every parameter combination deserves a distinct indexed page. Identify what each one changes. An article address with a campaign tag may still represent the same article, while a collection page parameter may identify a different subset. The pagination guide covers that second case in detail and explains why continuation pages should remain meaningful destinations.
For an illustrative audit, compare an article with and without a referral parameter. If the body and purpose are identical, the parameter is probably not part of the article's identity. Compare a filtered product or document collection more carefully: a filter may change the visible set substantially while still being unsuitable as a public landing page. Keep the decision explicit. Canonical URLs address preferred representations of equivalent content, while crawl controls address access. Those tools serve different purposes and should not become interchangeable ways to hide every complex route.
Keep links aligned with the preferred route
Once a preferred address is chosen, use it consistently in navigation, article references and relevant metadata. Google's link guidance provides the technical foundation for linked discovery. A site that continually links to legacy variants makes its own structure harder to inspect and maintain. Redirects can preserve old entry points, but internal references should normally lead straight to the current destination. This reduces unnecessary indirection and makes future audits easier because the linked graph reflects the routes readers are meant to use.
Check root-relative links in the context where they will be published. A link that works on the homepage may resolve differently if it was written relative to a nested directory. Reusable components need particular care because the same markup can appear on several route depths. Test a representative article, category and paginated view. The technical release checklist should include these route relationships when navigation components change. A neat naming convention cannot prevent broken links if the application assembles destination paths inconsistently across templates.
Make international routes represent real versions
Language and regional versions can justify separate URLs because the content serves distinct audiences. Choose a structure that can support those versions consistently, then keep language identity separate from incidental browser or location assumptions. A reader should be able to share the address of the version they actually read. Do not create a regional path solely to repeat the same English text under a different label if there is no meaningful regional purpose. The address should represent a real editorial and user experience decision.
The international AEO guide covers language and locale relationships in more depth. For URL planning, consider whether translated slugs can be maintained, how the language selector links between versions and what happens when one translation is retired. Do not silently redirect every unfamiliar locale to a generic page without considering the reader's expectation. The structure should remain predictable for editors as well as visitors, so a new language does not require inventing a different routing convention for every article added to the library.
Change URLs only with a complete migration path
Sometimes a move is necessary: a domain changes, a platform replaces its route scheme or several pages consolidate into one better answer. Map old addresses to meaningful destinations before release. Update internal references and preferred URL declarations, then test the old entry points as well as the new pages. Avoid redirect chains where an old route passes through several intermediate addresses before reaching the article. The migration checklist covers the broader work, including cases where a page has no equivalent successor.
After the move, keep watching real requests and known references for overlooked routes. A migration is not complete merely because the new navigation works from the homepage. External readers may continue using old links for a long time. Preserve the meaning of those journeys where possible and return honest behaviour where content has gone. A stable URL structure earns its value through years of dependable references. Choose clear conventions early, maintain them consistently and reserve disruptive changes for needs that genuinely outweigh the cost of moving an established address.
Sources and further reading
- Google URL structure guidanceSimple descriptive URL structures reduce crawling problems.
- Google crawlable link guidanceOrdinary anchor elements with href attributes enable link discovery.