New Web Domains: About Domain Extensions
By Ardan Michael Blum, who has run a Palo Alto SEO agency since 2016.
By Ardan Michael Blum, who has run a Palo Alto SEO agency since 2016.
Updated October 12, 2026
A web address can begin explaining a project before anyone opens the page. An ending such as .events, .design, or .art can suggest its subject, while a geographic or internationalized extension can express a connection to a place, community, or language. The expansion of domain extensions has given publishers, businesses, and individuals more ways to choose a fitting name.
The decision involves the complete address and the arrangements behind it. Who may register the name? What will it cost to keep? Can the intended audience read it, and will essential services accept it? Those questions help distinguish a useful naming choice from an attractive first-year offer.
In 2026, there is also an important timing distinction. Many extensions introduced through ICANN’s previous expansion are already available, subject to their registration rules. The applications published in October for the 2026 round are proposals undergoing a separate process. Their publication does not make those extensions available for ordinary domain registration.
Begin with a shortlist of complete addresses. Read each aloud, consider how it appears in an email address, and ask a few prospective readers what they expect to find there. Can they repeat it after hearing it? Does the spelling need explanation? Would its meaning still fit if the project expanded?
A hypothetical designer launching a first portfolio might find a .design address clear and appropriate. A narrow subject ending can also suit a focused publication. A broader name may give a changing organization more room. These are judgments about the audience and intended use, rather than a rule that one class of extension is universally better.
An established organization faces additional questions. Returning visitors, printed materials, existing page links, email addresses, and account-recovery contacts may all depend on its current name. A more attractive address on a poster should offer enough benefit to justify the work of changing those dependencies. Keeping an established address is a reasonable outcome of the comparison.
Tests of comprehension and recall can help you judge the name. They do not establish that an address will increase sales, credibility, or search traffic. Before deciding, combine the naming exercise with the exact name’s price, eligibility rules, and operational requirements.
A top-level domain, or TLD, sits immediately below the root of the Domain Name System, usually shortened to DNS. In the illustrative address localization.company, .company is the TLD and localization is the second-level label. Registration does not always take place directly beneath the TLD: in example.co.uk, .uk is the TLD, while co.uk is a public suffix under which names can be registered. RFC 9499 explains these levels and registration boundaries.
Three roles explain the ordinary registration arrangement. The registry operates an extension and maintains its registration records. A registrar offers registration services to customers, and the registrant is the person or organization holding the registration. Registering a name under .events gives the registrant rights under the relevant agreement; it does not make that person the operator of .events.
Registration, DNS hosting, website hosting, and email hosting are separate services, even when a provider sells them together. DNS records connect the name with services such as a website or mail system. A successful registration alone does not create a working website or mailbox. ICANN’s domain-industry explanation describes these services and the parties involved.
Delegation is another distinct step. For a TLD, the DNS root publishes references to the name servers responsible for that extension. Its registry may then offer registrations broadly, impose eligibility rules, withhold particular names, or operate the space for a specific organization. Delegation establishes a place in the DNS; registry policies and launch arrangements determine registration availability.
In this article, “new gTLDs” means the generic extensions introduced through the large-scale program that began with ICANN’s 2012 application round. The word identifies a program category. Many of these extensions have now been operating for more than a decade. Earlier expansion rounds in 2000 and 2003–04 had already produced additions such as .biz, .info, .cat, and .travel.
On October 23, 2013, ICANN announced the first four delegations from the 2012 round: .شبكة, .онлайн, .сайт, and .游戏, using Arabic, Cyrillic, and Chinese writing. Other extensions followed their own delegation and registration schedules, with different rules about who could use them.
The 2012 round received 1,930 applications for approximately 1,400 unique strings, meaning proposed TLD labels. ICANN’s statistics as of August 31, 2026 record 1,241 cumulative delegations. That figure is not an active-extension count: later contract terminations or removals from the root are not subtracted. Applications, distinct strings, cumulative delegations, and currently operating extensions answer different questions.
Word pairs such as localization.company, museum.art, and festival.events illustrate how the words on either side of the dot can describe a subject. They are naming illustrations, not offers of available registrations. A coherent complete address may suit a project better than a longer name chosen solely to obtain a familiar ending.
The useful test is how the intended audience understands the whole address. A descriptive ending can contribute to that understanding, but it cannot explain unclear wording elsewhere in the name. Judge the complete combination in the situations where people will encounter it: on a screen, in conversation, in print, and after the @ in an email address.
Extensions such as .africa, .berlin, .london, .nyc, .paris, .scot, and .tokyo can express a geographic or community connection. Their names do not reveal their complete eligibility rules. Some accept a broad range of applicants, while others require a continuing connection or a particular use.
For example, the .tokyo registry says registration is open worldwide without a local-address requirement. The .scot registration policy requires an ongoing connection to the worldwide Scottish community through language, culture, tourism, business, or another beneficial activity, together with a declaration of intended use. Eligibility may therefore matter throughout the registration, rather than only at the initial application.
Some organizations operate their own .Brand extensions. Specification 13 of ICANN’s Registry Agreement restricts registrants and control of DNS records to the operator, its defined affiliates, and qualifying trademark licensees. Individual registry policies can be narrower. Ordinary customers or commercial partners do not automatically qualify.
The attraction is coordinated control over naming and administration. A company can organize official services, product information, or campaigns within a space governed by its own policies and ICANN agreement. Google’s publication at blog.google provides a visible example. Extensions such as .apple, .bmw, .google, and .amazon illustrate brand control rather than ordinary retail registration choices.
This differs from exclusive use of a generic term for its general meaning. The 2026 Applicant Guidebook says closed-generic applications will not be approved until the required public-interest methodology and criteria exist. A dictionary word can still function as a particular brand. Spelling alone does not resolve that classification.
An extension can carry obligations beyond paying a registrar. Endings such as .bank, .insurance, .law, and .pharmacy have specialized eligibility or operating rules. A name that sounds appropriate for a profession is therefore not necessarily available to everyone working near that field.
The .bank implementation guide describes verification and continuing security requirements, including controls for DNS, web connections, and email. Unresolved compliance failures can lead to suspension under the registry’s enforcement policy. Before choosing a restricted extension, establish that you qualify and that your providers can maintain its requirements. Those safeguards do not guarantee that every transaction or item of content is safe.
Internationalized Domain Names, or IDNs, existed before the 2012 round. ICANN’s first non-Latin country-code extensions entered the production root in May 2010. The later generic expansion added endings such as .شبكة, .дети, .みんな, .世界, and .网络, extending multilingual choices at the top level.
Internationalization also includes Latin letters with accents and other diacritics. A non-ASCII label that meets IDNA’s rules has a Unicode form, called a U-label, and a corresponding DNS-compatible ASCII form, called an A-label. The conversion works label by label; A-labels begin with xn--. For example, .شبكة corresponds to xn--ngbc5azd. These are two representations of the same label, not separate names to buy. RFC 5890 explains the terminology.
For the 2026 round, ICANN’s Root Zone Label Generation Rules cover 27 scripts or writing systems. That describes rules for proposed top-level strings, not permission to register every word or Unicode character. Registry IDN tables and policies separately determine which spellings and combinations are allowed beneath an extension.
The round also permits applications for eligible variant strings under its evaluation rules. A variant is a distinct label with a relationship established by the applicable rules. It is not an automatic translation, DNS alias, or approved extension. Some variants are blocked rather than available.
A descriptive ending should earn its place through its usefulness to people. Google’s SEO Starter Guide says keywords in a domain name alone have little ranking effect and that, apart from country targeting, TLD choice does not matter to Google Search. Its ranking systems guide describes words in domains as one of many relevance factors and explains how its exact-match-domain system limits excessive credit. Neither statement establishes a special bonus for the word after the dot.
Geographic new gTLDs also differ from country-code targeting. Google treats city and regional generic extensions as generic, so .london does not supply the country signal associated with .uk. Some country-code extensions, including .ai and .io, are themselves treated as generic by Google. These search classifications do not change their status in the DNS. Publishers still need content and appropriate regional signals that identify their intended audience.
A TLD supplies no inherent search engine. DNS retrieves records associated with names; it does not create a content index of every website beneath an extension. A registry can separately provide a directory, and a search engine can offer filtering features, but those are additional services. This distinction follows from the DNS architecture, rather than from the descriptive meaning of an ending.
ICANN’s January 2024 overview summarized earlier competition, consumer choice, and consumer trust research. It described much greater choice, a smaller increase in competition, and limited overall change in trust. The underlying 2018 review found that familiarity favored legacy endings and that some TLDs had disproportionate levels of DNS abuse. These are historical findings, not a new survey of trust or abuse in 2026.
Since April 5, 2024, amendments to the applicable gTLD registry and registrar agreements have required appropriate mitigation of DNS abuse supported by actionable evidence. The defined category includes malware, botnets, phishing, pharming, and spam used to deliver those harms. ICANN’s DNS-abuse resources explain the contractual scope. Those obligations do not make ICANN a general regulator of website content; readers still need to examine the complete address, the organization, and the service they are using.
The exact name’s continuing cost matters more than an extension’s advertised starting price. ICANN’s renewal guidance warns that introductory prices can be lower than subsequent renewals. Obtain the registration, renewal, transfer, and restoration prices for each candidate, including applicable taxes and optional recurring services.
Premium pricing needs a separate question. A registry-designated premium name may carry higher registration, renewal, or transfer fees. An existing registrant’s resale asking price is a different charge, and a resold name may also retain premium renewal terms. Namecheap’s explanation of these sales models illustrates why a large purchase price tells you little about the next annual bill.
A hypothetical comparison makes the arithmetic concrete. If Name A costs USD 5 initially and USD 60 at renewal, five years cost USD 245. If Name B costs USD 30 initially and USD 30 at renewal, the same period costs USD 150. These invented figures count the first year plus four renewals, assume unchanged fees, and exclude tax and other charges. Apply the calculation to the actual quotes you receive.
Future renewal prices are not necessarily fixed. Section 2.10 of ICANN’s Base Registry Agreement permits registry renewal-price increases subject to notice and pricing provisions, generally including 180 days’ notice to contracted registrars with specified exceptions. These are wholesale rules; registrars set retail terms. Check the agreement applicable to the extension and the registrar’s terms rather than treating today’s quote as a lifetime guarantee.
Before paying, establish what rights the offer provides. For an ordinary registration, confirm that you or your organization will be the Registered Name Holder. ICANN warns about registration by a developer or agency in its own name. Domain registrations run for renewable terms, so payment does not secure a name forever.
Some specialized offerings use a different arrangement. The .realtor license agreement says the operator remains the registrant and grants the customer a license to use the name. In such a case, examine renewal, transfer, termination, and recovery provisions. Access to a dashboard alone does not answer who holds the registration or what happens when the relationship ends.
Keep authorized access to the registrar account and enable multifactor authentication where available. Record how access will be recovered if the responsible person leaves, and maintain current contact details. ICANN’s account-security guidance treats protection and recovery as part of managing a domain.
Use automatic renewal where appropriate, maintain valid payment details, and keep an independent expiration reminder. Confirm that renewal actually succeeded. Expiration can interrupt websites and email and may ultimately lead to loss of the registration. A secondary contact outside the affected domain helps avoid depending entirely on mail that an outage could disable.
An available name is not necessarily free of trademark conflicts. Consider relevant trademark records, existing commercial uses, and the proposed use before registration or acquisition. Registering a domain does not itself establish trademark rights, and a database search alone cannot establish that no conflicting rights exist.
A previously used name also deserves a review of its history. Google’s migration guidance recommends checking Search Console for existing manual actions and outstanding URL removals on a newly acquired domain. Availability or a completed purchase does not establish that those earlier issues have been resolved.
Under ICANN’s Uniform Domain Name Dispute Resolution Policy, a complainant must establish all three required elements: identity or confusing similarity to its mark, lack of the registrant’s rights or legitimate interests, and both bad-faith registration and bad-faith use. A successful complaint can result in cancellation or transfer. The separate Uniform Rapid Suspension procedure provides suspension for clear cases meeting its requirements and a clear-and-convincing evidence standard; it does not transfer the name to the complainant.
Universal Acceptance is the goal that valid domain names and email addresses work correctly across Internet-enabled systems. ICANN’s UA guidance covers acceptance, validation, processing, storage, and display. A site opening successfully in a browser does not establish that a signup form, customer database, or mail service handles its address correctly.
Several problems need to be distinguished. An ordinary ASCII address under a newer or longer ending can be rejected by an outdated validation rule. An internationalized domain needs correct handling of its Unicode and encoded forms. Non-ASCII characters before the @ introduce another requirement: internationalized email support, including the SMTPUTF8 extension. Punycode handles domain labels, not the mailbox name before the @. An ASCII mailbox using an encoded IDN domain does not require SMTPUTF8 solely because of that domain.
Test the workflows you will depend on. Submit controlled addresses through registration and recovery forms, save and reopen them in customer records, and complete confirmation and password-reset messages. Check replies, imports, exports, and forwarding if those are part of the service. For an IDN, check display and copying in relevant browsers and applications; browser security rules may display an encoded form in some circumstances.
Developers should test browser and server validation and replace stale extension lists or arbitrary suffix-length limits. The Universal Acceptance Steering Group’s document hub provides implementation and testing material. The important result is successful handling throughout the workflow, including delivery and recovery, rather than acceptance by a single form.
Test every web hostname visitors will use, including the bare domain and www address where applicable. Check HTTPS, certificate coverage and renewal arrangements, redirects, forms, and sign-in. A working homepage is only one part of a working service.
Google Registry’s .app and .dev extensions are included in the HSTS preload list. Browsers enforcing that list upgrade HTTP requests to HTTPS for names beneath them. Working HTTPS and a valid certificate are therefore needed even for a hostname used only to redirect visitors elsewhere. HSTS does not configure the server or issue its certificate.
HTTPS protects the connection, but Chromium’s security explanation cautions against treating it as proof that a website is trustworthy. The operator and content still need to be evaluated. A technical requirement attached to an extension should be understood precisely rather than turned into a general safety claim.
A domain change should begin with an inventory of dependencies. Identify important pages, downloads, email addresses, account-recovery contacts, integrations, and printed references. Prepare the destination before announcing it, and decide how each existing address will continue to work.
Google’s site-migration guidance recommends permanent redirects from old URLs to their corresponding new pages, normally using HTTP 301 or 308. When pages are genuinely consolidated, direct them to the relevant consolidated content. Sending unrelated old pages to the new homepage can discard the context readers expected.
Update internal links, canonical URLs, regional annotations where used, and the sitemap. At launch, remove any temporary noindex instructions or crawl blocks from public pages that should appear in search. For an applicable domain or subdomain move, follow Search Console’s Change of Address process, including its current instructions for verified old-domain variants.
Maintain redirects for as long as practical, generally at least a year under Google’s guidance. Keep the old registration, DNS, redirect service, and any necessary HTTPS certificates working for that period. Longer retention may serve returning visitors and remaining email or account dependencies. Monitor indexing and traffic, since search visibility can fluctuate; these steps do not guarantee unchanged rankings or a particular recovery date.
Email requires its own transition plan. Web redirects do not forward messages sent to an old email address. Keep needed mailboxes or forwarding arrangements working, test delivery, and update outside accounts that use the old address. For the new mail domain, confirm the required MX routing and ask the provider to configure appropriate SPF, DKIM, and DMARC authentication. Google’s sender guidance explains these authentication mechanisms. Test sending and receiving before retiring old arrangements.
ICANN’s application window ran from April 30 through August 12, 2026. On October 7, 2026, ICANN published the applications and reported 1,615 applications in its primary-string snapshot dated October 7. The Application Publication and Statistics system reported 481 applicants. The snapshot is provisional: final application numbers and types will be confirmed on String Confirmation Day. Applications are not a count of approved extensions or distinct names that registrants can already buy.
As of this article’s October 12 update, ICANN’s announced replacement-string period runs from October 8 through October 21, 2026, in UTC. Eligible applicants can select a previously designated replacement string, substituting it for their primary proposal. ICANN has scheduled String Confirmation Day for November 17, 2026, and the Community Input and Objections Period for November 17, 2026, through March 16, 2027. Consult current program announcements for any changes.
Evaluation, objections or contention where applicable, contracting, technical onboarding, and delegation still separate an application from an operating extension. The published application system also distinguishes primary proposals from replacement records. A replacement record is not an additional approved TLD, and readers should not count every published record as a separate application.
Applying to operate a TLD is a different financial undertaking from registering a domain. The current Applicant Guidebook, authoritative version V3-2026.10.07, gives a standard evaluation fee of USD 227,000 per application, with support provisions, specified variant arrangements, and possible additional fees. That is not the total cost of running a registry. Buyers choosing an address today should evaluate extensions and exact names already offered under current registration rules.
The Domain Name Industry Brief for Q2 2026, sponsored by Verisign, reported 52.9 million new-gTLD registrations at June 30, out of 401.6 million in its all-TLD category, approximately 13.2 percent. The .com total was 166.6 million. New-gTLD registrations had increased 34.0 percent over the previous year.
These figures establish a substantial market segment. They count registrations, which may support websites, email, redirects, defensive holdings, or future projects. They do not count distinct businesses, regular visitors, or successful publications.
The report gave its most recent combined renewal estimates as 31.0 percent for new gTLDs and 67.2 percent for legacy gTLDs excluding .com and .net. These are aggregate estimates of registration renewals, not measurements of active website use. DNIB’s methodology says estimates outside .com and .net use the previous quarter’s final renewal percentages or the latest available information. Coverage, rounding, and later revisions also affect the data.
Renewal and active use answer different questions. A retained registration may have no public website, and a discontinued registration may have served a temporary purpose. The category includes extensions with very different audiences and policies, so its combined percentage cannot establish the prospects of a particular .art, .bank, or community domain.
Use IANA’s current alphabetical TLD list to check delegation and its Root Zone Database to identify the manager and administrative record. The database retains some entries marked “Not assigned,” so appearing there alone does not establish current delegation. Neither source confirms that your exact name is available or that you qualify to use it.
Use these questions to compare shortlisted names. Resolve unanswered points before registering or committing to a migration.
Fit: Does the complete name communicate the project clearly to its intended audience?
Availability: Is this an available registration, an existing holder’s resale offer, or a licensed-use arrangement?
Eligibility: Can you satisfy the registry’s naming, use, and continuing technical requirements?
Cost: Have you checked the exact name’s renewal and premium terms as well as its initial price?
Control: Who holds the registration, who can recover access or renew it, and what options exist for moving it to another provider?
Rights: Have you considered trademark conflicts and the proposed use?
Operation: Have the necessary web, form, database, and email workflows been tested?
Continuity: If an address is changing, are old links, correspondence, and account dependencies covered?
New extensions offer more ways to make an address fit a project. Their value emerges when the name, audience, costs, rules, and operational arrangements work together. A strong choice is one you can explain clearly and maintain reliably as the site develops.
The links beside claims provide the most direct route to their sources. The selected resources below offer a shorter reading path through the larger subject. Official documents establish rules and technical definitions; registry and registrar material explains the particular services or policies those organizations administer.
ICANN: The Domain Name Registration Process. Roles of registrants, registrars, resellers, and registry operators.
ICANN: Domain Name Renewals and Expiration. Renewal, expiration, recovery, and continuing costs.
ICANN: Securely Managing Your Domain Name. Account protection and recovery.
ICANN Registration Data Lookup. Public registration data and registrar information; it does not establish trademark clearance or reveal all nonpublic details.
IANA Root Zone Database. TLD managers and administrative records, including some entries no longer assigned.
IANA Alphabetical List of TLDs. Current TLD list, separate from exact-name registration availability.
ICANN Transfer Policy. Governing rules for covered registrar transfers; consult the current version and your registration terms.
ICANN Universal Acceptance. Handling valid domain names and email addresses throughout software workflows.
Google: SEO Starter Guide. Domain keywords, country targeting, and the wider work of search visibility.
Google: Ranking Systems Guide. Domain words and the exact-match-domain system.
Google: Managing Multi-Regional and Multilingual Sites. Country signals and generic treatment of certain extensions.
Google: Site Moves With URL Changes. URL mapping, redirects, indexing, and monitoring.
Search Console: Change of Address. When and how to use the tool for an applicable move.
New gTLD Program: 2026 Round. Official program hub and current announcements.
ICANN’s October 7, 2026 Reveal Day Announcement. Dated application snapshot and announced milestones.
Application Publication and Statistics. Public application information and statistics; applications and replacement records require careful interpretation.
Applicant Guidebook Version Hub. Identifies the authoritative English version. As of October 12, it is V3-2026.10.07, published October 7.
2012 Round Statistics. Historical applications and cumulative delegations.
Domain Name Industry Brief: Q2 2026 and methodology. Registration totals and renewal estimates, with coverage and timing qualifications.
RFC 1034: Domain Names, Concepts and Facilities and RFC 1035: Domain Names, Implementation and Specification. Foundational DNS documents; consult their later updates.
RFC 9499: DNS Terminology. Published in 2024 and superseding RFC 8499.
RFC 5890: IDNA Definitions and Document Framework and RFC 5891: IDNA Protocol. Unicode labels, encoded representations, and protocol requirements.
RFC 6531: SMTP Extension for Internationalized Email. Requirements beyond domain-label encoding.
IANA Repository of IDN Practices. Registry-submitted tables of permitted characters and related rules.
Universal Acceptance Steering Group Document Hub. Practical developer guidance, email material, and readiness reports.
RFC 4033: DNS Security Introduction and Requirements. DNS-data authentication and integrity, distinct from transport encryption.
IANA DNSSEC Trust Anchors and Rollovers. Current operational key material. IANA confirmed that the root began using KSK-2024 on October 11, 2026, with key tag 38696.
Uniform Domain Name Dispute Resolution Policy. The policy text and its required elements.
WIPO Overview 3.1. Current synthesis of panel views, released in February 2026; it does not replace the policy or the facts of an individual dispute.
Uniform Rapid Suspension. A separate procedure whose remedy is suspension rather than transfer.
ICANN DNS Abuse Mitigation Resources. Contractual scope, reporting, and compliance.
ICANN: Registration Data Access Protocol. The standardized registration-data service for gTLDs. Continuing WHOIS obligations in limited cases do not remove RDAP obligations.
ICANN Registration Data Policy. Effective August 21, 2025, and revised May 12, 2026; use the current policy text.
For corrections, permissions, privacy requests, or accessibility assistance, use the contact form or call +1 (650) 427-9358. For details, see Legal, Privacy and Accessibility.
Disclosure: I work in SEO consulting and have a professional interest in how search engines direct readers to websites. AI tools assist with research, drafting, and editorial review; their use varies by page. I retain editorial control and responsibility for what I publish. AI-assisted review does not constitute independent human peer review.