The domain you want is taken. What should you monitor?

If your preferred domain is taken, the useful first question is what the public record actually shows. A browser visit answers whether a website responds. A registration lookup answers a different question: what registration information the registry or registrar publishes.

Use the exact domain, including its extension. Record the registrar, visible dates, status values, nameservers, lookup source and observation time. ICANN Lookup retrieves registration data through RDAP, the Registration Data Access Protocol. The returned information comes from registries or registrars; the lookup is not a statement about whether someone wants to sell.

Keep unknown fields as unknown. An empty contact field should not become an invented owner profile. If a name contains non-Latin characters, retain its displayed spelling and the technical form returned by your lookup tool so later comparisons refer to the same name.

Write one sentence explaining why you are following it. A founder evaluating a future brand name and a team checking an old company domain may need different follow-up decisions, even when they observe identical data.

Build a baseline across several signals instead of treating one field as the whole story. Your first record can be a simple dated note; the value comes from comparing it consistently.

This is a review plan, not a scoring model. Avoid assigning a numerical chance of future availability from these observations. Instead, give each alert a practical next action: repeat the lookup, inspect the new page or review the relevant status definition. DNS record monitoring explains how to compare DNS observations without confusing cached answers with new edits.

Do not schedule a launch around somebody else's domain expiry date. Registration status contains context that a date alone leaves out. For example, clientTransferProhibited restricts transfers; it is not a sign that the domain will become available. redemptionPeriod and pendingDelete describe different parts of a registration's lifecycle, and status combinations matter. Use ICANN's EPP status reference to interpret the exact values returned.

When a date moves, preserve the previous value and check which event the source labels it as. An updated date and an expiry date should occupy different fields in your notes. If the source changes its format, verify the underlying meaning before treating the difference as a domain event.

Keep your decision independent of a countdown. You can continue building on a domain you control while following another name. Our domain expiration guide covers the difference between renewal tracking for your own domains and observing expiry information for somebody else's.

A blank page, an error or a redirect is an observation about a web request. It does not establish the registration state of the domain. Likewise, an unchanged homepage gives you no reason to stop recording registration changes. Keep these observations in separate columns so your notes do not turn an interpretation into a fact.

When a website changes, save what you can actually describe: the page title, visible message, redirect destination, response status and time. Avoid summaries such as 'owner lost interest' or 'business closed' unless you have independent evidence for that statement. 'Homepage returned an error on two checks' is a much more useful record.

For an unfamiliar result, record the uncertainty explicitly. 'Lookup timed out' is different from 'domain not registered'. Repeat a failed check before changing your conclusion. A good monitoring workflow should let you distinguish a changed domain from a tool that could not retrieve the current data.

Choose a review routine that fits the importance of the name and the time you can spend on it. A growing watchlist needs a consistent process more than it needs a larger collection of screenshots.

1. Save a successful baseline with a timestamp and source.
2. Choose the specific fields you want to compare.
3. Require a clear old value and new value in your change notes.
4. Recheck surprising results using the original source when possible.
5. Mark the result as confirmed, expected, unresolved or a failed observation.
6. Decide whether the change affects your project; otherwise retain it as history.

Assign a person to review meaningful alerts if several people share the project. Include the domain in the subject or record title and use an unambiguous date format. Keep a separate review date for the watchlist itself, so names tied to abandoned projects do not consume attention indefinitely.

If a registration check reports availability, verify it again when you intend to act. Monitoring does not reserve the name or place you ahead of another registrant.

Consider a hypothetical founder tracking a domain for a future product. The initial record shows an existing registration and a basic landing page. A week later, a monitoring comparison shows different nameservers and a new website title.

The founder records both changes, repeats the registration lookup and opens the new destination. The useful conclusion is that the observed setup changed. The evidence does not justify concluding that the domain changed hands or can now be bought. The founder keeps using the project's existing domain and retains the new observations as a baseline.

Later, an expiry date changes. The founder records that event separately rather than erasing the earlier history. This keeps the sequence understandable: website changes, registration observations and project decisions remain distinct.

For a personal shortlist, the same approach can be lightweight: one record per domain, dated observations and a reason to revisit it. For a larger list, portfolio monitoring adds the need to prioritise which names deserve attention. The purpose stays the same: know what changed without claiming to know why.