Recording the Project Name, Candidate Domain and Registration Result Separately for a Small Business Service Site

This article addresses a common confusion for beginners: mixing up what you call your business, what you try to buy as a web address, and what actually gets registered. It uses a hypothetical example of a small service site to show why keeping these three items in separate notes prevents errors when checking availability or filling out forms.

Why Your Project Name Is Not Your Domain

This is a hypothetical example rather than a real business record. Imagine a reader planning a small site for hand-bound notebooks and letterpress cards. On the desk are three separate notes rather than one blended shopping list.

The first note holds project names: “Paper Loom Studio,” “Fold & Stitch Press,” and “Quiet Margin Books.” Each is a working title only, useful for describing the project to friends and for sketching a site heading. None has been checked against any business register, and the reader has not decided whether the eventual site is a personal portfolio or a shop.

The second note holds candidate domain strings: paperloom, foldandstitch, quietmargin. This is where the first unrelated question appears: a project name that reads smoothly aloud may be long to type, and a shorter string may not resemble the spoken name. The reader is weighing whether recognition matters more than brevity, and whether a word like “studio” or “press” should stay in the string at all.

The third note is still a blank column labelled registration result. It exists so that the reader does not later confuse a name they like with an address they attempted to obtain. Nothing on these notes has been submitted to a registrar, and no availability or outcome is known. The open choice is which candidate string to test first, and whether the accepted string must match the favourite project name exactly. Keeping the three notes apart makes that uncertainty visible instead of letting a favourite name quietly stand in for a verified web address.

Listing Candidate Domains Before You Check Availability

Before you type anything into a search box, you can draft a short candidate list on paper and keep it deliberately separate from your project names. Start with a spelling you would actually type and say aloud, then write two or three variants beside it. For the notebook example, a reader might try paperloom, paper-loom and paperloomstudio. Say each one aloud, read it once with letters grouped and once as a single run of characters, and note which ones invite a misreading. That note is for your own decision, not a verdict on what an address can contain.

Next, you can mark each candidate with a plain reason for keeping or dropping it. “Easy to spell after hearing it,” “too close to another word I might type by mistake,” “still reads clearly in lowercase.” These reasons help you compare candidates later without relying on memory. You might also record where a hyphen or a doubled letter would sit, so a later reader can see why one spelling felt safer than another.

When the list is ready, add a separate line under each candidate for the result of whatever availability guidance you consult, and leave it blank until then. Keeping the project name, the candidate spelling and the registration result in three places means a rejected spelling does not erase the name you began with. You can number the candidates and revisit them in the same order, which makes the comparison easier to explain to yourself a day later.

Recording the Actual Registration Result

Once a registrar has processed your details, MDN says the registrar will let you know when the domain name is properly registered, and that within a few hours all DNS servers will have received your DNS information. Record that result as the registrar states it, rather than treating a blank registration column as an outcome.¹

MDN also notes that in this process the registrar asks for your real-world address, and that in some countries registrars may be forced to close the domain if they cannot provide a valid address. Keep that requirement alongside the result note, since it shows the registration record depends on details you supplied.¹

For checking a name beforehand, MDN describes using a registrar's whois service or a whois command, with the example output showing a registered name and, for another name, NOT FOUND at the time of writing. That output is what MDN presents as availability information, so log it as the source's stated result rather than assuming a domain is secured.¹

Once the third note is ready, you can treat the registration result as a short, factual entry rather than a verdict on the project. Staying with the hypothetical notebook example: under quietmargin you might write “checked: taken,” and under foldandstitch “checked: offered, terms not reviewed.” Those are placeholders for what you observe, not promises. If you later query another candidate, you might add “checked: no result shown,” which is a distinct outcome from a clear refusal. You can record the date beside each line so that a note from one month is not mistaken for a current one.

How to Note Down the Full URL Structure

