Help and documentation

Before you go live

Should I translate everything before connecting my domain

Yes. Translate every language fully first, then connect your domain and go live.

If a visitor lands on a page that has not been translated yet, they get your original language while we translate it in the background, and that first load is slower. Once a page is translated, it is served instantly from cache. Translating first means no visitor ever sees the slow, half-translated version.

Why is one of my pages only partly translated

Because a visitor reached it before it was translated.

When someone opens a page we have never translated, we translate as much as we can in a few seconds, serve the page, and finish the rest in the background. That keeps the page fast instead of making the visitor wait. The next visitor gets the complete version.

If you see this on a live site, it means pages went live before they were translated. Run a full translation from the Languages screen and it resolves.

How many languages should I add at once

If your site has more than about 500 pages indexed by search engines, add around five languages first, wait until they are indexed, then add more in small batches.

Adding many languages to a large site at once creates a very large number of new pages for search engines to process, which slows indexing and can affect how your original language ranks in the meantime. On a small site this does not matter.

Translating

What is the difference between the two translation methods

Faster returns results in seconds to a few minutes. It costs more per word.

Background costs about half as much, and results arrive in bulk. For a few hundred strings that is usually within the hour. For several thousand it can take hours. Choose it when you are translating everything and are not waiting at the screen.

Both produce the same translation quality. The difference is speed and price, not output. Both are safe to rerun: only untranslated strings are ever sent.

How long until translations appear

A page is translated the first time it is requested, usually within seconds. Bulk-translating a large catalogue takes seconds to a few minutes with the faster method; the background method returns results in bulk, usually within the hour, a few hours for very large jobs, at about half the cost.

Can I edit the translations

Yes, all of them. The editor shows source and translation side by side and saves as you type, and your manual edits are never overwritten by automatic translation. You can also invite translators with access limited to specific languages.

How do I add or remove a language

Any time, under Translate, then Languages. Adding a language creates its subdomain or path and translates your content; removing one takes its pages offline but keeps the stored translations in case you bring it back. Languages are unlimited on every plan.

What does publishing do

Publishing clears the cached copies of your pages so visitors see your latest text immediately.

It is not a gate on whether translations are live. A page nobody has visited yet always gets the newest text. But a page already cached keeps serving what it had, for up to a day, until it is published or the cache expires.

Bulk translations publish themselves when they finish. Manual edits do not, so you decide when your changes go live.

Will my translations be overwritten if I edit the original text

No. If your source text changes, we flag the translation for review and leave it exactly as it is. Your work is never overwritten automatically. You can filter for changed sources on the Translations screen and decide what to update.

Do I pay for my original language

No. Your original-language pages are served by your own site and cost nothing. You pay only for translated pages.

What is the difference between word credits and page view credits

Word credits are spent once, when a piece of text is translated for the first time. Retranslating the same text does not cost again. Editing, republishing, and serving already-translated content never use word credits.

Page view credits are spent the first time we serve a piece of your translated site, on proxy plans only. After that it is cached, so every visitor after the first is free.

What happens when I run out

Nothing you have is lost: stored translations stay stored and keep serving normally.

If word credits run out, translation pauses: new or changed text waits, and new or unfinished pages show your original language until you add a one-time pack from billing, upgrade, or allow going past your allowance. If page view credits run out on a proxy plan, your billing setting decides: pause, so visitors see your original pages, or continue and charge a page view pack.

We show a banner in your dashboard when this happens, so you are never left guessing why new pages appear in the original language.

Connecting your domain

What is a DNS record

It is an instruction that tells the internet where to send people who type your domain, and adding one takes about two minutes. You add these where your domain is managed, which is either the company you bought it from or a separate DNS provider.

How do I find where my domain is managed

Check where you bought the domain. Look at which web or hosting service you pay each month. Ask whoever set up your website. Or search your email for "domain", "renewal", "DNS", or "nameserver". Common providers are GoDaddy, Namecheap, Cloudflare, Google Domains, Ionos, OVH, Gandi, Squarespace, Hover, Porkbun, and Shopify.

Where is the DNS panel at my provider

