تست A/B در سئو؛ طراحی آزمایش، داده و تصمیم معتبر

فرض کنید عنوان ۵۰ صفحه دسته‌بندی را عوض کرده‌اید و سه هفته بعد کلیک ارگانیک ۱۸ درصد بالا رفته است. آیا عنوان جدید برنده است؟ شاید؛ اما شاید تقاضای فصلی، Core Update، تغییر رتبه رقبا یا حتی بازخزش دیرهنگام گوگل علت باشد. نمودار «قبل و بعد» اثر را نشان نمی‌دهد؛ فقط هم‌زمانی را نشان می‌دهد.

تست A/B در سئو برای ساختن یک خلاف‌واقع معتبر است: اگر تغییر را اجرا نمی‌کردیم، چه اتفاقی می‌افتاد؟ در آزمایش SEO معمولاً URLهای مشابه را به گروه کنترل و آزمایش تقسیم می‌کنیم؛ هر URL یک نسخه ثابت دارد و کاربر و Googlebot همان نسخه را می‌بینند. این با A/B تست رایج CRO که بازدیدکنندگان یک صفحه را تصادفی به دو تجربه می‌فرستد، تفاوت بنیادی دارد.

تست A/B سئو چیست؟

آزمایش SEO یک مداخله کنترل‌شده روی عناصر قابل‌خزش و قابل‌ایندکس سایت است تا اثر علّی آن بر عملکرد جست‌وجو برآورد شود. واحد تخصیص معمولاً صفحه، گروه صفحه یا Template است؛ واحد مشاهده می‌تواند URL-روز، URL-هفته یا Query-URL-روز باشد.

برای طراحی آزمایش Conversion، MDE، SRM و Profit در سطح بازدیدکننده، راهنمای جامع CRO و Experimentation را ببینید. مقاله حاضر آن مفاهیم را برای محدودیت‌های Crawl، Index، SERP و داده Search Console بازطراحی می‌کند.

اشتباه خطرناک: دو Title تصادفی روی یک URL

برای سنجش اثر SEO عنوان، نباید نیمی از کاربران و Googlebot را به Title A و نیم دیگر را به Title B بفرستید. Googlebot عموماً Cookie تست را نگه نمی‌دارد؛ خزیدن در زمان‌های متفاوت نیز «نمونه تصادفی» قابل‌اتکا نمی‌سازد. افزون بر آن، نتیجه جست‌وجو برای URL از یک نسخه ایندکس‌شده ساخته می‌شود، نه از نسخه‌ای که هر کاربر بعد از کلیک دیده است.

الگوی درست برای سایت دارای صفحات هم‌نوع این است: مثلاً ۱۰۰ صفحه محصول واجد شرایط را به ۵۰ کنترل و ۵۰ Treatment تقسیم کنید. عنوان هر صفحه Treatment برای همه درخواست‌ها تغییر می‌کند و صفحات کنترل دست‌نخورده می‌مانند. سپس تغییر نسبی دو گروه را در زمان مقایسه می‌کنید.

چه زمانی آزمایش SEO ارزش دارد؟

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

Snapshot روش و منابع: مرداد ۱۴۰۵

رفتار Search Console، قابلیت ابزارها و سیستم‌های Google تغییر می‌کند. این راهنما بر اساس منابع رسمی موجود در ۱۹ مرداد ۱۴۰۵ (۱۰ اوت ۲۰۲۶) نوشته شده است. پیش از هر آزمایش، راهنمای جاری Google برای کمینه‌کردن اثر A/B test و وضعیت Search را دوباره بررسی کنید.

قرارداد آزمایش را پیش از دیدن نتیجه بنویسید

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

فرضیه خوب، نتیجه را تضمین نمی‌کند

قالب پیشنهادی: «برای [جمعیت]، تغییر [عنصر] از مسیر [مکانیسم] موجب [اثر جهت‌دار بر معیار اصلی] می‌شود، بدون عبور [Guardrail]؛ اثر کمتر از [MDE] ارزش Rollout ندارد.» ردشدن فرضیه شکست نیست؛ دانشی است که از اجرای سراسری بی‌اثر جلوگیری می‌کند.

