A URL, Uniform Resource Locator, is the complete address used to identify and locate a specific resource on the internet. Every web page, image, document, video, API endpoint, and any other accessible resource on the web has a URL, the unique address that browsers, applications, and other clients use to request that specific resource from the server that hosts it.

The URL https://example.com/products/blue-widget?colour=blue#specifications is a complete URL, it contains every component needed to precisely identify a resource, specify how to connect to the server that hosts it, and indicate exactly what resource is being requested and what portion of it is relevant.

URLs are the fundamental addressing system of the World Wide Web, the mechanism that makes the web navigable by providing stable, shareable, linkable addresses for resources. Every hyperlink is a URL. Every browser navigation is driven by a URL. Every DNS lookup resolves a URL’s domain to a server address. Every HTTP request is a request for a specific URL’s content. Every redirect is a mapping from one URL to another.

For redirect management URLs are the fundamental unit of operation, redirect rules specify source URLs and destination URLs, SEO equity accumulates at specific URLs, canonical tags designate specific URLs as preferred, and backlinks point to specific URLs. Understanding URLs at a precise technical level is foundational to understanding how redirect management works and why specific redirect configurations preserve or lose equity.

URL structure, the components

A complete URL is composed of up to six distinct components, each serving a specific technical purpose in identifying and locating a resource.

Scheme, the protocol: the first component, followed by ://. Specifies the protocol used to communicate with the server. https for secure encrypted connections, the standard for modern web pages. http for unencrypted connections. ftp for file transfer protocol. mailto for email addresses. For web resources HTTPS is the standard and expected scheme, browsers flag http URLs as not secure.

The scheme is a required component, a URL without a scheme is incomplete. example.com/page is not a valid URL, https://example.com/page is. In web content relative URLs, /page or ../page: omit the scheme and domain because they are resolved relative to the current page’s URL, the browser supplies the missing scheme and domain.

Authority, the server address: the component following :// that identifies the server hosting the resource. The authority typically consists of the domain name, example.com: and optionally a port number, example.com:8080. The domain is resolved through DNS to an IP address, the network address the browser connects to. When no port is specified the default port for the scheme is used, port 443 for HTTPS, port 80 for HTTP.

The authority component may also include a username and password for authenticated resources, username:password@example.com: though this form is rarely used in web URLs due to security concerns.

Path, the resource location: the component following the authority, beginning with /. Identifies the specific resource being requested on the server. /products/widgets/blue-widget: a path with three segments identifying a specific product page. The path communicates the resource’s location within the server’s content organisation, it corresponds to the URL structure decisions discussed in the URL structure article.

The path can be empty, https://example.com: representing the root resource of the domain, or deeply nested, https://example.com/section/category/subcategory/page: representing a specific resource within a hierarchical structure.

Query string, parameters: the optional component following a ? character. Contains key-value pairs separated by &: ?sort=price&colour=blue&page=2. Query strings provide additional parameters that modify the resource request, specifying sorting, filtering, tracking, pagination, and many other variable behaviours without changing the base resource path.

Query strings create URL variants, example.com/products?sort=price and example.com/products?sort=name are technically different URLs even when they serve near-identical content. Managing query string variants is one of the primary duplicate content and crawl budget challenges in technical SEO.

Fragment, the page anchor: the optional component following a # character. Identifies a specific section within the page, #specifications scrolls the page to the element with the ID specifications. Fragments are processed entirely by the browser, they are not sent to the server in the HTTP request. Search engines generally ignore fragments when indexing URLs, example.com/page#section-1 and example.com/page#section-2 are treated as the same URL for indexing purposes.

Port: an optional numeric component following the domain separated by :. example.com:8080 specifies that the server should be connected on port 8080 rather than the default port. Ports are rarely visible in production web URLs, default ports, 443 for HTTPS, 80 for HTTP, are implicit and omitted. Non-standard ports appear in development and testing environments.

Absolute vs relative URLs

URLs appear in two forms in web content, absolute and relative, each appropriate for different contexts.

Absolute URLs: complete URLs including scheme, authority, and path. https://example.com/products/blue-widget is an absolute URL, it contains all information needed to locate the resource regardless of context. Absolute URLs work in any context, they can be shared, typed into browsers, included in emails, and used in any document without needing context to resolve.

Absolute URLs are required in canonical tags: <link rel="canonical" href="https://example.com/page">: because canonical tags must specify the exact canonical URL unambiguously. Relative URLs in canonical tags could be misinterpreted if the page is accessed through different URL variants.

Absolute URLs are required in XML sitemaps: sitemaps must contain complete absolute URLs for each listed resource.

Absolute URLs in internal links add redirect hop overhead if the URL needs updating, when a page moves all internal links containing absolute URLs to that page must be updated. Relative URLs update automatically when the page structure changes.

Relative URLs: URLs that omit the scheme and authority, relying on the current page’s context to supply the missing components.

Root-relative URLs beginning with /: /products/blue-widget: resolve relative to the domain root. A page at https://example.com/blog/post containing a link to /products/blue-widget resolves the link to https://example.com/products/blue-widget.

