سئوی چندزبانه؛ تحقیق کلمه، ترجمه و QA محتوا

سئوی چندزبانه وقتی شکست می‌خورد که تیم «ترجمه شدن» را با «قابل‌فهم، قابل‌جست‌وجو و قابل‌تبدیل بودن» یکی بداند. یک ترجمه از نظر دستوری درست ممکن است واژه‌ای را استفاده کند که هیچ مشتری محلی جست‌وجو نمی‌کند، CTA نامأنوس داشته باشد یا قیمت و لینک نسخه اصلی را نمایش دهد.

این راهنما یک Workflow عملی برای تحقیق کلمه، انتخاب محتوا، ترجمه/Localization، بازبینی و QA فنی ارائه می‌کند. اگر هنوز بازار، دامنه و ساختار URL را انتخاب نکرده‌اید، ابتدا راهنمای استراتژی سئو بین‌المللی را بخوانید.

سئوی چندزبانه چیست؟

Multilingual SEO بهینه‌سازی نسخه‌های زبانی یک سایت است تا کاربر و موتور جست‌وجو محتوای درست، طبیعی و قابل‌استفاده را در زبان خود پیدا کنند. کار فقط ترجمه بدنه نیست؛ Query، Intent، Title، Meta، URL، لینک، تصویر، Schema، Navigation، فرم و پیام‌های خطا هم باید مدیریت شوند.

چندزبانه با چندمنطقه‌ای یکی نیست. صفحه انگلیسی عمومی ممکن است چند کشور را خدمت دهد؛ نسخه انگلیسی امارات علاوه بر زبان، قیمت، پرداخت، تحویل و مقررات منطقه را نیز تغییر می‌دهد.

ترجمه، Localization و Transcreation

همه جمله‌ها به یک روش نیاز ندارند. شرایط قرارداد ترجمه دقیق می‌خواهد؛ Headline تبلیغاتی ممکن است Transcreation شود؛ صفحه محصول باید ویژگی فنی را دقیق و فایده را بومی بیان کند.

از کدام زبان و صفحه شروع کنیم؟

کل سایت را یک‌باره ترجمه نکنید. صفحات را امتیاز دهید:

• تقاضای واقعی Query در زبان هدف؛
• ارتباط محصول با بازار؛
• ترافیک/لینک و عملکرد نسخه اصلی؛
• ارزش تجاری و مرحله Funnel؛
• هزینه ترجمه و نگهداری؛
• نیاز پشتیبانی/حقوقی؛
• قابلیت ارائه خدمت و تبدیل.

یک Pilot خوب شامل Hub، چند صفحه تصمیم‌ساز، FAQ، درباره/اعتماد، تماس و الزامات خرید است. ترجمه مقاله Top-of-funnel بدون صفحه خدمت یا CTA قابل‌استفاده، مسیر کاربر را نیمه‌کاره می‌گذارد.

تحقیق کلمه کلیدی در زبان مقصد

۱. Seed را از مسئله بسازید

کلمه نسخه فارسی فقط یکی از Seedهاست. مسئله کاربر، نام محصول، ویژگی، رقیب، اصطلاح محلی و سؤال فروش را جمع کنید.

۲. از متخصص بومی کمک بگیرید

مترجم عمومی ممکن است معنی را بداند اما اصطلاح صنعت یا Query رایج را نه. فرد بومیِ آشنا با محصول بین «ترجمه صحیح» و «زبان واقعی مشتری» پل می‌زند.

۳. SERP محلی را بررسی کنید

نوع نتایج، ویژگی SERP، قالب صفحه، لحن، واحد پول و رقبا را از بازار هدف ببینید. Query ممکن است در یک زبان اطلاعاتی و در زبان دیگر تراکنشی باشد.

۴. خوشه و Intent بسازید