جمعیت واجد شرایط را قبل از تقسیم تثبیت کنید

صفحات باید از نظر Template، Intent، چرخه عمر و رفتار تاریخی قابل‌مقایسه باشند. مخلوط‌کردن صفحه محصول، مقاله و دسته در یک آزمایش Variance را بالا و تفسیر را ضعیف می‌کند.

معیار ورود و خروج

• Indexable، Canonical پایدار و Status ۲۰۰ باشد.
• حداقل تاریخچه کافی برای شناخت فصل و Variance داشته باشد.
• مهاجرت، حذف، تغییر قیمت/موجودی غیرعادی یا بازطراحی هم‌زمان نداشته باشد.
• URLهای تازه، Outlier بسیار بزرگ و صفحات با Cannibalization حل‌نشده جدا شوند.
• زبان، کشور، نوع نتیجه و Device مهم ثبت شود.
• قاعده خروج پس از شروع، پیشاپیش تعریف شود؛ نتیجه ضعیف دلیل حذف URL نیست.

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

تخصیص تصادفی، پایدار و متوازن

URLها را با Hash یا Seed ثبت‌شده به کنترل و Treatment تخصیص دهید؛ تخصیص باید در تمام مدت پایدار بماند. قبل از Randomization می‌توانید بر اساس Template، کشور هدف، سطح Impression و رفتار پیش‌دوره Block بسازید تا تعادل بهتر شود.

assignment = hash(experiment_id + canonical_url + seed) mod 2
0 = control
1 = treatment

Manifest آزمایش باید Canonical URL، گروه، نسخه Treatment، زمان Deploy، مالک و وضعیت Exposure را نگه دارد. انتخاب دستی «صفحات امیدوارکننده» برای Treatment سوگیری ایجاد می‌کند.

تعادل پیش از اجرا

تداخل: وقتی یک صفحه روی دیگری اثر می‌گذارد

فرض ساده آزمایش این است که درمان یک URL نتیجه URL دیگر را تغییر نمی‌دهد. در SEO این فرض زیاد می‌شکند: لینک داخلی، Breadcrumb، Navigation، Sitemap، Canonical و Cannibalization صفحات را به هم وصل می‌کنند.

اگر Treatment در سطح Category parent یا Module لینک داخلی است، Childهای مرتبط را به‌صورت Cluster تخصیص دهید. یک دسته را نصف‌نصف نکنید اگر لینک و تقاضای آن میان صفحات پخش می‌شود. تغییر کل سایت مثل Navigation یا Robots را با Canary معماری و تحلیل سری زمانی بسنجید، نه Split ساده صفحه‌ای.

Exposure در SEO زمان Deploy نیست

یک کاربر نسخه Deploy‌شده را فوراً می‌بیند، اما سیستم جست‌وجو باید URL را بخزد، Render/پردازش و دوباره ایندکس کند. Google می‌گوید Recrawl می‌تواند از چند روز تا چند هفته طول بکشد و درخواست مکرر، آن را سریع‌تر نمی‌کند؛ جزئیات در راهنمای درخواست بازخزش آمده است.

تحلیل Intention-to-treat همه URLهای تخصیص‌یافته را حفظ می‌کند و در کنار آن Adoption را گزارش می‌دهد. حذف صفحات Treatment که دیر Crawl شده‌اند می‌تواند نتیجه را سوگیر کند.

یک تغییر قابل‌تشخیص و قابل‌بازگشت اجرا کنید

در هر آزمایش یک «بسته درمانی» روشن داشته باشید. تغییر هم‌زمان Title، H1، متن، Schema و لینک داخلی مشخص نمی‌کند کدام مکانیسم اثر کرده است. اگر بسته کامل محصولی را می‌سنجید، صریحاً بگویید اثر مربوط به بسته است نه جزء منفرد.

Marker و نسخه

<meta name="x-seo-experiment" content="category-title-v3:treatment">

