When you prepare a small website for the first time, keeping track of each page's name and its full address can feel overwhelming. This article uses one clearly hypothetical address to show how a simple recording habit helps you stay organized from the very start.
What a Domain Name and a Full URL Each Tell You
Suppose you are planning a small personal project and you sketch out a page you want to call “first-page.” To reach that page in a browser, you would need more than just the page name. You would need a complete address that tells the browser exactly where to look. A domain name identifies which web server you are asking, while a full URL goes further by pointing to a specific resource on that server. MDN describes a URL as the address of a unique resource on the internet and one of the key mechanisms browsers use to retrieve published resources such as HTML pages, CSS documents, and images.1
Think of the domain name as the building and the full URL as the complete mailing address that includes the building, the floor, and even the apartment number. A link on the web is simply a text string tied to a URL, and it allows a reader to jump from one document to another by activating that link. So when you record a page for your project, you are really recording the destination that a link will point to.12
For this article, the hypothetical address we will use throughout is https://example.org/notes/first-page?view=compact#intro. This page does not exist and has never been published anywhere. It is a constructed string chosen only so we can practice reading and labeling each part of a URL together.
Labeling Every Part of the Example Address
Look at the hypothetical address piece by piece. The scheme is https, which tells the browser which protocol to use when requesting the resource. MDN notes that for websites the protocol is usually HTTPS or its unsecured version HTTP, and the scheme is always the first part of a URL.1
After the scheme comes the authority, separated by the characters colon-slash-slash. In our example the domain portion is example.org. The domain indicates which web server is being requested. There is no port shown here because standard ports are usually omitted when the server uses the default port for HTTPS.1
The path in our example is /notes/first-page. MDN explains that the path represents the resource location on the web server, and that in modern practice it is mostly an abstraction handled by web servers rather than a physical file location. After the path comes a question mark, which introduces the query string. In this case the query is view=compact, a key-value pair that provides extra parameters to the server. Finally, the hash symbol introduces the fragment identifier, which here is intro. MDN notes that the fragment acts as a sort of bookmark inside the resource and is never sent to the server with the request.1
Comparing Different Paths and Queries Under the Same Host
Now keep the scheme and domain exactly as they are and imagine two variations. The first changes only the path to /notes/second-page, and the second changes only the query to view=full. In both cases the browser still contacts the same server identified by example.org, but the string after the domain differs. This observation comes from simply reading the address structure; it does not tell us what the server would actually return in response.
The path portion is what distinguishes one page from another on the same host. If your project has five pages, each one would share the same domain but carry a different path. The query string, on the other hand, can modify how a single page is displayed or processed without changing which page you are asking for. The fragment identifier sits at the very end and points to a location within the page itself, so two links that differ only in their fragment still refer to the same document.
Recording these distinctions in your checklist helps you avoid confusion later. When a collaborator asks which page you mean, you can point to the path. When they ask about a specific display mode, you can point to the query. When they ask about a section within the page, you can point to the fragment. Each part answers a different question.
Building an Address Description Card for Your Hypothetical Project
Record the following fields on a card or in a simple text file for each page in your project. The first field is the page name, which is a short human-readable label you choose yourself, such as “First Page.” The second field is the full address, written out completely including scheme, domain, path, query, and fragment if present. The third field is a brief note explaining the purpose of the page, for example “Introduction section of the notes area.”
For our hypothetical example the card would look like this. Page name: First Page. Full address: https://example.org/notes/first-page?view=compact#intro. Purpose note: A compact view of the introductory notes section. You might also add a fourth field for the date you recorded the entry, so you can track when information was last reviewed.
The value of this card is not in any single field but in having them together. When you hand off the project to a collaborator, or when you return to it after a break, the card gives you a quick reference without requiring you to re-derive the address from memory. Keep the card in whatever format is easiest for you to maintain, whether that is a plain text file, a spreadsheet row, or a note-taking application.
Verifying Your Card by Copying and Labeling
Check the full address on your card by copying it character by character from the browser address bar or from your planning document. Paste it into a fresh line in your text file and compare it against the card entry. If any character differs, correct the card before moving on. This manual copy step catches mistakes that are easy to overlook when you rely on memory alone.
Write a label under each segment of the pasted address. Mark the scheme, then the domain, then the path, then the query string if present, and finally the fragment if present. Use simple labels like “scheme,” “domain,” “path,” “query,” and “fragment.” This exercise confirms that you understand what each part represents and that your card reflects the actual structure.
Repeat this process for every page in your project. If your project has only two or three pages, the task takes just a few minutes. If it grows larger, the upfront effort of labeling each address saves time when you later need to explain your site structure to someone else or troubleshoot a broken link.
Step 1
Copy the full address from your source into a blank line in your text file.
Step 2
Compare the pasted string against your card entry and correct any mismatch.
Step 3
Write a label beneath each segment identifying it as scheme, domain, path, query, or fragment.
Keeping Your Record for Future Writing and Communication
Store your completed cards in a location you will actually revisit. A folder in your project directory, a dedicated note, or a shared document all work as long as you can find them quickly. The goal is not perfection but availability. A card you can locate in ten seconds is far more useful than a perfectly formatted spreadsheet you never open.
Use the cards as a reference whenever you write content that links to another page in your project. When you draft a navigation menu or an internal link, open the card for the target page and copy the full address from there rather than typing it from memory. This habit reduces the chance of introducing a typo into a path or query string.
Over time your choices about what to record may evolve. You might decide to add a field for the page's intended audience, or you might drop the fragment field if your project never uses in-page anchors. That flexibility is part of the value. The checklist serves your project, not the other way around. Start simple, keep what proves useful, and adjust the format as your needs become clearer.
Frequently asked questions
Do I need to include the fragment identifier in my address card?
Only if your page uses in-page anchors. If the page has no fragment-based navigation, you can leave that field blank or omit it entirely. The fragment points to a spot within a document and is never sent to the server, so it only matters when you want to link to a specific section.1
What is the difference between the path and the query string in a URL?
The path identifies which resource on the server you are requesting, while the query string provides extra key-value parameters that can modify how that resource is returned or displayed. They serve different roles: the path selects the page, and the query adjusts its behavior or presentation.1
Should I record relative addresses or full addresses on my card?
For a handoff checklist, full addresses are clearer because they are self-contained and do not depend on the reader already knowing the domain. Relative addresses are useful within HTML documents where the browser can fill in missing parts, but for communication between people a complete URL avoids ambiguity.1