For the third note, record the full URL structure separately from the project name and the registration result. MDN describes a URL as the address of a unique resource on the internet and lists its main parts: the scheme, which indicates the protocol the browser must use, usually HTTPS or HTTP for websites; the authority, which includes the domain and an optional port; the path to the resource; parameters made of key/value pairs; and an anchor pointing to a place inside the resource. MDN notes that in a browser address bar you must provide a full, absolute URL, though the protocol can be omitted because the browser uses HTTP by default. When a URL appears inside a document, the browser can fill in missing parts from that document's own URL, which is how relative URLs work.²

After you register a candidate, you can rewrite the liked string as a full address and note each part on its own line. Staying with the hypothetical “paperloom” example: scheme https, host www.paperloom.example, path /notebooks, and no query. You might label each line scheme, host, path, query, so the address is never mistaken for the registered name alone.

You can then compare that draft with the registration note and leave any part you cannot yet confirm as a blank line rather than guessing. The choice of how much detail to keep is yours; the aim is a record you can read back later without blending the address, the name, and the result.

Keeping DNS Details Separate from Domain Names

MDN’s guidance treats availability checking and registration as two distinct steps: you go to a registrar’s website, where most offer a whois service that tells you whether a domain name is available. In a shell, you can instead type a whois command; MDN shows the query whois mozilla.org and an output listing details such as creation date and sponsoring registrar. MDN also shows querying afunkydomainname.org returning NOT FOUND, after which “we could ask to register it.”¹

MDN separates that availability result from the later registration record. Registration itself happens on a registrar’s website: you click the prominent “Get a domain name” call to action, fill out the form with all required details, and take particular care not to misspell the desired name, since once it is paid for it is too late. The registrar then lets you know when the domain name is properly registered.¹

DNS information follows registration rather than replacing it. MDN states that within a few hours all DNS servers will have received your DNS information, and explains that when a registrar creates or updates information for a domain, each DNS server that knows about the domain stores the information for some time before it is automatically invalidated and refreshed from an authoritative server.¹

After you have a registration note, you can give DNS details their own page rather than adding them to the same note. In the hypothetical “paperloom” case, that means listing the domain itself on one line and leaving the nameserver or DNS record entries for a separate sheet, so a later change to hosting settings does not overwrite what you recorded about the registration.

You might also date each DNS note and write what you changed in plain words, such as “nameservers switched after moving the site.” If you are unsure where a DNS value came from, you can leave it blank and add a question instead of copying a value you cannot trace.

Reviewing Your Notes Before Going Live

Before going live, take the three notes you have kept apart and read them side by side rather than folding them into one page. Start with the project-name note: read each working title aloud and mark any that you would now drop. In the hypothetical notebook case, you might decide “Quiet Margin Books” better fits the handmade, small-batch feel than “Paper Loom Studio,” and you can write one short line saying why. That line belongs only under the name it describes.

Then read the candidate-domain note against the same reason. A reader might notice that “paperloom” is easier to say after hearing it once, while “quietmargin” matches the chosen feel but may prompt spelling questions. You can mark each candidate as keep, hold, or drop, and note the reason in your own words; the choice of which reasons matter is yours.

Finally, compare the registration-result note with both. If a result line is still blank, leave it blank and write “not yet known” beside it rather than carrying an impression forward. You might add one dated line recording that you reviewed the three notes, so a later reader can see what was decided and what was merely hoped for.

Frequently asked questions

How can I start drafting a candidate list before typing anything into a search box?

Before you type anything into a search box, you can draft a short candidate list on paper and keep it deliberately separate from your project names. Start with a spelling you would actually type and say aloud, then write two or three variants beside it.

How should I mark each candidate with a reason for keeping or dropping it?

Next, you can mark each candidate with a plain reason for keeping or dropping it. “Easy to spell after hearing it,” “too close to another word I might type by mistake,” “still reads clearly in lowercase.”

Where should I record the result of the availability guidance under each candidate while keeping project name, candidate spelling, and registration result separate?

When the list is ready, add a separate line under each candidate for the result of whatever availability guidance you consult, and leave it blank until then. Keeping the project name, the candidate spelling and the registration result in three places means a rejected spelling does not erase the name you began with.