Marker داخلی یا Header قابل‌ثبت، بررسی Render و Cache را آسان می‌کند؛ لازم نیست برای کاربر برجسته باشد. Version و Commit/Release را ذخیره کنید و Rollback باید همان‌قدر مشخص باشد که Deploy. الگوی انتشار کنترل‌شده در راهنمای CI/CD امن و Progressive Delivery تکمیل شده است.

کاربر و Googlebot باید یک Treatment ببینند

Google Search Central نمایش URL یا محتوای متفاوت به Googlebot و انسان را Cloaking و خلاف سیاست‌ها می‌داند. منطق درمان را به User-Agent خزنده گره نزنید. HTML خام، Renderشده، Mobile و حالت بدون Cookie را آزمون کنید.

برای تست رفتاری با URLهای Variant، راهنمای Google استفاده از rel="canonical" به URL اصلی و Redirect موقت ۳۰۲ به‌جای ۳۰۱ است. این الگو را با SEO split test صفحه‌ای اشتباه نگیرید: در تست Title روی مجموعه دسته‌ها، هر Canonical URL عضو گروه خود است و Alternate URL مصنوعی نمی‌سازید.

معیار اصلی را با مکانیسم فرضیه هماهنگ کنید

CTR نسبت Click به Impression است؛ اگر Treatment خود Impression یا Query mix را تغییر دهد، تفسیر CTR تنها می‌تواند گمراه‌کننده باشد. Click و Impression را با Count و Rate کنار هم ببینید. Average position نیز میانگین بالاترین جایگاه Property برای Impressionهاست و با تغییر Query mix جابه‌جا می‌شود؛ Google توصیه می‌کند بیشتر بر روند Click و Impression تمرکز کنید.

Title و Snippet آن چیزی نیست که دقیقاً در SERP می‌بینید

Google می‌گوید Title link را به‌صورت خودکار از <title>، عنوان دیداری، H1، og:title، متن صفحه و Anchorها می‌سازد و بازپردازش تغییر می‌تواند چند روز تا چند هفته طول بکشد. مرجع رسمی ساخت Title link را قبل از آزمایش قالب بخوانید.

Snippet نیز غالباً از محتوای صفحه ساخته می‌شود و گاهی Meta Description را به کار می‌گیرد؛ بنابراین «تغییر Meta = تغییر Snippet» فرض مطمئنی نیست. راهنمای Snippet گوگل این اختیار را توضیح می‌دهد. Adoption نمایش واقعی را در نمونه Queryها بسنجید، اما Scraping شخصی‌سازی‌شده SERP را حقیقت کامل فرض نکنید.

برای اصول Title، H1، Meta، لینک و Intent هر URL، چک‌لیست سئو داخلی صفحه مرجع عملی است.

قرارداد داده Search Console

داده Search Console را پیش از آزمایش Export و Freeze کنید. طبق مستند رسمی داده Search Console، داده معمولاً با دو تا سه روز تأخیر منتشر، روزها بر مبنای زمان کالیفرنیا ثبت و برخی Queryها برای حریم خصوصی پنهان می‌شوند. نمودار و جدول نیز به‌دلیل Aggregation ممکن است جمع یکسانی نداشته باشند.

Bulk export به BigQuery داده Performance موجود را به‌جز Queryهای ناشناس روزانه منتقل می‌کند و برای سایت بزرگ مناسب است. UI برای اکتشاف خوب است، نه لزوماً Dataset نهایی آزمایش.

جدول حداقلی داده

date | canonical_url | group | treatment_version
clicks | impressions | sum_top_position
country | device | search_type | search_appearance
crawl_exposure | deploy_version | data_complete

معماری Event، Warehouse، کیفیت و تطبیق درآمد در راهنمای تحلیل داده‌های بازاریابی آمده است. Search Console و Analytics را با تعریف‌های متفاوتشان نگه دارید؛ Click گوگل همان Session یا Order نیست.

Baseline و پیش‌دوره را قفل کنید

پیش‌دوره برای شناخت Trend، Seasonality، Variance و Match استفاده می‌شود؛ نباید آن‌قدر دست‌کاری شود تا گروه‌ها «برنده» به نظر برسند. تاریخ شروع و پایان، روزهای تعطیل، کمپین، تغییر موجودی و رخداد فنی را ثبت کنید.

