URLs & Web Fundamentals
What is a URL path?
A URL path is the component of a URL that identifies the specific resource being requested within a domain, the sequence of forward-slash-separated segments that follow the domain name and precede any query string or fragment. In https://example.com/products/widgets/blue-widget the path is /products/widgets/blue-widget: the three-segment sequence that locates the specific page within the site’s content hierarchy.
The path is the primary addressing component of the URL, it tells the server which specific resource the client is requesting from among all the resources hosted on the domain. The domain, example.com: identifies which server to connect to. The path, /products/widgets/blue-widget: identifies which specific resource on that server to return.
Every web page, API endpoint, image, document, and other resource accessible on a domain has a path, even the homepage has a path, which is the root path / representing the root resource of the domain. The path structure across all resources on a site constitutes its URL architecture, the system of paths that organises the site’s content into a navigable hierarchy.
URL paths matter for SEO because they communicate content hierarchy and topic relevance directly. They matter for redirect management because path changes, one of the most common URL changes, create redirect requirements for every URL affected. Understanding URL paths precisely, what they are, how they are structured, and how changes propagate, is foundational to managing redirects correctly.
URL path structure
The URL path has a defined structure, segments separated by forward slashes that create a hierarchical addressing system.
The root path: /: the single forward slash representing the root of the domain’s resource hierarchy. A request for https://example.com/: or https://example.com: requests the root path. The server responds with the root resource, typically the site’s homepage. The root path is always present even when omitted, example.com and example.com/ request the same root resource.
Path segments: the components between forward slashes. In /products/widgets/blue-widget there are three path segments, products, widgets, and blue-widget. Each segment represents one level of the hierarchy, products is a top-level category, widgets is a subcategory, and blue-widget is a specific item within the subcategory.
Path segments can contain letters, numbers, hyphens, underscores, periods, and a small set of other characters. Spaces and special characters must be URL-encoded: replaced with percent-encoded sequences. Most modern web applications encode path segments automatically, but understanding encoding is important when constructing and matching paths in redirect rules.
Depth and hierarchy: the number of path segments determines the depth of the URL in the site’s hierarchy. /page is one level deep. /category/page is two levels deep. /section/category/subcategory/page is four levels deep. URL depth affects both user experience, deeper paths feel more buried, and internal PageRank distribution, pages deeper in the hierarchy receive less equity from the homepage than shallower pages.
The distinction from query strings and fragments: the path ends at the first ? character, everything after is the query string. The path also ends at the first # character, everything after is the fragment. In https://example.com/products?sort=price#top the path is /products, the query string is sort=price, and the fragment is top.
URL paths and content organisation
URL paths reflect and reinforce the site’s content organisation, they are the visible expression of the site’s information architecture.
Hierarchical content organisation: well-designed URL paths mirror the logical hierarchy of content. A site selling clothing might have paths like /clothing/mens/jackets/waterproof-jackets: four levels communicating product category hierarchy, or /blog/seo/redirect-management-guide: three levels communicating content type, topic, and specific piece.
The hierarchy in the path communicates relationships, /clothing/mens/jackets tells search engines and users that jackets are a type of mens clothing. Internal PageRank flows through internal links from parent paths to child paths, /clothing receives internal links from the homepage and distributes authority to /clothing/mens which distributes to /clothing/mens/jackets and so on.
Flat vs deep path structures: the choice between flat paths, all pages at one or two levels deep, and deep paths, pages at four or five levels deep, affects both SEO and user experience. Flat structures make authority distribution more efficient, every page is close to the homepage, but provide less hierarchical context. Deep structures communicate rich hierarchy but may bury important pages too far from high-authority entry points.
Subdirectory vs subdomain paths: content can be organised either through subdirectory paths, example.com/blog/: or subdomains, blog.example.com/. From a path perspective subdirectory content has paths within the main domain, /blog/article-title: while subdomain content has paths within the subdomain’s own namespace. The SEO implications of subdirectory versus subdomain organisation, particularly for authority consolidation, make this an important architectural decision.
URL paths and SEO
URL paths contribute to SEO through several specific mechanisms.
Path segment keyword signals: keywords in path segments contribute minor relevance signals for queries containing those terms. A page at /redirect-management-guide has a URL-level keyword signal for queries about redirect management. The signal is modest but real, it reinforces the page’s topical focus alongside content quality and backlink signals.
Path-level keyword signals are cumulative across segments. /blog/seo/redirect-management-guide has keyword signals from all three segments, blog signals content type, seo signals topic category, redirect-management-guide signals specific content. The combination provides richer topical context than a single-segment path.
Breadcrumb generation from paths: search engines often generate breadcrumb navigation in search results based on URL path structure. A result for /clothing/mens/jackets may display Clothing > Mens > Jackets as a breadcrumb in the search result, helping users understand where the page sits in the site hierarchy and increasing click-through rate. Well-structured paths that reflect the content hierarchy generate more useful breadcrumbs.
Crawl budget implications of path depth: pages at deeper paths receive less frequent crawling than shallow pages. The homepage at / is crawled very frequently. Pages at /section/category/subcategory/page may be crawled infrequently, particularly on sites with limited crawl budget. Deep paths for important content can lead to indexation delays and stale indexed content. Keeping important content at shallower paths improves crawl frequency and indexation freshness.
Path-based duplicate content: URL paths create duplicate content risks through case sensitivity and trailing slash variants. /products/blue-widget, /Products/Blue-Widget, /products/blue-widget/: three technically distinct paths that may serve identical content. Consistent lowercase paths and consistent trailing slash handling with appropriate redirects and canonical tags eliminate path-based duplicates.
URL path changes and redirects
Path changes are among the most frequent redirect triggers, any change to a URL’s path creates a redirect requirement for every affected URL.
Individual path changes: a single page’s path changes, typically through a URL slug update. /blog/old-article-title changes to /blog/new-article-title. The redirect requirement is a single 301 permanent redirect from the old path to the new path. Simple to configure, source is the old full path, destination is the new full path.
Category path changes cascading to child pages: when a path segment that is a parent of many child pages changes all child page paths change simultaneously. /old-category/page-1, /old-category/page-2, /old-category/page-3: all change to /new-category/page-1 etc when the category segment changes. A single wildcard redirect rule, /old-category/* → /new-category/*: handles the entire category with one rule.
Platform migrations with path structure changes: migrating from one CMS to another often changes path patterns. WordPress paths, /blog/2024/01/article-title: may not match the new platform’s path format, /blog/article-title. Every old path must be mapped to its new equivalent, either through pattern-based wildcard redirect rules if the transformation follows a consistent pattern or through individual URL mapping if paths have been individually reorganised.
Subdirectory to subdomain migrations: moving content from a subdirectory path, example.com/blog/: to a subdomain, blog.example.com/: requires redirects from all old subdirectory paths to their subdomain equivalents. /blog/article-title redirects to blog.example.com/article-title. The redirect crosses both path and domain boundaries, requiring the full absolute URL in the redirect destination including the subdomain authority.
Subdomain to subdirectory migrations: the reverse, moving from subdomain to subdirectory, requires redirects from subdomain URLs to subdirectory paths. blog.example.com/article-title redirects to example.com/blog/article-title. This migration direction is common when consolidating authority, moving content from a subdomain into the main domain’s subdirectory to benefit from the main domain’s authority.
Path-based redirect patterns
Several redirect patterns are specifically path-based, they operate on path components to implement common redirect scenarios.
Path preservation redirects: the simplest and most common domain migration redirect pattern. When only the domain changes and all paths remain the same a path-preserving redirect carries the full path through to the new domain. old-domain.com/any/path redirects to new-domain.com/any/path: the path is preserved exactly. Implemented as a wildcard rule, old-domain.com/* → new-domain.com/*: one rule handles the entire domain.
Path transformation redirects: when paths change as part of a migration, removing date segments, adding category prefixes, restructuring hierarchy, the redirect rule must transform the old path into the new path. Pattern-based redirect rules using regular expressions can extract path components and reassemble them in the new format.
A regex-based rule removing date segments from blog paths, /blog/2024/01/15/article-title to /blog/article-title:
The regex captures the article slug after the date segments and reconstructs the path without the date.
Path prefix additions and removals: adding or removing prefixes from paths. /products/item becoming /shop/products/item: adding a /shop prefix. /old-section/category/page becoming /category/page: removing the /old-section prefix. Pattern-based rules handle these transformations efficiently.
Fallback redirects for unmatched paths: a catch-all redirect rule that handles any path not matched by more specific rules. When specific path-level redirects exist for high-value pages and a wildcard handles common patterns a fallback catches edge cases, sending visitors to the most relevant section or homepage rather than returning 404 errors for unmapped paths.
Checking and debugging path-based redirects
Verifying that path-based redirects are correctly configured requires testing specific paths and verifying redirect behaviour.
curl for path redirect testing: testing redirect responses for specific paths from the command line:
Returns the HTTP response headers including the status code and Location header, confirming whether the path is redirecting correctly and where it is redirecting to.
Testing path variants: when verifying path redirects test multiple variants of each path. The path with and without trailing slash, /products/item and /products/item/. The path in lowercase and mixed case, /products/item and /Products/Item. With and without query strings, /products/item and /products/item?sort=price. Each variant should redirect to the canonical destination in a single hop.
Crawl tool path audit: crawling tools like Screaming Frog simulate how search engines follow paths, reporting the response code and redirect chain for every discovered URL. Exporting the crawl results and filtering for non-200 responses identifies paths returning 404 errors or unexpected responses. Filtering for redirect responses identifies chains, paths that redirect through multiple hops before reaching a 200 response.
Google Search Console path coverage: the Coverage report in Google Search Console shows which paths Googlebot has crawled and how they responded, indexed, redirected, 404, or other responses. Post-migration Coverage reports reveal which old paths Googlebot is still discovering through links and whether they are correctly redirecting to new canonical paths.