واژه‌ها را به Topic، مرحله Funnel و نوع صفحه نگاشت کنید. هر Query نیاز به URL جدا ندارد؛ عبارت‌های هم‌نیت را در یک صفحه کامل پوشش دهید.

۵. Glossary سئو بسازید

برای هر اصطلاح ثبت کنید: واژه ترجیحی، موارد ممنوع، توضیح، مثال، شکل جمع، Capitalization، Intent و صفحه مالک. Glossary باید توسط SEO، مترجم و صاحب محصول تصویب شود.

Keyword Map چندزبانه

این Map مانع می‌شود دو مترجم برای یک Topic دو URL مستقل بسازند یا یک اصطلاح در صفحات مختلف به شکل ناسازگار ترجمه شود.

Brief ترجمه سئو چه دارد؟

• مخاطب، کشور و سطح دانش؛
• هدف و اقدام بعدی صفحه؛
• Primary/Secondary Topic و سؤال‌ها؛
• Glossary و لحن برند؛
• منابع و ادعاهای نیازمند بازبینی؛
• بخش‌های نیازمند Localization یا بازنویسی؛
• Title، Meta، H1 و Slug پیشنهادی؛
• لینک‌های داخلی معادل؛
• Alt، Caption و متن داخل تصویر؛
• محدودیت حقوقی و صاحب تأیید نهایی.

مترجم نباید حدس بزند صفحه برای چه کسی و چه تبدیلی نوشته شده است.

ترجمه ماشینی و AI؛ آیا برای SEO بد است؟

موتور جست‌وجو صرف استفاده از ابزار ترجمه را مجازات نمی‌کند؛ مسئله کیفیت و هدف است. سیاست Spam گوگل «تولید مقیاس‌بالای محتوای کم‌ارزش برای دستکاری رتبه» را بدون توجه به روش تولید، Scaled Content Abuse می‌داند و ترجمه/تبدیل خودکار بدون ارزش افزوده را نیز مثال می‌زند.

استفاده مسئولانه:

1. Machine/AI یک Draft اولیه تولید کند.
2. مترجم بومی معنا، اصطلاح، لحن و روانی را اصلاح کند.
3. متخصص موضوع ادعا، عدد، قانون و جزئیات محصول را تأیید کند.
4. SEO Intent، Keyword و عناصر صفحه را بازبینی کند.
5. QA فنی URL، Link، hreflang و نمایش را کنترل کند.
6. نمونه پس از انتشار با Query و بازخورد کاربر اصلاح شود.

برای صفحه حساس مالی، حقوقی یا سلامت، سطح بازبینی بالاتر و مسئول متخصص لازم است.

Human-in-the-loop واقعی چیست؟

«یک نگاه سریع» بازبینی نیست. Reviewer باید Checklist و اختیار رد داشته باشد:

• آیا معنی و جزئیات محصول حفظ شده است؟
• متن شبیه ترجمه تحت‌اللفظی یا زبان طبیعی بازار است؟
• Query و Intent محلی پوشش داده شده‌اند؟
• ادعا و منبع هنوز معتبرند؟
• مثال، قیمت، تاریخ و CTA قابل‌استفاده‌اند؟
• واژه‌های Glossary یکدست‌اند؟
• لحن با برند و حساسیت فرهنگی هماهنگ است؟
• کاربر بعد از خواندن می‌تواند اقدام کند؟

فرآیند Translation Management

1. Extract: محتوا و Stringها با شناسه پایدار استخراج شوند.
2. Prepare: متن قفل‌شده، Placeholder، Context و Screenshot اضافه شود.
3. Translate: مترجم از Glossary و Translation Memory استفاده کند.
4. Review: بازبینی زبانی و موضوعی جدا انجام شود.
5. Integrate: محتوا بدون شکستن HTML/Variable وارد CMS شود.
6. QA: Linguistic، Functional و SEO روی Staging.
7. Publish: نسخه کامل و هماهنگ منتشر شود.
8. Maintain: تغییر منبع Trigger برای Update ترجمه بسازد.