Placebo پیش از Deploy

همان مدل تحلیل را روی یک تاریخ جعلی در پیش‌دوره اجرا کنید. اگر بدون Treatment اثر بزرگ و مکرر می‌سازد، گروه یا مدل کنترل مناسبی نیست. Placebo تضمین اعتبار نیست، اما هشدار مفیدی درباره Trend ناموازی و Overfit است.

حجم نمونه و مدت تست عدد ثابت ندارند

قاعده «حداقل ۱۰۰۰ بازدید»، «دو هفته» یا «حتماً ۹۵ درصد» برای همه تست‌های SEO معتبر نیست. توان آزمون به تعداد واحد مستقل، Variance، هم‌بستگی زمانی، سهم صفرها، اثر موردانتظار و مدل تحلیل وابسته است. هزار Impression روی یک صفحه، با هزار Impression روی صد صفحه مستقل یکی نیست.

MDE را از ارزش کسب‌وکار بسازید

Minimum Detectable Effect کوچک‌ترین اثری است که اجرای سراسری آن پس از هزینه و ریسک ارزش دارد. سپس با داده تاریخی شبیه‌سازی کنید: Treatment مصنوعی با اندازه‌های مختلف تزریق و نرخ کشف/خطای مدل سنجیده شود.

پایان تست باید بر قرارداد داده، پنجره مشاهده، Adoption و Precision تکیه کند؛ نه اینکه هر روز نمودار را نگاه کنید و در اولین نقطه مثبت متوقف شوید.

سه روش تحلیل و محدودیت هرکدام

Difference-in-Differences

تغییر پیش تا پس Treatment را منهای تغییر همان بازه Control می‌کند. ساده و توضیح‌پذیر است، اما به فرض Trendهای موازی بدون Treatment وابسته است. Plot پیش‌دوره و Placebo ضروری‌اند.

اثر = (Treatment_after − Treatment_before)
منهای (Control_after − Control_before)

Regression با Covariate و اثر ثابت

می‌تواند اختلاف پایه URL، روز هفته، Device، Country و روند را کنترل کند. Standard error باید با ساختار Cluster/زمان سازگار باشد؛ هر ردیف URL-روز را مشاهده کاملاً مستقل فرض نکنید.

Synthetic control و Bayesian time series

برای Intervention محدود یا زمانی، ترکیبی از سری‌های کنترل یک خلاف‌واقع می‌سازد. مقاله Google Research درباره Bayesian structural time series این رویکرد و محدودیتش در نبود Randomization را توضیح می‌دهد. مدل زیبا جای Control مرتبط و فرض معتبر را نمی‌گیرد.

اثر را با عدم‌قطعیت گزارش کنید

نتیجه فقط «برنده/بازنده» نیست. اثر مطلق و نسبی، بازه اطمینان/اعتبار، Adoption، Guardrail و هزینه اجرا را کنار هم بنویسید.

سلامت آزمایش: SRM کافی نیست

در CRO، Sample Ratio Mismatch نسبت تخصیص را بررسی می‌کند. در SEO علاوه بر نسبت صفحه‌ها، باید سهم تاریخی Traffic، Deploy، Cache، Crawl، Index و داده را کنترل کنید.

چک سلامت روزانه

• تعداد و سهم پایه URLهای Control/Treatment با Manifest می‌خواند.
• هیچ URL بین گروه‌ها جابه‌جا نشده است.
• Marker نسخه روی همه Treatment و روی هیچ Control نیست.
• Status، Canonical، Robots، H1 و Render ناخواسته تغییر نکرده‌اند.
• Adoption Crawl/Index دو گروه و Lag داده ثبت می‌شود.
• Dataset روزهای ناقص، Duplicate و Missing را علامت می‌زند.
• Release، Incident، Algorithm update و کمپین Annotation دارند.

برای Telemetry، SLO و Alert کم‌نویز آزمایش، راهنمای Observability وب‌سایت مفید است.

عوامل بیرونی و تقویم تغییرات

