Universally is built so each language version is a real, indexable page rather than a client-side overlay. Everything on this page happens automatically, with no SEO configuration to do.
What you get without configuring anything
| A distinct URL per language | /es/pricing/ is its own page, so search engines can index it separately from /pricing/ |
| Server-rendered translations | translated text is in the HTML, not injected by JavaScript after load, so crawlers see it |
| hreflang tags (WordPress) | each page declares the other languages as alternates, so they read as one page rather than duplicates. Added by the WordPress plugin; an API integration emits its own |
| Translated metadata | <title>, meta description, Open Graph and Twitter card tags |
| Translated structured data | text fields inside JSON-LD, so rich results appear in the right language |
Translated alt text |
image alternatives are translated along with visible content |
The last three are the ones people expect to have to do by hand. See Multilingual SEO metadata for the exact fields.
What you should still decide
Which URL segment each language uses. Languages are served in subdirectories (/es/), and you choose the segment: the language code, the region code, or your own. See Subdomains and subdirectories.
Which pages to exclude. Checkout and account pages carry no SEO value and are better left untranslated. See Exclude pages.
Your terminology. Brand names, product names and terms of art should be consistent across every language. A glossary rule enforces that everywhere, including in text translated later. See Glossary rules.
What Universally does not do
It does not submit anything to search engines. Add your translated URLs to your sitemap and submit that as usual.
It does not do keyword research per language. Translation renders your existing copy faithfully; it does not rewrite it to target different search terms in each market. If a market needs different keywords, that is a content decision.