اگر نسخه اصلی تغییر کند و ترجمه بی‌خبر بماند، محتوای قدیمی یا خطرناک تولید می‌شود. هر صفحه وضعیت Sync، آخرین بازبینی و Owner داشته باشد.

Translation Memory و Glossary

Translation Memory جمله‌های تأییدشده را برای استفاده دوباره نگه می‌دارد؛ Glossary اصطلاح و قواعد را. این دو هزینه و ناسازگاری را کم می‌کنند، اما نباید متن را بی‌زمینه تکرار کنند. یک ترجمه در Button ممکن است در قرارداد مناسب نباشد. Context و Screenshot کنار String لازم است.

برای جمله تبلیغاتی، درصد Match بالا تضمین کیفیت نیست. Reviewer باید اثر و معنا را در صفحه ببیند.

Title، Meta و H1 را جدا بازنویسی کنید

محدودیت و رفتار SERP در زبان‌ها متفاوت است. ترجمه حرف‌به‌حرف Title ممکن است طولانی، بی‌جذابیت یا خارج از Query باشد:

• Primary Topic محلی را طبیعی بیاورید.
• Title را یکتا، دقیق و بدون Stuffing بنویسید.
• H1 با وعده صفحه هماهنگ اما الزاماً یکسان نباشد.
• Meta فایده، دامنه و CTA متناسب را خلاصه کند.
• نام برند و Script با زبان صفحه سازگار باشد.
• سال فقط برای محتوای واقعاً زمان‌حساس استفاده شود.

گوگل ممکن است Snippet و Title Link را از چند منبع بسازد؛ نوشتن خوب «Preference» شما را روشن می‌کند، تضمین نمایش نیست.

Slug و URL ترجمه‌شده

هر زبان URL مستقل داشته باشد. Slug می‌تواند به زبان مقصد یا لاتین توصیفی باشد؛ مهم این است که پایدار، قابل‌اشتراک و روشن باشد. برای فارسی/عربی، Percent Encoding در کپی و ابزارها را آزمایش کنید. در مایندیو برای سازگاری عملی معمولاً Slug انگلیسی/فینگلیش کوتاه انتخاب می‌شود.

اگر Slug صفحه منتشرشده تغییر می‌کند، Redirect ۳۰۱ مستقیم، canonical، Sitemap، hreflang و لینک‌های داخلی همه نسخه‌ها را اصلاح کنید.

لینک‌سازی داخلی در هر زبان

• لینک بدنه به معادل همان زبان برود، نه نسخه فارسی.
• Anchor با اصطلاح محلی و طبیعی نوشته شود.
• صفحه یتیم زبان مقصد با Hub و Navigation متصل شود.
• Language Switcher به معادل صفحه لینک دهد.
• اگر ترجمه مقصد نیست، کاربر به نزدیک‌ترین صفحه مرتبط هدایت و وضعیت روشن شود.
• لینک‌های قدیمی و Redirectشده پس از تغییر Slug به URL نهایی به‌روز شوند.

برای کنترل صفحه‌ای Title/Link/Schema از چک‌لیست On-Page استفاده کنید.

تصویر، ویدئو و فایل دانلودی

Localization شامل Asset است:

• متن داخل تصویر ترجمه یا با نسخه بدون متن جایگزین شود.
• Alt و Caption به زبان صفحه و متناسب با تصویر باشند.
• زیرنویس/Transcript ویدئو ارائه شود.
• واحد، تاریخ، نمودار و Screenshot قدیمی اصلاح شود.
• PDF زبان مقصد URL، Title و لینک مستقل داشته باشد.
• نماد یا تصویر نامناسب فرهنگی بازبینی شود.

یک Hero ترجمه‌شده با دکمه فارسی در صفحه عربی اعتماد را سریع از بین می‌برد.

فرم، ایمیل و پیام خطا