تغییر تقاضا، خبر، موجودی، قیمت، تبلیغ، رقیب، Core Update و اختلال Search می‌توانند نتیجه را جابه‌جا کنند. Google Search Status Dashboard و فهرست و راهنمای Core Update را در تقویم آزمایش ثبت کنید.

وجود Core Update الزاماً تست را باطل نمی‌کند؛ اگر Control هم‌زمان و واقعاً مشابه باشد، بخشی از Shock را جذب می‌کند. اما Interaction ممکن است متفاوت باشد. تحلیل حساسیت با حذف بازه Rollout، تقسیم Segment و گزارش صادقانه بهتر از نادیده‌گرفتن رخداد است.

آزمایش Title و Meta Description

کاندیداهای مناسب، Templateهای پرتعداد با Impression کافی و مشکل مشخص‌اند: عنوان Boilerplate، تمایز ناکافی، ناهماهنگی زبان یا Intent. فرضیه «کلمات قدرتمند CTR را زیاد می‌کنند» ضعیف است؛ مکانیسم باید به نیاز جست‌وجوگر مربوط باشد.

آزمایش محتوا و ساختار صفحه

محتوا را فقط برای «طول بیشتر» آزمایش نکنید. Treatment می‌تواند پاسخ مستقیم، جدول مشخصات، بخش مقایسه، مدرک تجربه، FAQ واقعی یا پوشش یک Intent فرعی باشد. کیفیت، صحت، تاریخ و مالک نگهداری جزئی از Treatment هستند.

Metric را به مکانیسم وصل کنید: پاسخ بهتر شاید Queryهای مرتبط، Impression و Click را تغییر دهد؛ CTA پایین صفحه بیشتر Conversion را تغییر می‌دهد و موضوع CRO است. معیارهای رفتار مانند Bounce یا Dwell را خودکار «سیگنال مستقیم رتبه» معرفی نکنید.

آزمایش لینک داخلی و خطر اثر شبکه‌ای

افزودن لینک از صفحات مبدأ به مقصد، Crawl و Page relationship را برای چند URL تغییر می‌دهد. واحد آزمایش باید Module/Cluster مبدأ باشد و نتیجه مقصدها نیز سنجیده شود. اگر یک مقصد از هر دو گروه لینک می‌گیرد، Treatment آلوده است.

Anchor را طبیعی و توصیفی نگه دارید؛ لینک آزمایشی نباید مسیر کاربر را خراب کند. تغییر Navigation سراسری را به‌عنوان Intervention شبکه‌ای با Rollout محدود و تحلیل سطح Site انجام دهید.

آزمایش Structured Data

ابتدا Eligibility، صحت و تطابق Markup با محتوای دیداری را کنترل کنید. Rich result تضمین نمی‌شود؛ ممکن است Valid باشید و نمایش نگیرید. معیار سلامت شامل خطای Rich Results، پوشش Template، Manual action و Search appearance است. Markup ساختگی یا محتوای پنهان Treatment قابل‌قبول نیست.

آزمایش سرعت و Core Web Vitals

تغییر Performance هم تجربه کاربر و هم Search را تحت‌تأثیر قرار می‌دهد، اما Field data پنجره و تأخیر خودش را دارد. RUM، CrUX/CWV، Error و Conversion را جدا از Search clicks تحلیل کنید؛ یک امتیاز Lab را Outcome ننامید. مرزبندی و مدل اثر در راهنمای سرعت سایت، UX، سئو و تبدیل آمده است.

سایت کم‌ترافیک چه کار کند؟

برای یک مقاله کم‌ترافیک، A/B واقعی و سریع ندارید. راه‌های بهتر:

1. صفحات هم‌Intent و هم‌Template را در یک آزمایش Cluster کنید.
2. تغییر بزرگ‌تر و مکانیسم‌دار با MDE عملی انتخاب کنید.
3. پیش‌دوره طولانی‌تر و Control خارجیِ واقعاً مرتبط بسازید.
4. برای یک URL از Interrupted time series استفاده و محدودیت علیت را گزارش کنید.
5. Quality fixهای روشن را اجرا و با Monitoring تأیید کنید، نه اینکه ماه‌ها منتظر Significance بمانید.

