A translated page is not automatically a searchable multilingual page. It also needs a stable URL, appropriate metadata, a language relationship, internal links and an update process.
When those responsibilities are separated, agencies publish incomplete language versions, conflicting canonicals or hreflang sets that do not match the available content.
This multilingual WordPress SEO workflow keeps translation, publication and technical validation in one controlled sequence.
Define language and market scope
Distinguish language from region before creating URLs.
English for the United Kingdom and English for Australia may share a language but require different offers, spelling, currency or legal information. French content may serve several countries through one version or require regional variants.
Record:
- language and optional region code;
- intended audience and market;
- URL pattern;
- source language;
- responsible reviewer;
- content and metadata scope;
- fallback behaviour when a translation is missing.
Do not launch a language switcher before deciding what each option represents.
Use separate, stable URLs
Google recommends different URLs for language versions rather than changing page content only through browser settings or cookies.
Subdirectories such as /fr/ or /de/ are often practical for one WordPress installation, but the correct choice depends on hosting, market strategy and architecture. Avoid URL parameters for primary language segmentation where a clearer structure is available.
Translated slugs can help users, but they require consistent redirect and internal-link handling when they change.
Use one eight-stage workflow
1. Qualify the source
Translate only approved, current content. Resolve major SEO and factual problems in the source first.
2. Create the language record
Reserve the target URL and relationship without presenting an empty or source-language clone as a complete translation.
3. Translate content and structured fields
Include headings, body, buttons, image alternatives, forms, product fields and other relevant components.
4. Translate metadata
Create a target-language title, description, social metadata and slug based on local reader intent. Do not mechanically translate character by character.
5. Review and approve
Check meaning, terminology, claims, links, layout and client-specific requirements.
6. Publish technical relationships
Confirm self-canonical URLs and complete, reciprocal hreflang relationships for the available versions.
7. Verify the rendered page
Inspect public HTML, language selector, forms, internal links, structured data and sitemap entries.
8. Monitor and maintain
Track source changes, translation status, crawl issues and outdated language versions.
Implement hreflang carefully
Google’s guidance requires each language version to list itself and the corresponding alternatives. Relationships should be reciprocal, and URLs must be fully qualified.
For every page set:
- use a supported language code and optional region code;
- include the current page itself;
- include the same set on corresponding versions;
- point to canonical URLs in the appropriate language;
- add
x-defaultonly where a genuine fallback or selector makes sense; - remove alternates for translations that do not exist or remain incomplete.
Do not use hreflang to compensate for source-language clones. Google notes that localised versions are considered duplicates when the main content remains untranslated.
Align canonicals with language versions
A genuine translated page should normally use a self-referencing canonical. Pointing every translation to the source language can prevent the language version from being treated as the preferred URL.
For an untranslated fallback, the agency may deliberately use noindex and a source-language canonical until real translated content exists. The exact approach should be consistent across routing, metadata, sitemap and hreflang output.
WpAgencyKit Translate includes controls for untranslated-language handling, while WpAgencyKit SEO coordinates sitemap and metadata output. Verify the current configuration on each site.
Translate intent, not only words
Keyword demand, terminology and customer expectations vary by market. A literal translation of the source title may be grammatically correct but commercially wrong.
For important pages:
- confirm local terminology;
- adapt the page promise without inventing capabilities;
- review currency, measurements and availability;
- preserve regulated or contractual meaning;
- write a natural target-language title and description;
- use a reviewer who understands the content risk.
The user handles WpAgencyKit’s final translated versions, but the source article and SEO structure should make those adaptations possible.
Maintain multilingual internal links
Where an equivalent target-language destination exists, link to it. Avoid sending a reader back to the source language unnecessarily.
Your review should identify:
- navigation and footer links;
- contextual links inside content;
- product and category relationships;
- form confirmation and account pages;
- downloadable documents;
- redirects from old translated slugs.
Broken or mixed-language journeys damage usability even when hreflang is technically correct.
Build a source-change process
Every source update should answer:
- Which translations are affected?
- Is the change material or cosmetic?
- Should the translated page remain published while waiting?
- Who updates and approves each language?
- How is completion recorded?
Use translation status and change history rather than assuming every language remains synchronised automatically.
WpAgencyKit Translate supports WordPress content and string translation, multiple providers, translation memory and multilingual routing. Use those capabilities inside a documented review process.
Final QA checklist
- target URL is stable and crawlable;
- visible content is genuinely translated;
- title, description, social metadata and slug are reviewed;
- canonical matches the intended target-language URL;
hreflangis reciprocal and complete;- sitemap includes only intended indexable versions;
- language selector reaches the correct page;
- internal links prefer available same-language destinations;
- forms and dynamic content are tested;
- source changes have an owner and status.
Keep language versions truthful
Multilingual SEO is not a layer added after translation. It is the publication system that connects the right content, URL and audience.
Agencies that coordinate scope, translation, metadata, canonicals, hreflang, links and maintenance can grow language coverage without creating a portfolio of misleading or abandoned pages.