When you are preparing pages for a small project website, keeping track of each page's name, full address, and purpose can quickly become confusing. A simple written checklist helps you stay organized and makes it easier to communicate your plan to collaborators or to your future self.
What a Domain Name Answers and What a Full URL Answers
Suppose you are planning a small personal project and you sketch out a page address like https://example.org/notes/first-page?view=compact#intro. This address is entirely hypothetical and is used here only to practice reading its parts; it does not point to a real page. Before you can record this address usefully, it helps to understand two different questions it answers at different levels.
A domain name provides a human-readable address for a web server available on the internet. In our example, example.org is the domain name. It tells you which server or site you are trying to reach. Domain names exist because the numeric IP addresses that computers use internally are difficult for people to remember and may change over time.1
A full URL goes further. A URL is the address of a unique resource on the internet and is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. Where the domain name answers "which site?", the full URL answers "which specific resource on that site, and under what conditions?" Our example address includes not just the domain but also a path, a query string, and a fragment, each adding a layer of specificity.2
Reading the Example Address Part by Part
Let us walk through the hypothetical address from left to right. The first part, https, is the scheme. It indicates the protocol the browser must use to request the resource. For websites, the protocol is usually HTTPS or its unsecured version HTTP.2
After the scheme comes the authority, separated by the character pattern ://. In our example the authority is simply example.org, which is the domain name indicating which web server is being requested. A port number could also appear here, but it is usually omitted when the server uses standard ports.2
The path in our example is /notes/first-page. It represents the location of the resource on the web server. In the early days of the web a path like this represented a physical file location, but nowadays it is mostly an abstraction handled by web servers without any physical reality.2
Query Strings and Fragments in the Example
After the path, a question mark introduces the query string. In our example the query is view=compact. Query parameters are extra key-value pairs provided to the web server, and the server can use them to do additional processing before returning the resource. Each web server has its own rules regarding parameters, so you cannot assume what a particular parameter does just by reading the string.2
Finally, the hash symbol introduces the fragment. In our example the fragment is intro. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. It is worth noting that the part after the hash, also known as the fragment identifier, is never sent to the server with the request.2
When you record this address on your checklist, marking where the question mark and the hash symbol fall helps you see at a glance which part is the query and which part is the fragment. This distinction matters because the query is sent to the server while the fragment is not, and confusing the two can lead to misunderstandings when you share the address with someone else.2
Comparing Strings with the Same Host
Now keep the scheme and host exactly the same and change only the path. Compare https://example.org/notes/first-page?view=compact#intro with https://example.org/notes/second-page?view=compact#intro. The only difference in the string is first-page versus second-page in the path. From the string alone you can observe that these two addresses point to different resources on the same server, but you cannot determine from the string what those resources contain or how the server handles them.2
Next, keep the path the same and change the query. Compare https://example.org/notes/first-page?view=compact#intro with https://example.org/notes/first-page?view=full#intro. Here only the value after the equals sign differs. Again, you can note the difference in the string, but you should not infer what the server actually does with view=compact versus view=full without checking with the server owner or its documentation.2
This exercise is about reading and comparing strings, not about predicting behavior. When you build your checklist, recording these variations side by side makes it easy to spot which part changed and which stayed the same. That habit is especially useful when a project grows beyond a handful of pages and you need to hand off address information to a collaborator.
Building an Address Description Card
Record a short description card for each page in your hypothetical project. A useful card has three fields: the purpose of the page in plain language, the full address, and a labeled breakdown of each part. For our example, the purpose might be "first notes page displayed in compact view, scrolled to the introduction section." The full address is the complete string. The breakdown lists scheme, host, path, query, and fragment separately.
Write the purpose in your own words rather than copying the path or query values. The purpose field is for humans who need to understand what the page is for without parsing the address character by character. If you later rename the page or adjust the query, you can update the address fields while keeping the purpose description stable as a reference.
This card format is a suggestion, not a rule from any specification. You can adapt it to whatever tool you use for notes, whether that is a plain text file, a spreadsheet, or a project management board. The key is that each card ties together a human-readable purpose and a machine-readable address in one place, so you do not have to reconstruct the connection from memory later.
Verifying the Card by Hand
Copy the full address from your description card into a blank line and mark each boundary by hand. Place a slash or a space at every point where one part ends and the next begins: after the scheme, after the host, after each path segment, before the question mark, and before the hash. This manual step catches missing characters or misplaced punctuation that are easy to overlook when you only glance at the string.
Check each labeled part against the card one at a time. Confirm that the scheme matches, that the host is spelled the same way, that the path segments appear in the right order, and that the query key and value are identical. If any part differs, correct the card before moving on. This is ordinary proofreading, not a technical test of whether the address works.
Use the same verification pass when you add a new page to the checklist. Copying an existing card as a template is convenient, but it also invites copy-paste errors where a path segment or query value from the old card slips into the new one. A quick item-by-item comparison takes only a moment and prevents those small mistakes from accumulating across a growing list.
Frequently asked questions
Why should I record the full URL instead of just the page name?
A page name alone does not tell a collaborator or your future self how to reach the page. The full URL includes the scheme, host, path, query, and fragment, which together specify the exact resource. Recording it once saves you from reconstructing it later.2
Does the fragment part of a URL affect what the server returns?
No. The fragment identifier, which is the part after the hash symbol, is never sent to the server with the request. It only tells the browser where to scroll or jump within the already-loaded resource.2
Can I tell what a query parameter does just by reading the URL string?
Not reliably. Each web server has its own rules for handling parameters. You can observe what the string says, but to know what the server actually does with a given parameter you need to check the server's documentation or ask its owner.2