What a URL is

A URL - Uniform Resource Locator - is the address of a resource on the web. It does two jobs in one string: it names which resource you mean, and it tells the software how to reach it. That second job is what makes it a locator rather than just a name - a URL is a set of fetch instructions compact enough to print on a poster.

The reason it deserves an article: every tool in the search series reads URLs, and each reads a different part. Browsers fetch them, crawlers collect them, robots.txt rules match against pieces of them, analytics mines their tails. The five named parts below are the shared vocabulary - learn them once and the rest of the series never has to explain them again.

The anatomy at a glance

A full URL, taken apart. Most URLs you meet use only some of these parts - the scheme, host, and path are the everyday core; query and fragment are optional extras.

https://example.com:443/paths/web/launch?theme=dark#anatomy
└─┬──┘  └────┬─────┘└┬┘ └──────┬───────┘└────┬────┘└───┬───┘
scheme      host    port      path         query   fragment

Reading order matters: everything up to the first / after the host says where to go; everything after it says what to ask for once you get there. The sections below take the parts one at a time.

Scheme

The part before :// names the protocol - the language the client should speak to fetch the resource. On the web that is https (encrypted HTTP) or, increasingly rarely, plain http. Other schemes route to entirely different machinery: mailto: opens a mail client, file: reads from the local disk.

The practical rule in 2026 is short: everything public is https. Browsers mark plain http pages as not secure, and search engines treat HTTPS as the baseline - one of the quality signals from SEO basics.

Host and port

The host names the server: example.com. Read it right to left - com is the top-level domain, example is the registered domain, and anything further left (blog.example.com) is a subdomain the owner carved out. The translation from name to a network address is DNS's job - one lookup, before any page is fetched.

The port after the colon picks which door on that server. You almost never see it because each scheme has a default - 443 for https, 80 for http - and browsers omit the default. It shows up mostly in local development: localhost:5173 is your machine, door 5173 - the one Vite's dev server answers on.

One boundary worth knowing: the scheme, host, and port together form the origin - the unit browsers use for security decisions about what a page's code may read. Two URLs with different origins are strangers to each other, however similar they look.

Path

The part after the host, starting with /, identifies the resource within the site: /paths/web/launch. It reads like a folder structure, and historically it was one - early servers mapped paths straight onto directories of files. Modern sites route paths however they like, but the hierarchy convention stuck because humans and crawlers both read it well.

The path is the part of the URL that robots.txt rules match against - Disallow: /admin/ from robots.txt and sitemaps is a path prefix, nothing more. It is also where "clean URL" conventions live: /launch instead of /launch.html, a purely cosmetic choice the server resolves either way.

Query string

The part after ? carries extra data as key=value pairs, separated by &:

/search?q=inverted+index&page=2

What the server does with it is entirely up to the server - a search page reads q as the query, a store reads page for pagination. And some parameters are not for the server at all: the utm_ tags from What is UTM? ride in the query string purely so the analytics script on the landing page can read them. Same slot, different reader.

The tradeoff the query string carries: it makes one page addressable in many ways, which is exactly what a crawler does not want - /launch and /launch?utm_source=x look like two pages. That duplicate problem, and the canonical-tag fix, is covered in the UTM article.

Fragment

The part after # points within the resource: #anatomy scrolls to the element with that id on this very page - the table-of-contents links in the sidebar are fragments at work.

The defining quirk: the fragment is never sent to the server. The browser strips it before making the request and handles it alone after the page loads. That makes it invisible to server logs, to crawlers fetching the page, and to anything else that only sees the request - it belongs entirely to the client.

Special characters

URLs allow a limited character set, and some characters have jobs - ?, &, #, / all mean something structural. Anything else, including spaces, gets percent-encoded: the character's byte value written as % plus two hex digits. A space becomes %20, so spring launch travels as spring%20launch.

This is why naming conventions in What is UTM? say underscores instead of spaces - not because spaces break, but because %20 is what your reports will show if you use them. When you build URLs in code, let the platform do the escaping - in JavaScript, the URL object assembles and encodes the parts correctly instead of you concatenating strings.

One URL, three readers

The same string is read three ways, and the search series is really the story of those readers:

  • The browser reads all of it - scheme and host to connect, path and query to request, fragment to scroll.
  • The crawler from how internet search works reads scheme, host, and path to fetch and identify pages, checks the path against robots.txt, and treats query variants as distinct URLs unless told otherwise.
  • Analytics ignores most of the URL and mines the query string for utm_ tags, crediting the visit to its origin.

Five parts, three readers, one line of text. Every other article in the series leans on this vocabulary - now it is yours.

References