تست A/B بدون آسیب به سئو؛ قوانین ایندکس و کنونیکال

تست A/B زمانی ارزش دارد که یک تصمیم واقعی را روشن کند؛ مثلاً آیا عنوان کوتاه‌تر، فرم ساده‌تر یا ترتیب تازهٔ اجزای صفحه نرخ تبدیل را بهتر می‌کند. اگر آزمایش بدون نقشهٔ URL، کنونیکال و معیار توقف اجرا شود، دادهٔ بازاریابی به دست می‌آید اما هم‌زمان ممکن است موتور جست‌وجو چند نسخهٔ رقیب ببیند یا سیگنال‌های صفحه بین چند نشانی پخش شود.

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

تست A/B سئو چیست و چه تفاوتی با تست نرخ تبدیل دارد؟

در تست نرخ تبدیل، کاربران یک URL ممکن است دو تجربهٔ متفاوت ببینند و معیار رفتار آن‌ها باشد. در تست A/B سئو، گروه‌هایی از صفحه‌های مشابه با تغییر یکسان مقایسه می‌شوند تا اثر تغییر بر کلیک یا ورودی ارگانیک سنجیده شود. تفاوت اصلی در واحد تقسیم، منبع داده و مدت لازم برای مشاهدهٔ اثر است.

برای نمونه، فروشگاه می‌تواند در آزمایش نرخ تبدیل، نیمی از کاربران صفحهٔ محصول را با دکمهٔ خرید جدید ببیند. در آزمایش سئو، تیم ممکن است عنوان ۵۰ صفحهٔ یک دسته را تغییر دهد و ۵۰ صفحهٔ مشابه را به‌عنوان گروه کنترل نگه دارد. در روش دوم، هر URL برای کاربر و موتور جست‌وجو نسخهٔ ثابتی دارد.

اگر مسئلهٔ اصلی خرید، ثبت‌نام یا تکمیل فرم است، ابتدا تعریف دقیق نرخ تبدیل و رویداد نهایی را مشخص کنید. تغییر رتبه، نمایش و کلیک ارگانیک را جدا از تبدیل بسنجید؛ چون رشد تبدیل بدون افزایش ورودی هم ممکن است و افزایش کلیک نیز لزوماً به درآمد بیشتر ختم نمی‌شود.

پیش از هر اجرا یک جملهٔ فرضیه بنویسید: «اگر X را برای گروه Y تغییر دهیم، معیار Z به دلیل Q بهتر می‌شود.» این جمله جلوی تغییر هم‌زمان چند عامل را می‌گیرد. اگر عنوان، تصویر، قیمت و فرم با هم عوض شوند، حتی در صورت موفقیت آزمایش نمی‌دانید کدام تغییر نتیجه را ساخته است.

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

خطر اصلی از خود آزمایش نمی‌آید؛ از اجرای مبهم آن می‌آید. نسخه‌های آزمایشیِ قابل ایندکس، ریدایرکت دائمی برای جابه‌جایی موقت، تفاوت عمدی محتوای Googlebot و کاربر، یا ادامهٔ بی‌پایان تست می‌توانند سیگنال‌ها را مخدوش کنند. هر آزمایش باید مالک، تاریخ پایان و مسیر بازگشت داشته باشد.

نسخه‌ای که روی URL جدا ساخته می‌شود ممکن است لینک بگیرد، در نقشهٔ سایت ظاهر شود یا در نتایج جست‌وجو جای نسخهٔ اصلی را بگیرد. اگر رابطهٔ نسخه‌ها روشن نباشد، گوگل باید خودش URL نماینده را انتخاب کند. این انتخاب همیشه با برنامهٔ تیم محصول یکسان نیست و گزارش‌گیری را هم پیچیده می‌کند.

در پروژه‌هایی که چند قالب، تیم و ابزار آزمایش هم‌زمان دارند، خدمات سئو گوگل باید شامل کنترل سناریوی انتشار و جمع‌کردن نسخه‌های موقت باشد. مسئول سئو لازم است پیش از فعال‌شدن تست، URLها، تگ‌ها، ریدایرکت‌ها و ثبت رویدادها را روی محیط آزمایشی بررسی کند.

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

