One address per language
Google recommends giving each language version its own web address instead of switching language with a cookie or the visitor's browser setting. A visitor can then link to, bookmark and share the exact language they are reading, and a search engine can crawl each version. Google describes three structures: a country-code domain, a subdomain and a subdirectory, and says URL parameters such as ?loc=de are not recommended. For a small business site on one domain a subdirectory is the simplest to set up and maintain, with the trade-off that the server is in one place and it is harder to separate the sites. Decide the pattern once, because changing it later moves every address.
- A subdirectory pattern looks like /de/ followed by the page path.
- Keep the same path under each language where you can, so counterparts are easy to map.
Language tags that point both ways
Language annotations tell search engines which pages are versions of each other. Google says HTML, HTTP header and sitemap methods are equivalent and that using more than one adds nothing. The rule that causes most failures is reciprocity: each language version must list itself and every other version, and if two pages do not point to each other, the tags will be ignored. Addresses in the tags must be fully qualified, including https and the host. Language codes use the two-letter ISO 639-1 form with an optional region, and a region on its own is not valid. An x-default entry can name the page for visitors who match none of your variants, such as a language selector page.
- Fetch the source of both pages in a pair and check that each lists both.
- Use only valid codes; invented ones are ignored.
Do not guess a visitor's language for them
Google advises avoiding automatic redirects between language versions, because a redirect based on a guess about the visitor can stop both people and crawlers from reaching every version. It specifically says not to use IP analysis to adapt content, and notes that its crawler usually requests pages from the United States without a language preference header, so it will not see versions hidden behind such logic. A visible switcher on every page, linking to the counterpart of that page and not to the home page, serves visitors and crawlers equally. Google also suggests links for choosing a region or language on all pages for the people who land on the wrong version.
- A browser-language suggestion banner that the visitor can dismiss is not a redirect.
- Test the switcher on every translated page, not only on the home page.
Translate the content, not just the frame
Google notes that translating only the navigation and footer while the main content stays in one language can harm the experience, and that the same content may then appear repeatedly in results under different frames. Each page should use one language for both content and navigation. It also says Google detects a page's language from the visible content, not from the HTML lang attribute or the address. The structure in this guide therefore cannot compensate for text that is not really translated: if only the menu is translated, do not publish that version.
- Publish a language version of a page only when its main text exists in that language.
- Plan for who updates both versions when the page changes.
Before you touch the live site
Google's guidance covers the target structure; it says nothing about how to reach it on a working WordPress site, and a multilingual plugin does more than add pages: it assigns a language to your existing pages and menus. This guide has not checked any plugin's documentation, so treat what follows as a checklist of things to verify with the plugin you choose, not as a description of what any plugin does. Work on a staging copy first. Before anything changes on the live site, take a full backup of the files and the database and try restoring it onto a spare copy: the WordPress backup handbook says to back up always before an upgrade and that you need both the database and the files to fully restore a typical site. List your existing main-language addresses (the home page and each page you will translate) with their status, title and preferred address, and check that every one is unchanged after the set-up, on staging and again on live. Some set-ups add a language prefix to the main language as well, or move the front page, and either would change addresses that are already indexed, so the choice of whether the main language gets a prefix is made before the set-up, not after. Applying the staging set-up to the live site by copying the staging database over it would overwrite anything added on live since the copy was made, so apply the settings by checklist during a short content freeze. Finally, rehearse the way out: remove the set-up on a fresh staging copy and write down what is left behind. Whether deactivating a plugin leaves translated pages, menu entries or settings in place depends on the plugin, so find out on the copy and do not assume deactivation returns the site to its earlier state.
- Staging first; a verified, test-restored backup before the live change.
- An inventory of the main-language addresses that must stay identical, checked before and after.
- A rehearsed removal on a fresh copy, with the leftovers listed.
What the paid job does and does not do
The multilingual job has a published test price of GBP 790 and sets up one added language for up to ten named pages, the menu and the footer, using text you supply. It is accepted when each page pair has separate addresses that return HTTP 200, every pair lists itself and its counterpart both ways, the switcher leads to each page's counterpart, the sitemap lists both versions and no automatic redirect by location or browser language occurs, and the existing main-language addresses return the same status, title and preferred address before and after. It requires a test-restored backup before the live change, keeps every existing main-language address unchanged, and includes a rehearsed removal on staging. It does not translate text, cover more than one added language, translate a shop checkout or promise rankings. Prices are untested proposals and payment follows the agreed checks.
- Send the language, the page list and who will supply the text.
- Say whether a half-finished translation or a plugin already exists.
Sources and limits
- Google Search Central: localized versions of your pages Checked 2026-10-11.
- HTML, HTTP header and sitemap annotations are equivalent; each language version must list itself and all other versions, and if two pages do not point to each other the tags will be ignored.
- Language codes use ISO 639-1 with an optional ISO 3166-1 Alpha 2 region; alternate URLs must be fully qualified; x-default is for users matching none of the listed variants; Google does not use hreflang or the HTML lang attribute to detect a page's language.
- Google Search Central: managing multi-regional and multilingual sites Checked 2026-10-11.
- Google recommends a separate URL for each language version rather than cookies or browser settings, and describes subdirectories, subdomains and country-code domains as options; URL parameters are not recommended.
- Translating only boilerplate while the main content stays in one language can harm user experience; avoid automatically redirecting visitors based on a guess about language, and do not use IP analysis; offer links so visitors can choose a version.
- WordPress developer handbook: back up your WordPress site Checked 2026-10-11.
- It says to back up the database regularly and always before an upgrade, that a backup has two parts, the database and the files, and that you need both to fully restore a typical WordPress site.