• GoDaddy. Sign in, open My products, then click DNS next to your domain.
• Namecheap. Sign in, open Domain list, click Manage next to your domain, then open the Advanced DNS tab.
• Cloudflare. Sign in, pick your domain, then open DNS in the left menu.
• Shopify managed domains. In your Shopify admin go to Settings, then Domains, click the domain, then Edit DNS settings.

What are the records I am asked to add

• CNAME, routing. Points a name at another name. This record points the host you connected (a language subdomain, your www address, or your root domain) at our edge, edge.ultimsuite.com, so visitors reach the translated pages. A CNAME on www or on a subdomain works at every provider. At a root domain, providers that support it call the equivalent record ALIAS or ANAME; providers without those types (Ionos and OVH, for example) cannot point a root domain this way, so connect www instead.
• CNAME starting with _acme-challenge, certificate. Lets us issue and renew the HTTPS certificate for your translated pages automatically. You never handle certificates yourself. Leave this record in place permanently. It is not a one-time step: the certificate renews on a schedule and the check runs again every time, so deleting the record months later takes your translated pages offline.
• TXT, verification. A one-time proof that the domain is yours. It carries a code we generate and check; it changes nothing about how your site works.

A caution for root domain records: a CNAME, ALIAS, or ANAME at the root replaces what is there, it is not added alongside. Never place one next to existing MX or TXT records at the root; some providers accept it, and email on the domain then breaks. Replace only the A or CNAME record that serves the website, and leave MX and TXT records untouched. When in doubt, connect www instead.

Do I need to tell you where my site is hosted

No. We work it out during the scan and show you what we found.

It is worth knowing what we are looking at, because it is easy to assume connecting a domain moves your site. It does not. Your pages stay exactly where they are. What changes is that your domain sends visitors to us first, and we then ask your existing host for the same pages, in the same way a visitor would, and translate them on the way through. Nothing about your site is copied, moved, or rebuilt.

We record the address your pages come from before your domain changes, because afterwards your domain points at us and that address is no longer visible to anyone. That is why the connection screen shows it, and why it is worth checking again if it was recorded a long time ago.

If we ever have it wrong, there is a manual override on the connection screen under "Set it manually". Almost nobody needs it.

Why does the connection screen mention a canonical link

Some sites share a server address with many other sites. To be certain we are always fetching your pages and not a neighbour's, we look for the canonical link your pages publish, which is the line of code that states a page's own address. It is a standard part of most themes and good for search engines anyway.

If your pages do not publish one, everything still works. What we lose is a safety check: we cannot tell your site apart from others on the same server, so we cannot automatically spot the rare case of a hosting address being reassigned. Adding a canonical link, or asking whoever built your site to, switches that check back on.

How long does connecting take

Connecting happens in two steps, and the screen only ever asks for one at a time. First you add the records that prove the domain is yours and get your certificate issued; nothing your visitors see changes at this stage, and the certificate usually arrives within minutes of those records going live. Then the screen shows the routing record, the one that actually sends visitors to us. After you add that, DNS usually takes 30 minutes to an hour to spread, sometimes longer.

The connection screen checks for you and marks an address Active once a real request to it comes back translated, so you never have to guess. You will not see a certificate warning on a new language, because the record that would expose one is not offered until the certificate exists.

My domain is on Cloudflare. Anything special

Yes, one thing. The records pointing at us must be set to DNS only, the grey cloud, not Proxied, the orange cloud. A proxied record sends visitors to Cloudflare's own network instead of ours, so the connection never activates and certificates cannot be issued. Your site loses nothing by using DNS only: translated pages are already served from an edge cache.

How do I set up subdirectories