انتخاب روش اجرا: یک URL یا چند URL؟

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

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

برای آزمایش چند URL، ساختار مقصد و بازگشت را در سند خدمات استراتژی سئو ثبت کنید: URL اصلی چیست، نسخهٔ موقت کجاست، چه زمانی فعال می‌شود و پس از پایان چه اتفاقی می‌افتد. این ثبت ساده مانع ماندن صفحه‌های آزمایشی در سایت می‌شود.

اگر ابزار فقط یک اسکریپت آماده می‌دهد، پیش از نصب پاسخ سه پرسش را بگیرید: نسخهٔ آزمایشی در HTML اولیه است یا پس از اجرا ساخته می‌شود؟ موتور جست‌وجو می‌تواند URL جایگزین را پیدا کند؟ کش CDN نسخهٔ یک کاربر را به کاربر دیگر می‌دهد؟ پاسخ این سه مورد روش فنی امن را مشخص می‌کند.

کنونیکال نسخه‌های آزمایشی را چگونه تنظیم کنیم؟

وقتی نسخهٔ آزمایشی URL جدا دارد، هر صفحهٔ جایگزین باید با rel=canonical به URL اصلی اشاره کند. صفحهٔ اصلی نیز کنونیکال خودارجاع داشته باشد. این تنظیم به گوگل می‌گوید کدام نشانی نماینده است، اما سیگنال محسوب می‌شود و جای کنترل لینک‌ها، نقشهٔ سایت و ریدایرکت را نمی‌گیرد.

راهنمای رسمی گوگل برای آزمایش سایت نیز توصیه می‌کند URLهای جایگزین به نسخهٔ اصلی کنونیکال شوند. نسخه‌های موقت را در نقشهٔ سایت قرار ندهید و در لینک‌های داخلی دائمی مقصد نکنید؛ چون این دو کار پیام متفاوتی دربارهٔ URL ترجیحی می‌فرستند.

تگ کنونیکال را از نسخهٔ آزمایشی به خودش نگذارید، مگر آن صفحه واقعاً قرار است مستقل بماند. کنونیکال زنجیره‌ای هم نسازید؛ یعنی نسخهٔ B به C و C به A اشاره نکند. هر نسخه باید مستقیم به URL اصلی برسد تا تفسیر و عیب‌یابی ساده بماند.

برای جزئیات انتخاب URL مرجع و خطاهای رایج، راهنمای تگ کنونیکال را کنار سند آزمایش نگه دارید. پس از فعال‌سازی، HTML نهایی هر نسخه را بررسی کنید؛ دیدن تگ در تنظیمات افزونه کافی نیست، چون قالب یا ابزار تست ممکن است خروجی را بازنویسی کند.

ترکیب noindex با کنونیکال معمولاً پیام‌های متفاوت می‌سازد: یکی می‌گوید صفحه در نتایج نباشد و دیگری سیگنال‌ها را به URL دیگر جمع می‌کند. برای نسخهٔ آزمایشی چند URL، از الگوی روشن کنونیکال و مدیریت لینک‌ها استفاده کنید و noindex را به‌عنوان راه میان‌بر به کار نبرید.

ریدایرکت ۳۰۲ چه زمانی لازم است؟

اگر کاربر از URL اصلی به نسخهٔ آزمایشی جدا هدایت می‌شود، ریدایرکت ۳۰۲ یا ۳۰۷ انتخاب مناسب‌تری است؛ چون جابه‌جایی موقت است. ریدایرکت ۳۰۱ پیام انتقال دائمی می‌دهد و با ماهیت آزمایش سازگار نیست. پس از پایان تست، ریدایرکت موقت و URL آزمایشی باید جمع شوند.

