.mobi is still an active generic top-level domain in 2026, but its original reason for existing is far less important. Modern responsive sites can serve phones, tablets, laptops, and assistive technologies from the same URLs. Google recommends responsive web design because it is the easiest pattern to implement and maintain.
For most new businesses, products, publications, and portfolios, the better choice is one primary domain with a responsive site. .mobi can still work for a tightly scoped mobile campaign, a short redirect, or a legacy address that already has users and links. It should rarely become a second full copy of the main website.
| Use | Current fit |
|---|---|
| New primary business website | Usually weak |
| Separate duplicate mobile site | Usually avoid |
| Short mobile campaign or QR destination | Possible when the name is clear |
| Redirect from an established legacy address | Useful when traffic or links remain |
| Mobile app product | Compare .app and the main company domain |
| Defensive registration | Case-specific; price the renewals first |
1) Use the current verdict
.mobi is relevant as a namespace, not as a requirement for reaching mobile users. IANA's current record lists it as a generic TLD sponsored by Identity Digital Limited. The record was updated on 4 September 2025 and traces the registration to 17 October 2005.
Nothing about a .mobi registration automatically makes a site fast, responsive, accessible, installable, or well designed. Those outcomes depend on the code, content, hosting, testing, and operational discipline behind the URL.
The extension now answers a branding question: does explicitly saying “mobile” in the address improve this particular journey? If the answer is vague, keep one primary domain. If the answer is tied to a measurable campaign or established legacy address, evaluate .mobi as a supporting asset.
2) Place the original idea in context
The original 2005 DotMobi charter described a namespace for consumers and providers of products, services, and content accessed over mobile or wireless connections. At that time, phones had smaller screens, weaker browsers, slower connections, and more device-specific site patterns. A separate mobile destination could signal that the experience was built for those constraints.
The contractual structure later changed. ICANN's current agreement index lists a base, non-sponsored agreement dated 30 March 2017 and identifies Identity Digital Domains Limited as operator. IANA now records .mobi as a generic TLD.
The historical mobile purpose still explains the word and the audience expectation. It does not create a present technical requirement to put mobile content on a .mobi domain.
3) Account for responsive design
Google's current mobile-first guidance describes three supported patterns: responsive design, dynamic serving, and separate mobile URLs. It recommends responsive web design because it is easiest to implement and maintain.
Responsive design serves the same HTML and URL across devices, then changes presentation according to screen size. That removes the main architectural reason to create parallel desktop and mobile domains.
One responsive URL reduces several operational burdens:
- one canonical address to share and earn links;
- one page inventory to update;
- one analytics path;
- one set of structured data and metadata;
- fewer device redirects;
- less risk of desktop and mobile content drifting apart; and
- simpler international and accessibility testing.
A responsive site can still fail on mobile. Large scripts, intrusive overlays, tiny tap targets, missing content, layout shifts, and slow servers are implementation problems. Changing the TLD does not correct them.
4) Keep the useful .mobi cases narrow
There are still defensible uses for .mobi.
An established legacy address. If customers, printed material, backlinks, or old applications still use the domain, keep control of it and redirect each useful path to the corresponding page on the responsive site.
A bounded mobile campaign. A concise domain on a poster, product label, vehicle, or event display can lead to a phone-first action such as tickets, directions, check-in, or a menu. The landing page still needs responsive code.
A device-specific operational tool. A field team may use a short address for scanning, inventory, or checklists. The value comes from memorability and access control, not from the extension's technical behavior.
A defensive asset. An organization may register the matching .mobi to prevent confusion and redirect it. This is only sensible when the confusion risk justifies a recurring renewal that may be much higher than the first-year sale.
In each case, define one job and one owner. A supporting domain without an owner becomes an expired redirect, stale campaign, or security risk.
5) Avoid a duplicate mobile website
Launching brand.mobi as a full copy of brand.com creates two inventories. Every change to price, stock, policy, navigation, tracking, consent, structured data, and accessibility must remain aligned.
Separate mobile URLs are supported, but they require extra search controls. Google's guidance calls for equivalent content, consistent robots directives, correct canonical and alternate relationships, matching structured data, and careful handling of international links. Mobile URLs that collapse many desktop pages into one destination can disappear from the index.
The duplication also creates user ambiguity. A customer can share the mobile URL to a desktop user, bookmark a device-specific path, or encounter inconsistent login and cart state. Responsive design is generally the cleaner default.
Do not build a second site merely because the .mobi name is available. Write down the user journey that cannot be served well on the primary responsive domain. If no such journey exists, the second site is overhead.
6) Compare .mobi, a subdomain, and .app
Three mobile-oriented choices solve different naming problems.
| Address pattern | Best interpretation | Main tradeoff |
|---|---|---|
brand.mobi | Separate mobile-labelled asset | Separate registration and renewal |
m.brand.com | Mobile host under the primary domain | Separate URL architecture still needs careful maintenance |
brand.app | Application or app-led product identity | .app requires HTTPS and may narrow the brand |
brand.com with responsive design | One cross-device company address | Mobile purpose is communicated by the experience, not the TLD |
An m. subdomain avoids another registration but retains the complexity of separate mobile URLs. .app communicates an application rather than mobile web access and has an HTTPS requirement because the namespace is on the HSTS preload list. The %%EDITORIAL_2%% comparison covers that choice.
For a product that includes a website, native apps, documentation, support, and a company story, one broad primary domain often creates the clearest hierarchy.
7) Test the mobile experience directly
Do not use the extension as a proxy for quality. Test the actual journey on real devices and throttled connections.
Check:
- the first useful content appears without an unnecessary splash screen;
- navigation and controls work with touch and keyboard input;
- text is readable without zooming;
- forms use appropriate input types and retain entered values;
- essential content is not hidden from mobile users;
- images and video fit the viewport;
- account, cart, payment, and error states work consistently;
- redirects preserve the exact destination path; and
- the page remains usable after orientation and text-size changes.
If .mobi is a campaign redirect, test the printed or QR path through to the final action. Record every hop, status code, tracking parameter, and fallback. A short address that adds several slow redirects is not a better mobile experience.
Repeat the test outside the office network and without an existing login session. A route can appear healthy to the team while failing for a first-time visitor because consent, authentication, location permissions, or an app-opening prompt interrupts the action. Record the device, browser, connection, destination, and result so a failed campaign can be diagnosed rather than dismissed as a user error.
8) Preserve search signals during migration
If an existing .mobi site is being retired, map each valuable old URL to its closest responsive replacement. Google recommends page-to-page permanent redirects when moving from separate mobile URLs to responsive URLs. Redirecting every old page to the home page loses context and can be treated as a soft error.
The migration checklist is:
- inventory all indexable
.mobiURLs; - identify traffic, backlinks, conversions, and printed dependencies;
- create a one-to-one redirect map;
- launch the responsive destination pages first;
- issue permanent server-side redirects;
- remove device-specific redirect logic;
- use self-referential canonicals on the destination pages;
- update internal links, sitemaps, campaigns, and profiles; and
- monitor crawl errors, logs, analytics, and conversions.
Keep the .mobi registration while redirects, backlinks, email, or offline material still depend on it. The renewal becomes part of the migration budget.
9) Calculate the actual renewal cost
Prices below were checked on 16 August 2026 for standard, non-premium names. The difference between the promotion and renewal is large enough to affect the decision.
| Registrar | First year | Regular or renewal | Transfer | Three-year scenario |
|---|---|---|---|---|
| Porkbun | $4.12 | $41.71 | $41.71 | $87.54 calculated |
| Namecheap | $4.48 | $64.98 renewal | $54.98 | $114.44 displayed registration |
Porkbun pricing shows $4.12 for the first year and $41.71 as the regular registration, renewal, and transfer price. A three-year scenario using one sale year and two regular years is $4.12 + (2 × $41.71) = $87.54.
Namecheap's current page shows $4.48 for the first year, $64.98 renewal, $54.98 transfer, and $114.44 for a displayed three-year registration purchase. The page says a $0.20 ICANN fee may be added to affected transactions. Premium names, tax, promotions, and checkout conditions can change the total.
Do not evaluate a defensive or redirect-only domain from the first-year price. Multiply the renewal by the years the dependency is likely to remain.
10) Check the name and operating plan
Before buying:
- compare the exact label on the primary domain,
.mobi, and relevant alternatives; - check trademarks and existing use;
- inspect a registered candidate's status and history;
- decide whether it will host content or redirect;
- name the person responsible for renewals and redirects;
- record the regular renewal, not only the sale;
- define analytics and success criteria; and
- set an exit rule for a temporary campaign.
Use the %%EDITORIAL_0%% page for extension context and domain research for registered names. Compare complete candidates in Bulk Search.
For a campaign, a success metric might be completed check-ins or scans reaching the correct page. For a legacy domain, it might be declining direct traffic and the removal of old printed dependencies. Without a metric, the renewal continues by habit.
11) Apply the decision rule
Use .mobi when it has a specific supporting job: an established legacy route, a measured mobile campaign, a concise field tool, or a justified defensive redirect.
Use one responsive primary domain when launching a normal website for a company, product, publication, service, or person. That approach serves mobile users without splitting content, links, analytics, and maintenance across two address systems.
The extension is still real. Its original technical proposition is no longer the default architecture. Buy it for a defined naming or continuity benefit, not because a mobile audience supposedly requires a mobile TLD.