ترافیک کم مجوز Multivariate test نیست. متغیرهای بیشتر، حالت‌های بیشتر و توان کمتر می‌سازند.

مثال ایرانی: عنوان دسته فروشگاهی

فروشگاهی ۱۲۰ صفحه دسته پایدار دارد. فرضیه این است که افزودن نوع کاربرد و حذف Boilerplate تکراری، تطابق Non-brand query و Click را بهتر می‌کند. صفحات بر اساس Impression پیش‌دوره، نوع محصول و سهم Mobile Block و سپس تصادفی می‌شوند.

در ایران، نوروز، یلدا، بازگشایی مدارس، تغییر قیمت و موجودی می‌توانند Trend را بشکنند. سهم Device، Country گزارش‌شده و رفتار شبکه/VPN را Segment کنید، اما داده کم را به ده‌ها زیرگروه خرد نکنید.

ابزارهای لازم؛ از داده تا Deploy

ابزار تخصصی SEO testing می‌تواند Assignment، Forecast و گزارش را ساده کند، اما اعتبار طراحی را تضمین نمی‌کند. پیش از خرید، Export داده، مدل آماری، Adoption، Handling صفحات صفر، Segment، هزینه، دسترسی از ایران و امکان خروج را روی داده خودتان Pilot کنید.

گزارش نتیجه؛ چه چیزی ثبت شود؟

• فرضیه، جمعیت، تغییر و نسخه قرارداد بدون ویرایش پسینی.
• نمودار پیش‌دوره و پس‌دوره برای Control و Treatment.
• تعادل پایه، Adoption Crawl/Index و نقص داده.
• اثر مطلق/نسبی، بازه عدم‌قطعیت و MDE.
• Guardrail، Segmentهای ازپیش‌تعریف‌شده و تحلیل حساسیت.
• رخدادهای بیرونی، انحراف از پروتکل و محدودیت‌ها.
• تصمیم Ship/Hold/Rollback، مالک و زمان Follow-up.

داشبورد برای دیدن است؛ Decision record برای یادگیری. فرایند تصمیم ترکیبی داده، پژوهش و قضاوت در راهنمای طراحی UX داده‌آگاه توضیح داده شده است.

Rollout نتیجه برنده هم یک آزمایش عملیاتی است

برنده را یک‌باره روی کل سایت Deploy نکنید. ابتدا Canary کوچک، سپس ۲۵/۵۰/۱۰۰ درصد URLهای واجد شرایط با کنترل Error، Canonical، Render، Index و کسب‌وکار اجرا شود. اثر ممکن است با گسترش کاهش یابد؛ صفحات باقی‌مانده با جمعیت آزمایش یکسان نیستند یا Interference رخ می‌دهد.

شرایط Rollback

• خطای 5xx/Render یا افت Indexability.
• Canonical/Robots/Schema ناخواسته.
• شکستن Conversion یا SLO فراتر از Guardrail.
• عدم تطابق نسخه برای کاربر و خزنده.
• اثر منفی پایدار پس از پنجره Adoption تعریف‌شده.

برنامه اجرایی ۶۰روزه

اشتباه‌های رایج در تست SEO

• نمایش دو Title تصادفی روی یک URL و نامیدن آن SEO split test.
• استفاده از قبل/بعد بدون Control و ادعای علیت.
• توقف وقتی نمودار مثبت شد یا تمدید تا نتیجه دلخواه.
• فرض عدد ثابت برای ترافیک، مدت یا Confidence.
• نادیده‌گرفتن Recrawl/Index و شروع ساعت از Deploy.
• حذف URLهای Treatment ضعیف پس از دیدن داده.
• CTR-only در حالی که Impression و Query mix تغییر کرده است.
• اعلام Title/Meta منتشرشده به‌عنوان نمایش قطعی SERP.
• تغییر چند جزء و نسبت‌دادن اثر به یک جزء.
• نادیده‌گرفتن Core Update، فصل، موجودی و کمپین.
• Rollout سراسری بدون Canary و مسیر بازگشت.