گوگل در راهنمای آزمایش سایت، استفاده از ریدایرکت موقت را برای این سناریو توضیح می‌دهد. تخصیص کاربر باید پایدار باشد تا همان فرد هنگام بازگشت نسخهٔ دیگری نبیند؛ کوکی یا شناسهٔ آزمایش می‌تواند این ثبات را حفظ کند.

ریدایرکت را حلقه‌ای یا زنجیره‌ای نکنید. URL اصلی باید با یک پرش به نسخهٔ تست برسد و نسخهٔ تست نیز نباید دوباره کاربر را به اصل برگرداند. کد وضعیت را با ابزار شبکه یا curl بررسی کنید؛ برچسب «موقت» در پنل ابزار آزمایش اثبات نمی‌کند که سرور واقعاً ۳۰۲ می‌فرستد.

اگر تیم فنی دربارهٔ رفتار کدها ابهام دارد، تفاوت و موارد استفادهٔ ریدایرکت ۳۰۱ را پیش از اجرا مرور کند. آزمایش تمام‌شده‌ای که همچنان با ۳۰۲ کاربر را پخش می‌کند، اندازه‌گیری آینده را آلوده می‌کند و نگهداری سایت را سخت‌تر می‌سازد.

چطور از Cloaking جلوگیری کنیم؟

Cloaking زمانی رخ می‌دهد که موتور جست‌وجو عمداً محتوایی متفاوت از کاربر دریافت کند. در آزمایش معتبر، تخصیص نسخه باید برای Googlebot و کاربران با همان منطق عادی انجام شود. نمایش نسخهٔ بهینه به ربات و نسخهٔ دیگری به کاربر، آزمایش نیست و می‌تواند خلاف سیاست‌های گوگل باشد.

از شرط‌هایی مانند User-Agent برابر Googlebot یا IPهای شناخته‌شدهٔ خزنده برای انتخاب نسخه استفاده نکنید. اگر ربات به‌طور تصادفی یکی از نسخه‌ها را دید، همان رفتاری است که کاربر در همان شرایط می‌بیند. تفاوت ناشی از اندازه صفحه یا ورود کاربر طبیعی است، اما تفاوت طراحی‌شده فقط برای ربات طبیعی نیست.

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

چه صفحه‌هایی را برای آزمایش انتخاب کنیم؟

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

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

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

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

فرضیه و معیار موفقیت را چگونه بنویسیم؟

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

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

هر فرضیه را در برنامهٔ استراتژی سئو به یک تصمیم وصل کنید. اگر نتیجه مثبت شد چه چیزی منتشر می‌شود؟ اگر خنثی یا منفی شد چه اقدامی انجام می‌دهید؟ آزمایشی که هیچ نتیجه‌ای تصمیم تیم را تغییر نمی‌دهد، فقط داده تولید می‌کند و اولویت اجرا ندارد.

نتیجه را چطور بدون خطای زمانی بسنجیم؟

آزمایش را تا رسیدن به عدد دلخواه متوقف نکنید. بازه و قاعدهٔ توقف را پیش از شروع تعیین کنید و دوره‌های کامل رفتاری را پوشش دهید. مقایسهٔ دو روز پرترافیک با دو روز عادی نتیجه را منحرف می‌کند. در سئو، تأخیر خزش و پردازش نیز باید در تحلیل لحاظ شود.

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

نمایش و کلیک را بر اساس نوع جست‌وجو، دستگاه و کشور بخش‌بندی کنید، اما پس از دیدن نتیجه ده‌ها برش نسازید تا بالاخره یک نمودار مثبت پیدا شود. بخش‌بندی باید از مسئلهٔ واقعی بیاید. برای نمونه، تغییر عنوان ممکن است در موبایل با فضای کوتاه‌تر اثر متفاوتی داشته باشد.

برای کنونیکال، گوگل توضیح می‌دهد که ریدایرکت و rel=canonical سیگنال‌های قوی و حضور در نقشهٔ سایت سیگنال ضعیف‌تری است؛ ترکیب سیگنال‌های همسو احتمال انتخاب URL موردنظر را بیشتر می‌کند. جزئیات این موضوع در راهنمای یکپارچه‌سازی URLهای تکراری آمده است.

