Running a multilingual website can be a rewarding but technically challenging endeavor. One issue that often flies under the radar until it impacts SEO or usability is the unexpected alteration of URL slugs, especially after cloning a site. If you’re using TranslatePress, a fantastic WordPress plugin for managing multilingual content, you may have encountered a mysterious suffix—“-2”—appearing in your translated slugs. This minor-looking change can trigger a cascade of issues, ranging from SEO penalties to broken hreflang configurations. After facing this challenge, we crafted a URL normalization script that resolved these inconsistencies and restored sanity to our site’s structure.
TL;DR
Cloning a WordPress site that uses TranslatePress may duplicate translated slugs, generating unwanted “-2” suffixes that disrupt the URL structure. This leads to duplicate content warnings, broken hreflang mappings, and SEO penalties. A custom script was created to normalize URL slugs across all languages and clean up the slug database. The fix restored canonical slugs and repaired hreflang pairs, stabilizing the site’s multilingual structure.
Understanding the TranslatePress Slug “-2” Issue
TranslatePress stores translated slugs directly in the WordPress database, tying them to a unique post, page, or taxonomy term. Normally, this setup works beautifully. But problems arise in cloned or migrated environments where duplicate slugs collide with existing entries. WordPress, by default, appends a “-2” suffix to make slugs unique—for example, turning about into about-2 or the French version à-propos into à-propos-2.
This behavior is logical for new content, but disastrous when applied to translated pages. For example:
- Original site’s Spanish slug for “Services”:
/es/servicios - Cloned site’s Spanish slug becomes:
/es/servicios-2
These new URLs mismatch with previous hreflang metadata, sitemaps, and internal links, causing Google to flag canonicalization errors. Even worse, the original slug might still exist in the database without an active page—essentially an orphaned entry.
Diagnosing the Symptoms
The moment the new site went live, warning signs appeared in Search Console. Google began reporting duplicate content issues and invalid hreflang annotations across multiple pages.
Here are the key symptoms:
- Surprise “-2” slugs: URLs contained unexpected suffixes across secondary languages.
- Broken hreflang relationships: Canonical URLs did not match between language versions.
- Sitemap confusion: Sitemap included inconsistent links pointing to ephemeral slugs.
- Backlink losses: External links pointing to original slugs now 404ed or redirected improperly.
Root Cause: Slug Collision During Cloning
On inspection, the cloning tool used (like Duplicator or WP Migrate DB) had indeed copied over all the content faithfully, but some invisible or orphaned entries remained active in the wp_trp tables specific to TranslatePress. Since slugs are treated as unique entities, when TranslatePress re-registered slugs for the translated versions on the clone, any name conflict prompted the automatic addition of “-2” to resolve ambiguity.
This behavior is standard but undesirable. TranslatePress treats translated slugs as customizable entities, and duplicate entries unfairly penalized the second, valid site.
The Fix: A Slug Normalization Script
After thorough testing in staging environments, we built a custom PHP script that did the following:
- Looped through all translated posts and pages.
- Identified any slugs ending with “-2” or higher suffixes.
- Checked for existing entries using the same base slug.
- Removed orphaned records or updated database pointers where appropriate.
- Normalized slugs and ensured
wp_trpand postmeta synced correctly.
This database-sensitive operation had to be performed carefully to avoid overwriting legitimate data or disconnecting pages from their translated equivalents entirely. Backups were mandatory before running any corrections.
Key Portions of the Script
Here’s a basic outline (not a full copy) of the logic flow:
// Pseudocode for normalization
foreach (translated_posts as $post) {
if (slug has "-2") {
$clean_slug = remove_suffix($post->slug);
if (!slug_exists($clean_slug)) {
update_slug($post->ID, $clean_slug);
} else {
// Potential collision; maybe manual resolution
}
}
}
The script utilized get_post_meta(), update_post_meta(), and custom SQL queries to dive into TranslatePress’s trp_dictionary tables. Once the conflicts were resolved and all slugs normalized, we flushed the WordPress rewrite rules and regenerated translated sitemaps.
Repairing Hreflang Relationships
Arguably more important than slug appearance was the restoration of accurate hreflang relationships. Since hreflang relies on matching canonical URLs across language versions, mismatched slugs cause these to break silently. Our normalization fixed the slugs, but we followed up by:
- Regenerating sitemaps using TranslatePress’s built-in functions.
- Re-testing hreflang connections using tools like Screaming Frog and Ahrefs.
- Resubmitting sitemaps to Google Search Console.
Only after these steps did Search Console begin to lower error counts and resume correct indexing of all variants.
Lessons Learned and Prevention
This bug was a classic case of edge-case meets automation. While cloning a site, especially one using complex multilingual plugins like TranslatePress, a few proactive steps could prevent such surprises:
- Clean database entries before cloning, especially transient or orphaned slugs.
- Use migration tools that understand multilingual plugins (not all do).
- Manually inspect translated slugs post-clone using the WordPress dashboard or a slug auditing tool.
- Freeze page and slug relationships pre-clone by exporting complete mappings from TranslatePress settings or APIs.
Conclusion
The TranslatePress “-2” slug suffix might seem like a small issue, but its impact can ripple across SEO strategy, user experience, and multilingual consistency. Fortunately, with a careful diagnosis and a custom normalization script, we restored the site’s translated slugs and repaired all hreflang breaks. This fix not only stabilized the new site but also provided a template for safer future migrations.
So if your recently cloned multilingual site is suddenly sprouting “-2” in URLs, you’re not alone—and now, better armed to fix it.