صفحه فقط محتوای CMS نیست. این نقاط را تست کنید:

• Label، Placeholder، Validation و Success message؛
• ایمیل تأیید، فاکتور و Reset Password؛
• پیام Cookie/Consent و Privacy؛
• Search، Filter و Empty state؛
• ۴۰۴، Maintenance و خطای پرداخت؛
• Live chat، Bot و پاسخ پشتیبانی؛
• تقویم، عدد، واحد پول و شماره تلفن.

Stringهای افزونه و Third-party ممکن است خارج از Editor ترجمه بمانند. Crawl و مسیر کاربر واقعی را کنار String inventory انجام دهید.

QA زبانی

QA فنی و SEO

• URL نهایی ۲۰۰ و HTTPS است.
• canonical و hreflang معتبر، متقابل و هم‌راستا هستند.
• html lang و برای فارسی/عربی dir درست است.
• Title، Meta، H1 و Schema محلی‌اند.
• Robots/noindex ناخواسته وجود ندارد.
• Sitemap نسخه را با lastmod واقعی دارد.
• تمام لینک‌های بدنه و Switcher مقصد ۲۰۰ دارند.
• Mobile، RTL/LTR و متن دوجهته نمی‌شکند.
• داده Structured با قیمت/زبان visible هماهنگ است.
• URL Inspection و Render نمونه اجرا شده است.

ابزار/افزونه چندزبانه وردپرس را چگونه انتخاب کنیم؟

نام ابزار بدون معماری پاسخ نیست. WPML، Polylang و TranslatePress مدل‌های متفاوتی برای Translation، URL، String و Workflow دارند. قابلیت و Plan تغییر می‌کند؛ بر اساس PoC انتخاب کنید.

مستندات فعلی WPML، Polylang و TranslatePress را برای Feature و Plan مقایسه کنید. ادعای Vendor را روی Staging با Theme، SEO plugin، Cache و فروشگاه خودتان تست کنید.

Redirect خودکار زبان در افزونه

برخی افزونه‌ها تشخیص IP یا زبان مرورگر دارند. فعال‌بودن Feature به معنی مناسب‌بودن آن برای SEO نیست. Google توصیه می‌کند کاربر را بر اساس حدس زبان Redirect اجباری نکنید. پیشنهاد غیرمسدودکننده، Switcher و URL مستقیم را ترجیح دهید و Googlebot را آزمایش کنید.

عملکرد و CDN چندزبانه

زبان را در Cache Key به‌درستی تفکیک کنید. ساختار URL جدا این کار را ساده می‌کند. Cookie/Accept-Language می‌تواند نسخه‌های زیاد و Hit پایین بسازد یا محتوای زبان اشتباه تحویل دهد. برای طراحی Edge و RUM بازار، راهنمای CDN بین‌المللی را ببینید.

Governance و مسئولیت‌ها

صفحه بدون Owner زود قدیمی می‌شود. SLA به‌روزرسانی ترجمه را بر اساس ریسک موضوع تعیین کنید.

اندازه‌گیری کیفیت هر زبان

• Impression، Click، CTR و Query Non-brand؛
• Index و canonical انتخاب‌شده؛
• Conversion و Lead quality؛
• خروج/بازگشت سریع و Search داخلی؛
• خطای فرم، پرداخت و Support ticket؛
• عبارت‌های جست‌وجوی بدون نتیجه؛
• تعداد Issueهای Linguistic/Functional؛
• زمان Sync نسخه منبع تا ترجمه؛
• هزینه هر صفحه و ارزش ایجادشده.

Position تنها KPI نیست. صفحه‌ای با رتبه و ترافیک خوب اما CTA ناممکن یا Lead نامرتبط موفق نیست.

نقشه اجرای ۸هفته‌ای

هفته ۱–۲: آماده‌سازی

• زبان/بازار و صفحات Pilot؛
• Keyword map، Glossary و Style guide؛
• انتخاب URL/افزونه و Workflow؛
• Baseline و KPI.