پس از پایان، نسخهٔ برنده را برای همه منتشر کنید، کد آزمایش را بردارید و دوباره وضعیت پاسخ، کنونیکال و رویدادها را بسنجید. گزارش نهایی باید فرضیه، تاریخ، URLها، تغییر، معیارها، نتیجه و تصمیم را نگه دارد. این گزارش برای جلوگیری از تکرار آزمایش‌های مشابه ارزش عملی دارد.

چک‌لیست اجرای تست A/B بدون آسیب به سئو

این چک‌لیست مسیر آزمایش را از تصمیم تا پاک‌سازی پوشش می‌دهد. هر مورد باید مسئول مشخص داشته باشد و با مشاهدهٔ خروجی تأیید شود. تیک‌زدن تنظیم داخل پنل کافی نیست؛ کد وضعیت، HTML نهایی، دادهٔ رویداد و رفتار واقعی کاربر باید بررسی شوند.

• فرضیه، معیار اصلی، معیار نگهبان و قاعدهٔ توقف پیش از اجرا نوشته شده است.
• URL اصلی کنونیکال خودارجاع دارد و نسخه‌های جایگزین مستقیم به آن اشاره می‌کنند.
• اگر جابه‌جایی URL لازم است، پاسخ ۳۰۲ یا ۳۰۷ است و زنجیره یا حلقه وجود ندارد.
• تقسیم نسخه به User-Agent یا IP موتور جست‌وجو وابسته نیست.
• نسخه‌های موقت در نقشهٔ سایت و لینک‌های داخلی دائمی قرار نگرفته‌اند.
• کش، رندر JavaScript، سرعت و ثبت رویداد در موبایل و دسکتاپ آزموده شده‌اند.
• گروه کنترل با گروه تست از نظر قالب، تقاضا، فصل و عملکرد پایه قابل مقایسه است.
• مالک، تاریخ پایان، برنامهٔ بازگشت و کارهای پاک‌سازی مشخص هستند.
• پس از پایان، ابزار آزمایش، ریدایرکت موقت و URLهای اضافه بررسی و جمع می‌شوند.

اشتباهات رایج در تست A/B سئو

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

اشتباه دیگر، یکسان‌گرفتن نتیجهٔ تبدیل و نتیجهٔ سئو است. عنوانی ممکن است کلیک بیشتری بگیرد اما کاربر کم‌کیفیت‌تری وارد کند. فرم کوتاه‌تر ممکن است تبدیل را بالا ببرد اما اطلاعات لازم تیم فروش را کم کند. تصمیم نهایی باید معیار اصلی و نگهبان را هم‌زمان ببیند.

در پایان نیز نباید نسخهٔ برنده بدون کنترل عمومی شود. گاهی برنده فقط برای یک دستگاه، یک دسته یا یک بازه مناسب است. محدودهٔ اعتبار نتیجه را بنویسید و انتشار را مرحله‌ای انجام دهید تا اگر خطای فنی یا رفتاری تازه‌ای دیده شد، بازگشت آسان باشد.

جمع‌بندی

تست A/B سئو زمانی قابل اتکاست که طراحی محصول و کنترل فنی از ابتدا کنار هم باشند. برای تغییر کوچک، یک URL ساده‌تر است؛ برای نسخه‌های جدا، کنونیکال به صفحهٔ اصلی و ریدایرکت موقت لازم است. تخصیص نباید بر اساس هویت ربات انجام شود. فرضیه، گروه کنترل، معیارهای نگهبان و برنامهٔ پاک‌سازی نیز باید پیش از شروع نوشته شوند تا نتیجه به یک تصمیم قابل اجرا برسد.

سوالات متداول

منابع

• Google Search Central: A/B Testing Best Practices
• Google Search Central: Canonicalization
• Google Search Central: Redirects and Google Search