چک‌لیست پیش از شروع

• Intent، Population، Treatment، Primary، Guardrail و MDE ثبت شده‌اند.
• Canonical، Indexability و داده پایه سالم‌اند.
• واحد تخصیص با خطر Interference سازگار است.
• Seed و Manifest ثابت و بازتولیدپذیرند.
• کاربر و Googlebot محتوای یکسان می‌بینند.
• Marker نسخه، Cache purge و Rollback آزموده شده‌اند.
• Exposure Crawl/Index جدا از Deploy سنجیده می‌شود.
• Search Console lag، Timezone، privacy و truncation مدیریت شده‌اند.
• مدل تحلیل و Stop rule پیشاپیش تعیین شده‌اند.
• تقویم Release، کمپین و Update گوگل Annotation دارد.
• نتیجه با اثر، عدم‌قطعیت، MDE و Guardrail گزارش می‌شود.

پرسش‌های متداول

تفاوت تست A/B سئو و CRO چیست؟

در SEO معمولاً URLهای مشابه به کنترل و Treatment تقسیم می‌شوند و هر URL برای همه کاربران و خزنده‌ها نسخه ثابتی دارد؛ Outcome نیز پس از Crawl/Index در Search سنجیده می‌شود. در CRO معمولاً کاربر یا Session روی یک تجربه تصادفی می‌شود و Outcome رفتاری/تجاری است.

آیا می‌توان برای یک صفحه تست A/B سئو اجرا کرد؟

برای یک URL منفرد نمی‌توانید هم‌زمان دو نسخه مستقل ایندکس‌شده و منصفانه بسازید. می‌توانید قبل/بعد، Interrupted time series یا Synthetic control اجرا کنید، اما فرض‌ها و قدرت استنباط آن از آزمایش تصادفی چندصفحه‌ای ضعیف‌تر است.

حداقل ترافیک و مدت تست SEO چقدر است؟

عدد جهانی وجود ندارد. تعداد URL مستقل، Variance تاریخی، MDE، Seasonality، هم‌بستگی زمانی و سرعت Crawl/Index تعیین‌کننده‌اند. با داده تاریخی Power simulation انجام دهید و مدت را با Adoption و Stop rule مشخص کنید، نه با «دو هفته» یا «هزار بازدید» ثابت.

آیا تست A/B به سئو آسیب می‌زند؟

آزمایش درست ذاتاً جریمه ندارد، اما Cloaking، Canonical/Redirect اشتباه، اجرای طولانی Variantهای URL و محتوای گمراه‌کننده ریسک دارند. Google برای Variant URL، Canonical به نسخه اصلی و Redirect موقت ۳۰۲ را توصیه می‌کند؛ کاربر و Googlebot باید Treatment یکسان ببینند.

آیا Search Console به‌تنهایی برای تحلیل تست کافی است؟

برای Click، Impression، CTR و Position منبع اصلی است، اما به Assignment registry، Crawl/Index evidence، QA فنی، تقویم رخداد و داده Conversion/Revenue هم نیاز دارید. UI محدودیت ردیف و Query privacy دارد؛ سایت بزرگ بهتر است API یا Bulk export را به Warehouse متصل کند.

جمع‌بندی: آزمایش SEO یعنی ساختن خلاف‌واقع

تست معتبر SEO با ابزار یا دکمه «Start experiment» آغاز نمی‌شود؛ با سؤال علّی، واحد درست و قرارداد تصمیم آغاز می‌شود. صفحات مشابه را منصفانه تقسیم کنید، Treatment را برای انسان و خزنده یکسان نگه دارید، Exposure واقعی را پس از Crawl/Index بسنجید و Control هم‌زمان را از دست ندهید.

نتیجه خوب فقط عدد مثبت نیست. نتیجه خوب اثری است که اندازه، عدم‌قطعیت، ارزش عملی، سلامت داده و محدودیتش روشن باشد و بتوان آن را با Canary و Rollback امن به سایت منتقل کرد. این رویکرد، «سئو تجربی» را از نمودارهای امیدوارکننده به یک سیستم یادگیری سازمانی تبدیل می‌کند.