هفته ۳–۵: تولید

• Brief و Draft؛
• Review زبانی و موضوعی؛
• Title/Meta/Slug/Link/Asset؛
• ورود به Staging و Sync state.

هفته ۶–۷: QA

• Linguistic، Functional و SEO؛
• Mobile/RTL، فرم، ایمیل و Checkout؛
• Crawl، hreflang و Sitemap؛
• Performance و Analytics.

هفته ۸: انتشار و یادگیری

• انتشار تدریجی؛
• Live URL و Index monitoring؛
• جمع‌آوری Query و Feedback؛
• اصلاح Glossary/Workflow پیش از Batch بعدی.

چک‌لیست انتشار محتوای چندزبانه

• Query و Intent محلی تحقیق شده‌اند.
• Glossary، Style guide و Brief داریم.
• ترجمه ماشینی بدون Review منتشر نمی‌شود.
• مترجم و متخصص موضوع تأیید کرده‌اند.
• Title، Meta، H1، Slug و Alt بومی‌اند.
• قیمت، تاریخ، CTA و ادعا مناسب بازار است.
• URL، canonical، hreflang و lang/dir درست‌اند.
• لینک‌ها به همان زبان و مقصد ۲۰۰ می‌روند.
• Form، Email، Search، ۴۰۴ و Checkout تست شده‌اند.
• Schema و Sitemap با صفحه هماهنگ‌اند.
• Analytics/RUM و KPI Locale فعال است.
• Owner و Trigger به‌روزرسانی مشخص‌اند.

سؤالات متداول سئوی چندزبانه

آیا ترجمه ماشینی به سئو آسیب می‌زند؟

استفاده از ابزار به‌خودی‌خود مشکل نیست؛ انتشار انبوه متن کم‌ارزش، نادقیق یا بدون نیاز کاربر ریسک دارد. Draft ماشینی را با بازبینی بومی، موضوعی و SEO تکمیل کنید.

آیا همه صفحات سایت را ترجمه کنیم؟

نه لزوماً. از صفحاتی شروع کنید که تقاضا، ارزش و قابلیت پشتیبانی دارند و مسیر کامل تبدیل را می‌سازند. صفحه کم‌ارزش هزینه نگهداری چندبرابر ایجاد می‌کند.

بهترین افزونه چندزبانه وردپرس کدام است؟

به معماری، WooCommerce، Workflow، Builder، SEO plugin، عملکرد و مالکیت داده بستگی دارد. WPML، Polylang و TranslatePress را با PoC روی Staging و Featureهای موردنیاز مقایسه کنید.

آیا Slug را ترجمه کنیم؟

اگر ابزار و تیم می‌توانند Redirect و نگهداری را مدیریت کنند، Slug توصیفی زبان مقصد برای کاربر مفید است. ثبات URL و هماهنگی hreflang/canonical از ترجمه ظاهری مهم‌تر است.

هر ترجمه چه زمانی باید به‌روزرسانی شود؟

وقتی منبع در بخش معنادار تغییر می‌کند، Trigger و Diff برای Owner ترجمه بسازید. SLA بر اساس ریسک باشد: قیمت/قانون فوری‌تر از مقاله کم‌تغییر است.

جمع‌بندی

سئوی چندزبانه یک خط تولید محتوا با کنترل کیفیت است: تحقیق محلی، Glossary، Brief، ترجمه، بازبینی، QA فنی و نگهداری. ابزار سرعت می‌دهد، اما Intent، لحن، دقت و قابلیت تبدیل را تیم بومی و متخصص تضمین می‌کند.

برای طراحی Workflow ترجمه، انتخاب افزونه یا ممیزی hreflang و محتوای زبان‌های فعلی، از فرم مشاوره مایندیو استفاده کنید و زبان‌ها، CMS و حجم صفحات را بنویسید.