Document-relative URLs, ../products/blue-widget: resolve relative to the current document’s location. These are less common in web applications than root-relative URLs because the resolution depends on the current document’s path, which can lead to resolution errors when content is moved.

Protocol-relative URLs, //example.com/page: omit the scheme and inherit the current page’s protocol. A page served over HTTPS resolves a protocol-relative URL as HTTPS. Protocol-relative URLs were historically useful for resources available over both HTTP and HTTPS, now that HTTPS is standard they are less necessary.

URLs and HTTP

The URL is the addressing component of HTTP: the protocol through which browsers request web resources. Understanding how URLs are processed in HTTP requests clarifies the mechanics of redirect management.

The HTTP request: when a browser navigates to a URL it sends an HTTP request to the server. The request includes the method, GET, POST, etc., the path and query string from the URL, the scheme and authority determine which server to connect to, not what to include in the request itself, and headers including the Host header that specifies the domain.

For https://example.com/products/blue-widget?colour=blue the browser:

1. Resolves example.com to an IP address through DNS

2. Connects to that IP address on port 443 over TLS

3. Sends an HTTP GET request for /products/blue-widget?colour=blue with Host: example.com

4. Receives the HTTP response — content or redirect

The host header and virtual hosting: web servers hosting multiple domains use the Host header to determine which site to serve. The URL https://example.com/page and https://other-domain.com/page may both resolve to the same server IP address, the Host header, example.com or other-domain.com: tells the server which site’s content to return. SNI in TLS performs the same function at the SSL layer, before the HTTP request is received.

This virtual hosting mechanism is how redirect management platforms serve content for many connected domains from shared infrastructure, the Host header identifies which domain’s redirect rules to apply to each incoming request.

URLs and redirects

Every redirect is fundamentally a URL mapping, a rule that specifies a source URL and a destination URL with an instruction about the nature of the redirect.

Source URL: the URL that triggers the redirect. A user who requests the source URL receives a redirect response rather than content. The source URL may be a specific URL, https://old-domain.com/specific-page: or a URL pattern, https://old-domain.com/* matching any URL on the old domain.

Destination URL: the URL the browser is directed to after receiving the redirect response. The destination must be a complete absolute URL, including scheme, authority, and path, to avoid ambiguity. The destination URL should be the canonical form of the target resource, HTTPS, consistent trailing slash convention, without unnecessary parameters.

The Location header: the HTTP mechanism for specifying the redirect destination. When a server returns a 3xx status code it includes a Location header specifying the destination URL. The browser reads the Location header and makes a new request to the destination URL.

URL identity and equity: SEO equity accumulates at specific URLs, not at domains or paths in the abstract but at the precise URL including scheme, subdomain, path, and canonical handling of parameters and trailing slashes. A backlink to http://example.com/page and a backlink to https://example.com/page/ are backlinks to technically different URLs, redirect management must handle all variants to consolidate equity at the canonical URL.

URL best practices

Canonical URL definition: every resource should have exactly one canonical URL, the single address that is the definitive, preferred location for that resource. All other URL variants, different schemes, different subdomains, different parameter combinations, should either redirect to the canonical or have canonical tags pointing to it. Defining and enforcing canonical URLs is the foundational URL management practice.

URL stability: URLs should be as stable as possible, changed only when the benefit clearly outweighs the redirect overhead and disruption. A URL changed unnecessarily requires redirect configuration, loses some equity in the redirect, and potentially disrupts backlinks and bookmarks. Design URLs for stability from the start, choosing patterns that do not need to change as the site evolves.

Consistent URL formation: every element of URL formation should be consistent, protocol, subdomain, trailing slash convention, case convention, word separator convention. Inconsistency creates variant URLs that require management. Establishing and enforcing URL formation standards, in CMS settings, in server configuration, in development guidelines, prevents inconsistency from accumulating.

URL length: while there is no hard URL length limit that causes SEO problems long URLs are harder to share, more likely to break in some contexts, and less readable. Paths should be as concise as possible while remaining descriptive, omitting unnecessary words, avoiding deeply nested hierarchies, and keeping slugs focused on the most important descriptive terms.

URL encoding

URLs can only contain certain characters, letters, numbers, and a small set of special characters. Characters outside this set, spaces, accented characters, non-ASCII characters, and others, must be URL-encoded, replaced with a percent sign followed by the hexadecimal code for the character.

A space is encoded as %20: example.com/page%20name. An accented é is encoded as %C3%A9. Encoding ensures URLs can be transmitted correctly in HTTP without ambiguity.

Modern browsers handle URL encoding transparently, a user who types example.com/page name in a browser address bar sees the URL auto-encoded to example.com/page%20name. URLs in HTML are often written in decoded form and the browser encodes them on use.

For SEO and redirect management URL encoding creates potential variant issues, example.com/page%20name and example.com/page name may be treated as different URLs by some systems. URL encoding normalisation, consistently using encoded or decoded forms throughout the site, prevents encoding variant duplicate content.