Domain Cybersquatting: How to Detect and Document It
Learn how to assess possible domain cybersquatting, weigh evidence on both sides, and organize a factual record for a UDRP complaint.
A domain that resembles your trademark may deserve investigation, but similarity alone does not prove cybersquatting or establish a successful UDRP claim. To prevail under the Uniform Domain Name Dispute Resolution Policy (UDRP), a complainant must prove all three elements: trademark rights and identical or confusing similarity; the registrant’s lack of rights or legitimate interests; and registration and use in bad faith. Build a dated, indexed record that addresses each element and also records facts that could support the registrant.
ICANN generally characterizes cybersquatting as bad-faith registration of another’s trademark in a domain name. That general description is not a finding about any particular registrant. A parked page, an offer to sell, or a similar string can be relevant, but none alone establishes all three UDRP elements. See ICANN’s explanation of cybersquatting and the UDRP text.
What is domain cybersquatting?
Domain cybersquatting generally refers to registering a domain name in bad faith that uses another party’s trademark. The key practical distinction is between a suspicious domain and a supported claim: under the UDRP, the complainant has to prove the policy’s three elements, not simply show that the name looks similar.
The UDRP gives examples of circumstances that may support bad faith: registering primarily to sell the domain to the mark owner or a competitor for more than documented direct out-of-pocket costs; a pattern of registrations intended to prevent mark owners from reflecting their marks in domain names; registration primarily to disrupt a competitor; or intentionally attracting users for commercial gain through likely confusion. These are examples to evaluate in context, not automatic rules. A sale offer, for example, should be read alongside the domain’s use, the parties’ communications, and the other elements.
How do I know if someone is cybersquatting on my domain?
Start by comparing the precise domain and its actual use with the mark you rely on. Then investigate the circumstances of registration and use, preserve relevant communications, and assess possible legitimate interests fairly. Avoid labeling the registrant a cybersquatter before the evidence has been evaluated against all three elements.
Element 1: trademark rights and similarity
Identify the trademark or service mark, its owner, relevant registration details if applicable, and the goods or services associated with it. Record the exact disputed domain spelling, including the top-level domain, and explain why the name is identical or confusingly similar. A bare statement that it is “similar” is less useful than a clear comparison tied to the mark and the domain.
Element 2: no rights or legitimate interests
Look for evidence about how the registrant uses the domain and whether there is a plausible independent reason for the name. The UDRP identifies circumstances that may show rights or legitimate interests, including:
- Bona fide use, or demonstrable preparations for bona fide use, before notice of the dispute.
- Being commonly known by the domain name, even without trademark rights.
- Legitimate noncommercial or fair use, without intent for commercial gain to misleadingly divert consumers or tarnish the mark.
Record facts that point in either direction. A site that uses a similar name is not enough by itself to resolve whether its use is bona fide, fair, or misleading.
Element 3: registration and use in bad faith
Collect evidence about both registration and use. Relevant facts can include targeted resale communications, a pattern of blocking trademark owners, competitor activity, or commercial attraction through confusion. Record the actual content and context you observed; do not infer intent from the domain string alone. The policy’s examples are described in the UDRP.
What evidence do I need for a UDRP complaint?
The Rules call for a complaint explaining its grounds and requested remedy, with documentary or other evidence and an indexed schedule of that evidence. The following workflow is a practical way to organize a factual record; it is not a technical preservation standard mandated by ICANN.
- Identify the mark and owner. Gather the mark records you will rely on, identify the owner, and describe the associated goods or services.
- Identify the domain and registrar. Record the exact domain and registrar information available to you. The complaint rules require domain and registrar details as part of the filing.
- Record observed use. Keep copies of the website content you observed and note when you observed it. If relevant, record whether the site is parked, offers goods or services, redirects, appears blank, or is unavailable. A dated observation helps explain what the evidence shows, but the research sources do not prescribe a particular screenshot, timestamping, DNS, or chain-of-custody method.
- Preserve relevant communications. Keep targeted offers to sell, correspondence, or other communications that bear on intent or confusion, if they exist. Distinguish what was said from your interpretation of it.
- Record evidence on both sides. Note facts that may support bad faith and facts that could show bona fide preparations, common-name use, or legitimate noncommercial or fair use.
- Index the materials. Give each item a stable label and add it to a schedule that briefly says what it is and which element it relates to. The UDRP Rules expressly require documentary or other evidence with a schedule indexing the evidence attached to the complaint.
- Explain the elements and requested remedy. Connect the facts to each of the three elements, identify the remedy sought, and include related proceeding information as required by the Rules.
Example evidence index
| Index | Item | What it records | Possible relevance |
|---|---|---|---|
| A | Trademark record | Mark owner and registration information | Trademark rights |
| B | Domain and registrar record | Exact disputed name and registrar information | Domain identification and procedure |
| C | Dated site observations | Content visible at the times observed | Use, possible confusion, or possible legitimate use |
| D | Relevant correspondence | Exact communications and dates | Possible targeting, resale, or other context |
| E | Context or contrary evidence | Facts about independent use or preparations | Possible rights or legitimate interests |
This is an organizational example, not an official ICANN-prescribed evidence format. Follow the applicable provider’s current filing requirements.
Procedure and domain coverage
UDRP applicability is not universal across every domain extension or dispute. ICANN explains that the UDRP may be available for a similar mark in a contracted generic top-level domain; do not assume that applies to every country-code top-level domain or every domain-name dispute. Check the policy, the relevant registry’s rules, and the dispute provider’s current supplemental rules for the specific domain.
Under the Rules, after a complaint is filed the provider requests verification from the registrar. The registrar supplies the registration data and confirms a lock within the rule framework. The rules set out the process, but provider-specific requirements and domain coverage should be checked at the time of filing. For a consequential dispute, consult qualified intellectual-property counsel familiar with domain-name disputes.
Capture dated website evidence
A screenshot can help show what a site displayed when observed. Keep the domain, observation date and time, and a brief note about what the capture depicts with the image in your evidence index. A screenshot records visible page content; it does not by itself prove who registered the domain, what the registrant intended, or whether all UDRP elements are met.
For a manual capture, open the exact URL in a browser, wait for the relevant page content to appear, and save a screenshot with the date and domain recorded in your notes. If a page is long, capture the relevant portion and make clear what is and is not visible. The research materials do not establish an official screenshot-preservation protocol, so treat this as practical documentation rather than a formal evidentiary guarantee.
Capture a page with Playwright
Install Playwright and its Chromium browser, then save this as capture.mjs. It captures the page as rendered and writes a full-page PNG. The timestamp and URL are printed for your separate evidence notes; the script does not certify authenticity or preserve a chain of custody.
npm install playwright
npx playwright install chromium
// capture.mjs
import { chromium } from 'playwright';
const target = process.argv[2];
if (!target) throw new Error('Usage: node capture.mjs https://example.com');
const browser = await chromium.launch({ headless: true });
try {
const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
const response = await page.goto(target, { waitUntil: 'networkidle', timeout: 45000 });
console.log(JSON.stringify({
url: page.url(),
observedAt: new Date().toISOString(),
status: response?.status() ?? null
}, null, 2));
await page.screenshot({ path: 'domain-evidence.png', fullPage: true });
} finally {
await browser.close();
}
Run it with node capture.mjs https://example.com, replacing the sample URL with the domain under review. A site may block automated browsers, render differently by location or account state, or change between visits. Note those conditions rather than treating a failed capture as proof of what the page normally displays.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Send one GET request for a URL and receive a PNG, JPEG, WebP, or PDF. Its consent handling accepts cookie banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. For documenting a page, consider whether removing those overlays would omit relevant evidence: if the banner or popup itself matters, disable the corresponding cleanup step or use another capture method, and record the method used.
Read the ScreenshotNeo API documentation for request options. This example saves the response body as a WebP file:
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://example.com \
-o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);
ScreenshotNeo reports page verdict and billing status in response headers. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed. It also offers an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. Plans include 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000, and every feature is available on every plan. These are capture and billing features, not a guarantee that a screenshot will be accepted as evidence or prove a UDRP claim.
Sign up for 1,000 free screenshots a month, with no card required.
Reliability, performance, and cost considerations
- Repeat observations carefully. A page can change or behave differently across sessions. Record when you viewed it and what conditions were used; separate observations from conclusions.
- Expect capture failures. Timeouts, bot checks, blank responses, and blocked automation can prevent a useful image. Try a normal browser observation and record the failure rather than interpreting it as evidence of intent.
- Keep originals and an index. Store the captured files alongside their index entries and keep the domain and observation time in accompanying notes. The cited rules require indexed evidence but do not specify a technical retention or integrity procedure.
- Budget by method and volume. A local Playwright workflow uses your own browser setup and compute. ScreenshotNeo’s stated plans range from a free 1,000 monthly shots to paid plans starting at $5 for 3,000; yearly billing gives two months free. Only clean shots are billed under its stated policy. Confirm current plan details in its documentation.
Common problems and fixes
| Problem | Why it happens | What to do |
|---|---|---|
| The domain resembles the mark, but the record is thin | Similarity addresses only one part of the UDRP analysis | Gather facts for all three elements and assess contrary evidence before drawing a conclusion. |
| The site is parked or blank | A page state alone does not establish bad-faith registration and use | Record what was observed and when; seek contextual evidence rather than inferring intent. |
| A registrant offered to sell the domain | An offer alone does not prove all policy elements | Preserve the exact communication and assess whether the policy’s targeted resale example fits the facts, including documented direct out-of-pocket costs. |
| Playwright times out waiting for network idle | Some sites keep network connections open or load continuously | Use a shorter, explicit wait strategy such as domcontentloaded, then wait for a relevant selector or a reasonable delay and note the capture conditions. |
| Playwright cannot load the page | The site may block automation, have a certificate problem, or be unavailable | Check the URL in a regular browser, record the error and time, and do not treat an unsuccessful capture as proof of site content. |
| Screenshot omits a banner or popup | Consent or overlay cleanup can change visible content | Use a method that preserves the relevant overlay or turn off the applicable cleanup step; record which method produced the image. |
| The filing provider asks for a different format or additional material | Provider supplemental rules and domain coverage can vary | Check the current provider rules and the relevant registry requirements before submitting. |
Frequently asked questions
Does a parked domain prove cybersquatting?
No. It may be a fact to document, but a complainant must prove all three UDRP elements, and the circumstances matter.
Does an offer to sell prove bad faith?
Not by itself. The policy lists targeted resale above documented direct out-of-pocket costs as an example of bad faith, but the whole record and each required element still need evaluation.
Does the UDRP apply to every domain extension?
No universal assumption is safe. Check the policy and current rules for the particular extension, registry, and provider.
Can screenshots prove who owns or registered a domain?
A screenshot shows visible page content at a capture time. It does not by itself establish registrant identity, intent, or the complete UDRP case.


