Multilingual WooCommerce SEO Starts with Correct Product Data

SEO cannot repair a translated catalog whose products are connected to the wrong languages. Before keyword work, a multilingual WooCommerce store needs correct product identity, WPML relationships, URLs, categories, and buyer-facing content.

An import affects those foundations. That does not mean every import problem causes a ranking loss; it means the output deserves technical and editorial QA before publication.

Product identity comes first

For normal cross-store product matching, use SKU. Matrix ID / External ID can identify multilingual Matrix records. WordPress post IDs and WPML translation-group IDs are local to a site.

If identity is wrong, a repeat import can create duplicates. Search engines may then discover several similar product URLs, while the team struggles to decide which one is authoritative.

Run a small staging import twice and confirm the second pass updates the same products.

WPML connects separate language-specific product records. The language switcher, translated archives, and related internal links depend on those relationships.

Matrix Mode gives the import explicit language columns such as title|en, title|de, and description|pl. When WPML is active, Shirely uses WPML-aware paths to create or update the related records.

After import, switch between every version of a representative product. A correct title does not compensate for a switcher that opens an unrelated item.

Slugs and categories create the URL structure

Translated slugs and categories influence how products are reached and understood. Category Matrix should preserve parent-child hierarchy with source_id and parent_source_id, not destination term IDs copied from another store.

Check translated category archives and breadcrumbs. Make sure products appear where intended and internal links lead to the correct language.

Do not change established public slugs casually. A slug migration needs redirects, internal-link updates, canonical checks, and sitemap review beyond the import itself.

SEO fields need explicit language values

Shirely supports mapped Yoast and Rank Math SEO fields within its documented contract. Use language-suffixed Matrix columns when titles and descriptions differ per language.

Review both storage and output. A value present in the CSV is not proof that the theme or SEO plugin renders it. On staging, inspect:

the HTML title;
meta description;
self-canonical;
robots directive;
structured data;
social title and description where used.

Avoid copying one language's metadata across every version merely to fill a field.

Content quality remains human work

A translated product should answer the buyer's question naturally, use accurate terminology, and avoid unsupported claims. Search-focused phrasing is not a substitute for a useful description.

Have language and product owners review a sample in its final layout. Long translated headings, tables, and variation labels also need mobile testing.

Publication should be a separate gate

Import to staging, verify the records, then decide what is ready to publish. Preserve draft and scheduled statuses unless the release plan explicitly changes them.

If you later automate a supported import with Shirely 1.3, use Run now and Run History first. WP-Cron does not guarantee exact timing, and overlapping jobs that write the same products, terms, or WPML/WCML groups should run sequentially.

A concise SEO import check

stable key matches the intended product;
one translation exists per intended language;
language switching is correct in both directions;
slugs and category hierarchy are reviewed;
title, description, canonical, robots, and schema render correctly;
internal links stay in the intended language;
no staging URLs or source notes are visible;
sitemaps change only where planned.

For metadata fields, read the SEO and Meta Fields documentation. For relationship problems, use the WPML language-switcher diagnostic.