Universally suits sites where the content is already written and the problem is serving it in other languages, without maintaining a second copy of the site. If you are weighing it up, the questions below decide it faster than a feature list.
It fits well when
Your content changes and you don't want to re-export anything. Pages are translated the first time someone requests them in a language, and edits are picked up on the next visit. There is no export, no sync step, and no file to keep in step with the site. See How Universally works.
You need the translated pages indexed. Each language gets its own URL and the translated text is in the HTML, not injected by JavaScript after load, so crawlers see it. See Multilingual SEO overview.
Whatever your site runs on. WordPress has a plugin, so it is the quickest start. Every other platform connects through the same REST API the plugin itself uses, and native integrations for more platforms are on the way. See Supported platforms.
Terminology has to stay consistent. Brand names, product names and terms of art can be pinned per language, and the rule applies to text translated later too. See Glossary rules.
You manage several sites, or several people do. Sites group into projects and workspaces, with roles for who can add languages, edit translations and see billing. See Projects, workspaces and sites and Roles and permissions.
You need a language Google Translate handles badly. 110 languages, including right-to-left ones, with regional variants where the wording differs by country. See Supported languages and Right-to-left languages.
It is the wrong tool when
You want the copy rewritten per market, not translated. Translation renders your existing wording faithfully in another language. It does not re-pitch the page for a different audience or target different search terms. That is a copywriting job, and no glossary rule substitutes for it.
You need translations as files. There is no bulk export to send to a translation vendor and no file to upload back. Editing happens in the dashboard. See Edit translations manually.
If you are not on WordPress
Nothing here is WordPress-only. The plugin is a convenience on top of the API, and the API is the whole product: send content, get it back translated, in any of the 110 languages.
Today, a non-WordPress site connects through the Translator API, which is a piece of server-side work rather than an install. Sites on Shopify, BigCommerce and Wix can go this route wherever they can reach their own HTML output.
If your pages are assembled in the browser, send those strings through the API rather than relying on the page markup, since text your server never sends is not there to be translated. Coverage for dynamic content is being expanded. See Translate dynamic and JavaScript content.
Soon, native integrations for more platforms, along with subdomain and domain-level translation beyond WordPress. If your platform is not covered the way you want yet, it is worth asking where it sits on that list. See Get support.
What it costs you to find out
The free plan translates a limited number of words into one language, which is enough to see real pages in a real language on your own site. Word totals are prepaid and do not reset, so a trial you abandon does not expire on you. See Plans and pricing and Usage limits.