1. In your project settings, open Connection, choose Subdirectories, enter your website domain, and pick the host to connect: www or your root domain.
2. At your registrar, add the two records the screen shows first: the TXT verification record and the _acme-challenge CNAME. Nothing your visitors see changes at this step.
3. Wait for your certificate. The screen shows the routing record only once the certificate exists: a CNAME pointing the host you chose at edge.ultimsuite.com (www works at every provider; a root domain needs your provider's ALIAS or ANAME type). That is the record that moves live traffic, so set the lowest TTL your provider offers and copy the current value somewhere safe before you change it.
4. Add it, then click Check status. The address turns Active once a real request to it comes back translated.
5. Your translated pages appear under language paths like yoursite.com/fr/. Pages without a language prefix, including your whole original site, pass straight through to your website unchanged.

Connecting www? Two extra minutes of setup: make www your primary domain on your platform (on Shopify: Settings, then Domains, set the www domain as primary; Shopify then redirects the root domain automatically), and if your platform does not redirect for you, add domain forwarding from the root to www at your registrar. GoDaddy, Namecheap, Ionos, and OVH all offer it in their domain dashboard.

I connected www. What happens to my root domain

Your root domain should redirect to www so visitors and old links still reach you. If www is your platform's primary domain, most platforms redirect automatically; Shopify always redirects to the primary domain. Otherwise use your registrar's domain forwarding: GoDaddy (Domain settings, then Forwarding), Namecheap (Domain, then Redirect domain), Ionos (Domains and SSL, then Forwarding), and OVH (Web Cloud, then Redirection) all include it at no cost.

How do I set up language subdomains

1. In your project settings, open Connection, choose Language subdomains, and enter your website domain.
2. At your registrar, add the records the screen shows first: the TXT verification record and, for each language, one _acme-challenge CNAME. These prove the domain is yours and get the certificates issued. Nothing your visitors see changes yet.
3. Once a language's certificate exists, the screen shows its routing record: a CNAME pointing the subdomain (like fr.yourstore.com) at edge.ultimsuite.com. Add it, then click Check status. Each subdomain turns Active once a real request to it comes back translated.
4. Each language appears on its own subdomain, like fr.yourstore.com. Your main domain never touches us, and there is nothing to add in your store platform's admin.

Every language needs BOTH records, and the second one is the easy one to miss. The _acme-challenge record from step 2 only gets the certificate issued. The routing record from step 3 is what actually sends visitors to us. A language with only the first will show a valid certificate and still serve nothing, which reads like success and is not. Seen for real: a merchant added all five _acme-challenge records correctly, every certificate went active, and no language served, because none of the five routing records existed.

Note the name field for a subdomain of a subdomain. If your store is at shop.example.com, the routing record for French is named fr.shop, not fr. Most registrars append the rest of the domain for you, so typing fr there creates fr.example.com, which is not the host we serve.

Will this slow my site down

No. Your original site is served exactly as before. Translated pages are served from an edge cache close to your visitors and typically load as fast as your site itself, without the flicker of client-side translation widgets.

Is my original-language traffic affected

No. With language subdomains your main domain never points at us at all. With subdirectories, pages without a language prefix pass straight through to your site untouched.

What is the difference between subdirectory and subdomain

Subdirectory puts your translated pages on your own domain under a language path, like yoursite.com/fr/. Best for search engines, because they treat it as part of your main site. Included in the proxy plans.

Subdomain puts them on a language subdomain, like fr.yoursite.com. Simpler to set up and available on every plan, slightly weaker for search than a subdirectory.

Why can I not use a subdirectory on my domain

Some DNS providers do not allow the kind of record a root domain needs to point at another service. Ionos and OVH are common examples. If yours does not, you have three options.

The first keeps every address you have: put your domain on Cloudflare's free plan. You change only the nameservers at your current provider, the domain itself stays registered and billed where it is, your DNS records move over with you, and the whole thing takes about twenty minutes. Cloudflare allows the root-domain record your provider cannot create, so subdirectory delivery works on your bare domain from then on.

The other two: use a language subdomain, which changes none of your existing addresses, or point www at us instead, which is stronger for search but means making www your main address and redirecting your existing pages.

We check your provider when you connect and tell you which options you have.

Are my Shopify order and shipping emails translated

Not by us, and it is worth explaining why rather than leaving you to wonder. Shopify composes and sends those emails from its own systems straight to your customer, so they never travel through us and there is nothing for us to translate on the way past.

Shopify can translate them itself, for any language you have published in your Shopify admin. Go to Settings, then Notifications, choose the notification, and click Localize. Shopify then sends each customer the version matching the language they ordered in.

That last part is the catch worth knowing: Shopify only uses a translated notification for a language you have published in Shopify. Languages you serve through us alone are not published there, so notifications for those customers arrive in your default language.

My site is behind a firewall or bot protection

Some firewalls block our crawler or our edge requests. If discovery finds nothing, or pages fail to load, allow our requests in your firewall rules. Contact us and we will tell you exactly what to allow.

Why did the connection check say it could not confirm my site

Before we send visitors through us, we fetch your site the way a browser would and check that the page which comes back is recognisably yours. The strongest signal is the address your own page claims as its canonical one.

Some pages do not publish that. An error page from a shared hosting platform, a holding page, or a server that declines the request all come back looking identical to each other and to nothing in particular. We treat that as "could not confirm", never as "confirmed", because the alternative is switching your live storefront over to an address that had just told us to go away.

If you see this, your site is almost certainly fine. It usually means the check reached a shared address before your own DNS change had finished spreading. Wait a few minutes and run it again. If it keeps saying the same thing, tell us and we will look: it is a signal worth chasing, not one to click past.

The language selector

How does the selector appear on my original-language pages

Translated pages get the selector automatically. Your original pages need one of two things.

Add a snippet to your site. One line of code, pasted once. Works with any connection, costs nothing extra. This is the better option and we recommend it.

Let us serve your original pages. Nothing to add to your site. Available with a subdirectory connection. Your original pages then count towards your page view allowance, so your page view usage grows faster and may cost more.

Can I use my own language switcher instead

Yes. If you already have a language menu in your theme, or kept one from another tool, you can drive it from your own links and turn ours off. The next question lists the calls available.

How do I drive the selector from my own code

Call these from any click handler on a page that loads our script. The language codes are your project's own; fr below is an example.

• window.ultimTranslate.setLocale('fr') switches the language and remembers the visitor's choice.
• window.ultimTranslate.goToLocale('fr') switches without recording a preference.
• window.ultimTranslate.getLanguages() returns your configured languages, with native names and codes.
• window.ultimTranslate.on('localeChange', handler) runs your handler whenever the visitor switches language.

How do I put the selector in my burger menu

Try the picker first. If the position holds, you are done. If the selector does not end up where you picked, or moves later, use the placement element instead: paste <div data-ut-selector></div> into your theme at the exact spot inside the menu, and the selector renders there. Nothing is guessed at page load, so it stays put.

Copy the element from Settings, Selector, using the "Paste an element" placement method. Each selector has its own element, so copy the one shown for that selector.

One thing to expect on some sites: many burger menus are built so the menu only exists on the page once a visitor taps it open. If yours works that way, pasting the element in is not enough on its own, because the menu is not in the page for us to render into until it opens. Your developer needs to change the menu so it is always in the page and simply hidden while closed. That is a small change, but it is a change to the menu itself rather than to anything you paste, so it is worth mentioning when you hand the element over. The copyable developer instruction in Settings, Selector explains exactly what to do, including how to keep the hidden menu accessible.

We hit this on our own site, so it is a normal thing to run into, not a sign anything is wrong.

Which method should I use where

The picker works well for positions that are on the page when it loads: header bars, footers, sidebars, utility bars.

A burger menu, drawer or modal builds its contents only when a visitor opens it, and many site builders rebuild that markup on every open. Picking inside one works on some sites and not others, so try it, and if it does not hold, the placement element is the reliable route.

The element route needs somewhere to paste HTML. It works on Shopify (theme code), WordPress (theme template or a Custom HTML block), Webflow (an Embed element), Framer (an embed inside the nav component), and any site where a developer can edit the template, including Next.js and other frameworks. It is not available inside the mobile menu on Wix, where an HTML embed renders in an iframe, or on Squarespace, where the mobile menu markup is not editable on most templates. Google Tag Manager can load our script but cannot reliably place an element inside a menu.

The picker put my selector in the wrong place

That happens when the position you picked looks the same as another spot on the page, which is common inside menus: the same links often appear in both the header and the menu. Use the placement element for that selector instead. It is exact, and it cannot drift.

I changed the selector but my site still shows the old one

Configuration changes reach live sites within about five minutes. If you want to see a change immediately, use the clear cache button in the selector settings.

Shopify

Is my checkout translated

It depends on who runs your checkout. If your checkout is ordinary pages on your own site, we translate it like any other page and there is nothing to configure. If your platform hosts and controls the checkout, as Shopify does, we cannot touch it and nor can any other translation service: it handles payments. That is a boundary of the platform, not a limit of ours, and it does not apply to every merchant.

We pass your visitor's language to Shopify when they reach checkout, and Shopify serves its own translated checkout in that language. Shopify ships its checkout in more than 30 languages, and this works even with no extra languages set up in your Shopify admin. There is nothing for you to configure.

How do I change the wording on my checkout

In your Shopify admin, go to Sales channels, then Online Store, then Themes. Open the three dots menu on your live theme and choose Edit default theme content, then the Checkout and system tab.

To edit a language other than your default, temporarily change your store's default language in Settings, then Languages, edit the wording, then change it back. If you are comfortable in theme code, you can edit the locales json files directly instead.

Do language subdomains need anything special on Shopify

No. You do not need to add anything in your Shopify admin, and you should not.

We used to say that Shopify's spam protection would reject forms sent from your translated pages unless you registered each language subdomain in Shopify. We tested that on a live shop and it is not true. With nothing added to the Shopify admin, a contact form on a language subdomain delivered its email, a newsletter signup on a subdirectory site recorded the subscriber, and a complete order went through with the checkout in the shopper's language. Shopify's spam protection was switched on the whole time, and Shopify's own documentation sets no condition about which domain a form is submitted from.

Please do not add your language subdomains under Settings, then Domains. Shopify's connect-domain wizard will ask you to point that subdomain at shops.myshopify.com. That replaces the record that sends visitors to us, and your translated pages go offline the moment it takes effect. There is nothing to gain from adding them and a working site to lose.

If you ever see a form on a translated page behave differently from the same form on your main site, tell us and we will look at it. It is not something you need to pre-empt by changing your domain settings.

A customer came back from checkout and the site was in English again

After checkout, your store platform sends the customer back to your main address rather than to the language they were reading. Links like "back to the shop", and the account link in an order confirmation, all point there.

What happens now depends on how your translations are delivered.

If your languages live in folders (yourshop.com/fr/), we handle it. Their saved language is remembered, and a customer who chose French and is handed your main address is taken back to French automatically. Nothing to set up.

If your languages live on subdomains (fr.yourshop.com), your main address never passes through us, so we cannot see that visit at all and cannot redirect it. The one thing that can is the small snippet on your own pages: it runs in the customer's browser, reads the language they chose, and sends them back to it.

If you have not added the snippet, this case cannot be fixed, by us or by you, and a customer returning from checkout will see your default language until they choose again. That is a real limit of the subdomain setup, not something waiting to be built. If your customers use checkout, and on a shop they will, adding the snippet is worth the five minutes.

A customer who deliberately picks your default language in the selector is left alone in every case. Choosing English is a choice, and we do not override it.

Which pages does my store platform control, and are they translated

Some pages belong to your store platform rather than to your theme: checkout, sign in, account, and a few others. We do not translate those pages, because your platform renders them itself. What we now do is tell your platform which language the visitor is reading in, so it renders its own page in that language instead of your shop's default.

That covers checkout today. Customer sign in and the account area are declared and ready but not yet working: a visitor reading in French who clicks through to sign in is still handed a link that says English, and arrives in English. We know exactly which link it is and we are working on it. If your customers use accounts, expect that one hop to be in your shop's default language for now.

Two pages cannot take a language and will stay in your shop's default: the bot check your platform shows on suspicious traffic, and the storefront password page. That is a limit of the platform, not something waiting to be built.

Product names, prices and other content that comes from your store data are a separate matter, covered just below.

Why are product names still in the original language at checkout

Because product names come from your store data, not from Shopify's checkout wording. Shopify's checkout translation covers its own labels and buttons. To translate product names at checkout, translate them in Shopify's own product translations.

Keeping things up to date

I added new products. Do I need to do anything

We check your site regularly and pick up new pages automatically. You can also run discovery yourself at any time from the Translate settings, which is instant and free.

New text is found automatically, but translating it costs credits, so we do not translate it without asking. Turn on automatic translation in the settings if you would rather we did.

Does discovery cost anything

No. Reading your site to find text is free and uses no AI. Only translating costs.