How to use Drupal’s Pathauto for SEO-friendly URLs
Clean URLs help people understand a page before they open it, and they give search engines useful context about its subject. In Drupal, Pathauto automates this work by creating URL aliases from patterns, so editors do not need to type a new address for every article, product or landing page.
A well-planned alias system is especially useful for Australian websites with local service pages. A business might need separate URLs for Sydney, Melbourne, Brisbane and Perth, while a publisher may organise content around topics such as bushfire preparation, NRL, property, tourism or regional events.
Pathauto does not replace keyword research or good information architecture. It applies the rules you define. If those rules are too broad, URLs can become confusing, duplicate aliases may appear, or a small change to a content type can affect thousands of pages.
The safest approach is to decide on a URL structure first, test it on a staging site, and then enable automatic generation. The following settings provide a practical foundation for Drupal 9 and Drupal 10, with many of the same concepts applying to newer Drupal releases.
| Requirement | Recommended approach | Common risk |
|---|---|---|
| Blog articles | /blog/[node:title] or /news/[node:title] |
Long or vague titles |
| Basic pages | /[node:title] only for carefully managed sites |
Collisions with system paths |
| Products or services | /services/[node:title] or a taxonomy-based pattern |
Changing business categories |
| Local landing pages | /locations/[node:field_city]/[node:title] |
Inconsistent city names |
| Taxonomy terms | /topics/[term:name] |
Duplicate terms and poor hierarchy |
| Existing indexed pages | Preserve aliases and add redirects | Broken backlinks and lost rankings |
What Pathauto does in Drupal
Pathauto is a contributed Drupal module that creates URL aliases automatically. Drupal’s internal path might look like /node/123, but Pathauto can expose that same content as /blog/drupal-seo-guide. The node still has its internal identifier, while visitors and search engines see the readable alias.
The module relies on tokens. A token is a placeholder that Drupal replaces with content, such as a node title, author name, content type or taxonomy term. Typical examples include [node:title], [node:created:custom:Y], [node:content-type:name] and a field token such as [node:field-city].
Pathauto usually works alongside the Token and Chaos Tool Suite ecosystems, depending on the Drupal version and installation method. Install it with Composer where possible, then enable it through the Extend page or Drush. Before creating patterns, check that the relevant fields exist and that their values are consistently entered by editors.
The module does not automatically make every alias SEO-friendly. A title such as “Untitled” can produce a poor URL, and a pattern based on a frequently edited field can generate unstable addresses. URL quality depends on the content model, editorial process and redirect settings surrounding Pathauto.
Planning a URL structure that lasts
Start with the major content types on the website. A community organisation might have articles, events, projects and staff profiles, while an Australian trades business could have services, suburbs, case studies and contact pages. Each type should have a predictable location in the URL hierarchy.
Useful patterns are usually short and descriptive. Examples include /news/[node:title], /events/[node:title] and /services/[node:title]. A location-based business may use /locations/[node:field-state]/[node:field-suburb]/[node:title], though this should be used only when the location fields are controlled and genuinely important to navigation.
Avoid placing dates in every URL unless the publishing archive depends on them. A pattern such as /2025/03/long-article-title can become awkward when evergreen content is updated. It also creates a migration problem if the editorial team later removes dates from the site structure.
For Australian audiences, use the terms customers actually recognise. “Removalists” may be more appropriate than “moving companies” for an Australian service website, while a tourism website might use /things-to-do/tasmania rather than an imported overseas naming convention. Local language should be based on search research, not assumptions.
Installing and configuring Pathauto
Install the module with a command such as composer require drupal/pathauto, then enable it with Drush or Drupal’s administration interface. The exact command may vary according to the project’s deployment process, but Composer keeps the module version controlled and repeatable across local, staging and production environments.
After enabling Pathauto, review the configuration at Configuration, Search and metadata, URL aliases and Patterns. Create one pattern per relevant entity type. For nodes, choose the content type and enter a path pattern using available tokens. Save the pattern, then inspect the generated preview where Drupal provides one.
The “update action” setting deserves careful attention. When a title or relevant field changes, Drupal may leave the old alias in place, create a new alias, or replace the existing alias. Keeping the old alias and generating a redirect is generally safer for published content because bookmarks, backlinks and search engine results can continue to reach the page.
Set the punctuation and case rules under Pathauto’s general configuration. Lowercase aliases with hyphens are the normal choice. Remove unnecessary words and punctuation, but be cautious with accented characters and non-English terms. Drupal’s transliteration settings can turn characters such as “é” into a plain Latin equivalent, which improves compatibility with some systems.
Choosing tokens and avoiding duplicate aliases
The [node:title] token is the starting point for many content patterns, but titles alone can produce collisions. Two content items called “Welcome” may both attempt to use /welcome. Drupal can add a numeric suffix, yet /welcome-1 is rarely a useful long-term information architecture.
Adding the content type or a taxonomy segment prevents many conflicts. For example, /guides/[node:title] and /case-studies/[node:title] are clearer than relying on a title token across the entire website. If the website has several versions of the same resource, use a controlled field rather than asking editors to make titles artificially unique.
Taxonomy tokens can create meaningful topical URLs, such as /topics/web-development/[node:title]. Use this structure only when the term is stable and each item has one primary category. If editors can select several terms, Drupal may generate ambiguous or repeated paths, and changing the first term can move the page unexpectedly.
Fields need consistent values. “NSW”, “New South Wales” and “N.S.W.” should not all be accepted for a state field used in an alias. A controlled vocabulary or list field is a better option. This matters for websites serving places such as Parramatta, Geelong or the Gold Coast, where a small spelling variation can create separate URL paths for what users regard as the same place.
Managing changes, redirects and migrations
URL changes are a technical SEO event, even when the page content stays the same. If an article moves from /blog/drupal-guide to /resources/drupal-guide, the old address should redirect permanently to the new one. This preserves much of the page’s accumulated authority and prevents visitors from meeting a 404 page.
Enable redirect handling if it is part of the project’s approved Drupal setup, and check that the Redirect module is configured sensibly. Pathauto can create redirects when aliases change, but a large bulk operation can generate many records. Review database growth, redirect chains and canonical URLs after a substantial update.
Do not build redirects that point to another redirect. A page should ideally travel directly from its old URL to its current canonical URL. This is important during a rebrand, domain move or platform migration, when several historical URL formats may exist. A careful migration spreadsheet containing old paths, new paths, status codes and destination pages can prevent omissions.
For organisations coordinating a wider rebuild, engineering support can be useful when URL rules need to align with hosting, integrations or a broader platform migration. The Drupal configuration should still remain documented in the project repository so future developers can understand why each pattern exists.
After publishing changes, test representative aliases manually and crawl the site with an SEO auditing tool. Check internal links, XML sitemaps, canonical tags and Google Search Console coverage. A rise in “Page not found” reports after a pattern change usually indicates that redirects or internal references need attention.
Handling multilingual and localised websites
Multilingual Drupal sites require extra planning because a translated page may have a different title and a different alias. Decide whether the language should appear in the path, such as /en/services/... and /fr/services/..., or whether language negotiation will keep paths separate without a visible prefix.
Use language-aware tokens and test aliases for every enabled language. A translated title can produce a valid localised URL, but transliteration and reserved characters should be checked carefully. Avoid manually creating English aliases for translated content unless the editorial policy clearly requires it.
Australian sites often serve a wide geographic area from one domain. A national retailer may need pages for Adelaide, Canberra and Darwin, while a local clinic may target only nearby suburbs. Location paths can support that structure, but each page should contain genuinely useful local information rather than a repeated template with a suburb name swapped in.
Keep suburb and city naming consistent with the site’s content model. “Melbourne CBD”, “Melbourne City” and “Melbourne” may describe overlapping areas but should not be mixed casually in aliases. Confirm how addresses, state abbreviations and locality names are represented before generating thousands of URLs.
Auditing Pathauto for ongoing SEO health
Pathauto configuration should be treated as part of the website’s operating procedure. Document each pattern, its intended content type, the tokens it uses and the action taken when an alias changes. This makes handover easier when a Drupal developer or content editor joins the project.
Review URL reports periodically. Look for duplicate aliases, numeric suffixes, uppercase letters, overly long paths, encoded characters and unnecessary query strings. Drupal’s URL alias administration screen can help locate individual problems, while command-line tools and database queries are useful for larger sites.
Editors should understand which title fields affect the public URL. A headline change made for style can also change a page address if Pathauto is configured to update aliases. For established pages, it may be better to retain the current alias and edit the page title without regenerating the path.
Finally, validate the result with real user journeys. Open a news article from an internal link, follow a service page from a location page, and test old URLs after a content update. For an Australian site, include examples from metropolitan and regional pages, such as Sydney services, regional Queensland resources and Western Australian contact pages. A technically valid pattern is successful only when it remains understandable, stable and useful as the site grows.