Choosing a Cafe Domain Name and Moving It Safely


Short answer: choose a domain name for the customer who has to type it or hear it mentioned on a podcast, and keep it stable for years. If you already have a domain and need to move it, whether a designer is leaving, a builder is being swapped, or the shop is rebranding, treat the move as a redirect project, not a design project. The risk in a move is missing redirects, not the move itself.
Two situations bring owners to this decision. Someone naming a first cafe site, torn between a name with the city in it and a shorter brand name. Or someone about to move an existing domain and nervous the site will vanish from search for weeks, worried they will lose ground built up over years. This post covers both, in order: choosing, then moving, then the redirect checklist that actually protects a move.
Choosing a Name
A domain name has one real job: being easy for a real person to type correctly or repeat out loud after hearing it once, whether that is on a podcast, from a friend, or read off a coffee cup sleeve. Five practical questions cover this well. Can someone spell it correctly after hearing it spoken once, without needing to guess at unusual letters or word breaks? Is it short enough to say quickly and remember? Does it avoid words that are commonly misspelled or have an obvious homophone that would send someone to the wrong site entirely? Does it avoid numbers or symbols that get typed inconsistently, spelled out versus written as a digit? And is it free of a clash with an existing, unrelated brand that would confuse someone searching for it?
A city name in the domain is worth thinking through carefully rather than defaulting to it. It does tie the business clearly to a place, which reads well for a cafe that intends to stay a single location in that town indefinitely. But it is a real constraint if the shop later opens a second location in a different town, or moves, or simply outgrows the identity of being only that one place. A domain built entirely around one city's name has to be either kept as a slightly awkward fit or abandoned, neither of which is a small decision once a domain has years of use, links, and recognition behind it.
It is also worth being direct about something owners commonly assume: including a city in the domain is not the significant ranking lever many people believe it to be. A cafe's actual location, hours, and content matter far more to how it shows up in local search than whether the domain name itself contains the city. Choosing a city name domain because it feels like a search advantage, without weighing the long term flexibility cost, is optimizing for the wrong thing.
For a cafe with two locations already, or genuine plans to grow beyond one town, a brand only domain avoids locking the business into a single place's name. For a cafe confident it will stay exactly where it is, a domain naming the city is a reasonable, honest choice, as long as it also passes the five practical questions above.
A related, often overlooked question is how the domain will sound spoken aloud, not just how it looks written down. A name that reads clearly on a coffee bag or a sign can still cause confusion the moment someone hears it mentioned on a podcast or repeated by a friend, particularly if it includes a word with more than one common spelling or a phrase that could plausibly be split into words differently than intended. Saying the candidate name out loud to someone unfamiliar with it, and watching how they type it afterward, is a simple, low cost test that catches problems a written review alone tends to miss.
It is also worth deciding early whether the domain will match the cafe's actual, spoken name exactly, or whether some shortening or adaptation is acceptable. A cafe with a long, descriptive name might reasonably use a shortened version as its domain, as long as that shortened version is still the same thing a customer would naturally try first. Where this goes wrong is when the domain becomes a separate, unrelated word chosen purely for availability, disconnected from what the business is actually called, forcing every mention of the cafe to include a second, different name just for the website.
Deciding to Move
A domain move usually comes from a real, specific trigger: a designer or agency relationship ending and a new one taking over, a platform switch that requires a new setup, or a deliberate rebrand. Whatever the trigger, the actual technical move is the same regardless of why it is happening, and it is worth separating the decision to rebrand or switch platforms from the mechanics of the move itself, since conflating the two is where owners get anxious.
The anxiety is usually about visibility disappearing during the transition, and that fear is not unfounded if the move is handled carelessly. But it is specifically a redirect problem, not an inherent risk of moving at all. A move executed with every old page redirected correctly to its matching new page carries far less risk than owners typically assume. A move executed without that mapping, where old pages simply stop existing and nothing points anywhere, is where the real damage happens.
This is why the framing in this post's title matters: a move is a redirect project first, and everything else, new design, new platform, new branding, is secondary to getting that redirect mapping right. Treat it in the opposite order, focusing on the new site's design while treating redirects as an afterthought, and the visibility risk owners are afraid of becomes much more real.
It helps to name a single person as the owner of the redirect mapping specifically, separate from whoever is handling the new design or the new platform setup. A designer focused on how the new site looks is not necessarily thinking about whether every old blog post has a home on the new structure, and a developer focused on getting the new platform running is not necessarily thinking about search visibility at all. Someone, whether that is the cafe owner directly or whoever manages the site's marketing, needs to own the full list of old pages and confirm every one of them has a place to land.
Moving Safely: The Checklist
Inventory every page on the old site before touching anything. A simple list of every live URL, including pages that might feel minor, an old blog post, a seasonal menu page, a location page, gives you the full scope of what needs to be accounted for rather than discovering gaps after the fact.
Map old URLs to new ones, one to one wherever a direct match exists. A location page on the old site should redirect to the equivalent location page on the new one, not to the new homepage as a generic catch all. A generic redirect to the homepage for every old page is a common shortcut that technically avoids a broken link but loses the specific value each individual page had.
Set up permanent redirects, generally referred to as 301 redirects, from every old URL to its mapped new URL. Every major platform, Wix, Squarespace, Shopify, and WordPress, provides a tool for this, usually found somewhere under marketing, SEO, or navigation settings, though the exact location and terminology varies by platform and can change, so confirm the current path within your specific platform's own help documentation rather than assuming last year's menu structure still applies.
Update Google Business Profile with the new domain, along with any directories, social bios, and other listings that reference the old website address. A perfectly executed technical redirect still leaves confusion behind if your own Business Profile keeps pointing visitors to the old address. Submit the change through Search Console's change of address tool if the new domain is different from the old one, which tells Google directly that a move has happened rather than relying on it being inferred. Then monitor: check periodically that old URLs are still redirecting correctly, since redirects can occasionally be lost during later site updates if nobody remembers they exist.
It is worth testing a sample of redirects directly rather than assuming the setup worked simply because the platform's interface showed no errors. Request a handful of old URLs, spread across different page types, a blog post, a location page, the old homepage, and confirm each one lands on the correct new page rather than an error page or an unrelated default. This kind of spot check, done once right after the redirects are set up and again a few weeks later, catches the small mistakes that a platform's own confirmation screen does not always surface.
What the Census Shows About Naming Patterns
Hillcane's own census gives some honest, dated context on how cafes across the industry name their domains today, though it says nothing about whether any particular pattern performs better, only what is common. Across the recorded urls in a census of more than 1,000 shops across six regions, snapshot dated September 15, 2026, the vast majority of shops have a recorded domain, 1,105 of 1,109 urls filled as of September 21, 2026. Both brand only domains and domains that include a city or a generic word such as coffee or cafe appear throughout that population, reflecting the same two paths described in the naming section above playing out at scale across real, independent cafes.
This is worth making explicit: nothing in that data says one naming pattern ranks better than another, and this post is not going to claim it does. What the pattern does confirm is that both choices, brand only and city or generic inclusive, are common, established paths that real cafes across the country have taken, which should reassure an owner that neither choice is a mistake in itself. The right choice depends on the specific factors covered in the naming section, not on chasing whatever pattern happens to be more common.
Two realistic situations make this concrete. A cafe with two locations weighing whether to add a city name to its existing single location domain, versus keeping the brand name alone and simply adding location pages under it, is really asking a naming question, not a technical one, since either structure can be built correctly once decided. A cafe changing website builders because a working relationship with its current developer or platform ended is a moving question, and the checklist above applies regardless of which naming path the domain already follows.
Whichever situation applies, it helps to write the decision down once it is made, along with the reasoning behind it, somewhere the next person involved with the site, a future developer, a new manager, a future owner, can find it. A short note explaining why the domain was named the way it was, or why a move happened when it did, saves the next person from having to reconstruct that history from scratch, and it is a small courtesy that costs almost nothing to leave behind.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
Should my domain include the city?
It is not the significant ranking lever many owners assume it is; your actual location, hours, and content matter far more to local search than the domain name itself. A city name domain is a reasonable choice for a cafe confident it will stay in that one place. A brand only domain gives more flexibility if the cafe might grow beyond a single town.
What is the biggest risk when moving a domain?
Missing redirects are the biggest risk, not the move itself. A move where every old page is mapped to its matching new page through a permanent 301 redirect carries far less risk than owners typically fear. Damage happens when old pages simply stop existing with nothing pointing anywhere. Name one person to own the full list of old URLs, then test a sample of blog, location, and homepage redirects right after setup and again a few weeks later.
What is a permanent redirect?
Commonly called a 301 redirect, it is a signal set up on the old URL telling browsers and search engines that the content has permanently moved to a new address. Every major platform, including Wix, Squarespace, Shopify, and WordPress, provides a tool for setting these up, though the exact steps and location vary by platform and should be confirmed in that platform's own current help documentation.
Should I redirect every old page to my new homepage?
No. Map each old page to its specific matching new page wherever a direct equivalent exists, a location page to a location page, a menu page to a menu page. A blanket redirect to the homepage technically avoids a broken link but loses the specific value each individual page had, and it is a common shortcut worth avoiding.
What should I do besides setting up redirects?
Update your Google Business Profile first, then every directory, social bio, and listing that still shows the old website address. If the domain itself changed, submit the move through the change of address tool in Search Console so Google is told directly instead of inferring it. A technically correct 301 redirect still leaves confusion when your own profile keeps sending visitors to the old address, so check those listings again during the weeks of monitoring that follow.
How long does it take for search visibility to return after a move?
This post is not going to state a specific timeline, since none is documented as a guarantee. What is reasonable is to expect some observation period measured in weeks rather than days, and to monitor that redirects remain in place during that time rather than assuming the move is finished the moment redirects are set up.
Should I keep my old domain registered after moving?
Yes, keep it registered. The old domain is what carries the 301 redirects, so holding it, even with no site built on it, lets those redirects keep sending visitors and search engines to the matching new pages indefinitely. Letting it lapse after a move can break every redirect at once, undoing the page by page mapping from your inventory of old URLs. Periodic checks that old addresses still redirect also depend on the domain staying in your hands.
Is a generic word like coffee or cafe in a domain a bad idea?
Not inherently. Hillcane's census of more than 1,000 shops across six regions, snapshot dated September 15, 2026, had 1,105 of 1,109 urls filled as of September 21, 2026, and both brand only domains and domains with a city or a generic word such as coffee or cafe appear throughout it. Nothing in that data says one pattern ranks better. It only shows both paths are common, so the five practical naming questions should decide it.
What if I am also changing platforms during the move, not just the domain?
The same redirect checklist applies whether the platform, the domain, or both change at once. Inventory every old URL, map each one to its new equivalent, and set up permanent 301 redirects using the tool your new platform provides, whether that is Wix, Squarespace, Shopify, or WordPress. Then update your Google Business Profile and listings, submit the change of address in Search Console if the domain changed, and keep monitoring that old URLs still land correctly.
How much effort does a domain move take?
For a typical single location cafe site, inventorying pages, mapping them, and setting up redirects is realistically a project measured in hours rather than days, assuming the new site's pages already exist. Updating listings and submitting the change of address adds a bit more time. The ongoing monitoring afterward is a matter of minutes, checked periodically over the following weeks.
Work with Hillcane
The risk in moving a domain is not the move. It is the redirect nobody remembered to set up.
If you are naming a first cafe domain or planning a move, reach Hillcane at hillcane.co/contact or (256) 384-2449.



Comments