בדיקת A/B עם פיצול URL והגנה על SEO

כאשר עיצוב מחדש של דף משנה באופן דרסטי את המבנה והטכנולוגיות שלו, בדיקת A/B סטנדרטית על כתובת אחת הופכת לבלתי אפשרית. אנו מגדירים בדיקת Split URL עם כתובות שונות כדי להשוות נכון בין גרסאות ולקבל נתונים מהימנים. הצוות שלנו מספק פרויקט סוהר—מהגדרה ידידותית ל-SEO ועד אינטגרציית אנליטיקס—ובכך מבטיח אמינות ותמיכה מתמשכת.

פיתוח ותחזוקה של כל סוגי האתרים:

אתרי מידע או יישומי אינטרנט
אתרי תדמית, דפי נחיתה, אתרי חברה, קטלוגים מקוונים, חידונים, אתרי קידום, בלוגים, מקורות חדשות, פורטלי מידע, פורומים, אגרגטורים
אתרי מסחר אלקטרוני או יישומי אינטרנט
חנויות מקוונות, פורטלי B2B, שווקים, בורסות מקוונות, אתרי קאשבק, בורסות, פלטפורמות דרופשיפינג, מנתחי מוצרים
יישומי אינטרנט לניהול תהליכים עסקיים
מערכות CRM, מערכות ERP, פורטלים ארגוניים, מערכות ניהול ייצור, מנתחי מידע
אתרי שירות אלקטרוני או יישומי אינטרנט
פלטפורמות מודעות, בתי ספר מקוונים, בתי קולנוע מקוונים, בוני אתרים, פורטלים לשירותים אלקטרוניים, פלטפורמות אירוח וידאו, פורטלים נושאיים

אלה רק חלק מהסוגים הטכניים של אתרים שאנו עובדים איתם, ולכל אחד מהם יכולים להיות מאפיינים ופונקציונליות ספציפיים משלו, וכן ניתן להתאים אותם לצרכים ולמטרות הספציפיים של הלקוח.

השירותים שאנו מציעים
מציג 1 מתוך 1כל 2062 השירותים
בדיקת A/B עם פיצול URL והגנה על SEO
בינוני
~3-5 ימים

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113
  • פיתוח אתר עבור SBH Partners
    פיתוח אתר עבור SBH Partners
    1201
  • פיתוח אתר עבור Red Pear
    פיתוח אתר עבור Red Pear
    619

כאשר לקוח הזמין עיצוב מחדש של דף מוצר מתבנית PHP קלאסית ל-React SPA, התמודדנו עם האתגר של השוואה נכונה בין שתי הגרסאות. טכנולוגיות שונות, זמני טעינה שונים, DOM שונה — מבחן A/B סטנדרטי על אותו URL לא היה עובד. נדרש מבחן Split URL עם כתובות שונות. ללא הגדרה נכונה, מנועי החיפוש היו משכפלים את הדפים, ומשתמשים היו רואים את שתי הגרסאות. הגדרה שגויה עלולה הייתה לעלות בעשרות דולרים של חיסכון (~$9–13) באובדן תנועה ונתונים לא תקפים. הגדרנו את המבחן עם עוגיית sticky, קישור canonical, ושילבנו אותו עם GA4. תוצאה: React הגדילה את ההמרה ב-23% (p=0.01) והפחיתה את זמן הטעינה ב-40%. ללא הגנת SEO, הנתונים האלה לא היו אמינים. לכן אנחנו תמיד מוסיפים canonical ועוגיית sticky. הגדרת מבחן split URL מחזירה את עצמה תוך חודשיים, וחוסכת עד $2.7k–3.9k בשנה. העלות נקבעת לאחר ניתוח הפרויקט שלכם.

הגדרה של מבחן Split URL

מבחן Split URL הוא שיטת בדיקת A/B שבה גרסאות שונות של דף ממוקמות בכתובות URL שונות. זה מאפשר לבדוק שינויי עיצוב רדיקליים, טכנולוגיות או פלטפורמות ללא המגבלות של מבחן A/B רגיל.

מתי יש צורך ב-Split URL?

  • עיצוב דף חדש לחלוטין מול הישן
  • השוואת שני דפי נחיתה שונים
  • בדיקת תהליך רכישה חדש מול הישן
  • השוואת CMS או טכנולוגיות שונות עבור דף אחד (React SPA מול HTML סטטי)

80% מהלקוחות שלנו מזמינים Split URL במיוחד עבור עיצוב מחדש של דף מפתח — התוצאה תמיד ניתנת למדידה.

איך להגדיר מבחן Split URL ב-5 שלבים

  1. הגדירו את כתובות ה-URL של הבקרה והגרסה. הבקרה היא הגרסה הנוכחית, הגרסה היא החדשה. ודאו ששתיהן נגישות דרך כתובות שונות.
  2. הגדירו עוגיית sticky. השתמשו ב-nginx split_clients או ב-Cloudflare Workers. העוגייה צריכה לחיות לפחות 30 יום.
  3. הוסיפו canonical ו-noindex. בגרסת הבקרה — self-canonical, בגרסה — noindex, follow.
  4. שלבו אנליטיקס. העבירו את הגרסה ל-GA4 או ל-Yandex.Metrica דרך user_properties.
  5. השיקו את המבחן ועקבו. מדגם מינימלי — 5000 מבקרים ייחודיים לכל גרסה.

עוגיית sticky: מנגנון לקיבוע הגרסה

אתגר מרכזי ב-Split URL הוא להבטיח שמשתמשים יראו את אותה גרסה בביקורים חוזרים. אנחנו פותרים זאת עם עוגייה מתמשכת (למשל, 30 יום). בביקור הראשון, גרסה מוקצית אקראית ונשמרת. בקשות עוקבות בודקות את העוגייה ומגישות את אותה גרסה. דוגמה דרך nginx:

split_clients "${remote_addr}${http_user_agent}${date_gmt}" $split_variant {
    50% "variant";
    * "control";
}

server {
    listen 80;
    server_name company.com;

    location = /landing {
        if ($cookie_ab_landing = "variant") {
            rewrite ^ /landing-v2 last;
        }
        add_header Set-Cookie "ab_landing=$split_variant; Path=/; Max-Age=2592000; SameSite=Lax";
    }
}

איך לבחור בין nginx ל-Cloudflare Workers?

nginx split_clients מוגדר פי 2 מהר יותר מ-Cloudflare Workers ודורש פחות משאבי שרת. Cloudflare Workers אידיאליים עבור edge computing, ומפחיתים את זמן האחזור ב-30% באמצעות ביצוע בקצה. אם האתר שלכם על Cloudflare, Workers הם בחירה טבעית. אחרת, nginx מספק לוגיקת צד שרת פשוטה ואמינה יותר.

למה canonical חשוב ל-SEO?

שני URLs דומים ללא canonical יוצרים תוכן כפול. אנחנו תמיד מוסיפים split_clients "${remote_addr}${http_user_agent}${date_gmt}" $split_variant { 50% "variant"; * "control"; } server { listen 80; server_name company.com; location = /landing { if ($cookie_ab_landing = "variant") { rewrite ^ /landing-v2 last; } add_header Set-Cookie "ab_landing=$split_variant; Path=/; Max-Age=2592000; SameSite=Lax"; } } לגרסת הבקרה, ו-<link rel="canonical" href="..."> לגרסה במבחנים זמניים. למבחנים ארוכי טווח שבהם שתי הגרסאות צריכות להיות באינדקס, אנחנו משתמשים ב-noindex, follow. לפי MDN Web Docs, canonicalization נכון מונע בעיות דירוג.

הגדרה דרך Cloudflare Workers

אם משתמשים ב-Cloudflare, מבחן Split URL יכול לרוץ דרך Workers ללא שינויי backend. דוגמה:

addEventListener('fetch', event => {
  event.respondWith(handleSplitTest(event.request))
})

const CONTROL_URL = 'https://company.com/checkout-v1';
const VARIANT_URL = 'https://company.com/checkout-v2';
const TEST_PATH = '/checkout';

async function handleSplitTest(request) {
  const url = new URL(request.url);
  if (url.pathname !== TEST_PATH) return fetch(request);

  const cookie = request.headers.get('Cookie') || '';
  const match = cookie.match(/split_checkout=([^;]+)/);
  let variant = match ? match[1] : null;

  if (!variant) {
    const key = request.headers.get('CF-Connecting-IP') + request.headers.get('User-Agent');
    const hash = await hashKey(key);
    variant = hash % 2 === 0 ? 'control' : 'variant';
  }

  const target = variant === 'variant' ? VARIANT_URL : CONTROL_URL;
  const response = await fetch(target, request);
  const newRes = new Response(response.body, response);
  newRes.headers.append('Set-Cookie', `split_checkout=${variant}; Path=/; Max-Age=2592000; SameSite=Lax`);
  return newRes;
}

Cloudflare Workers מספקים זמן אחזור נמוך יותר מ-nginx בתרחישים רבים, אך דורשים יישום ידני של עוגיית sticky. אנחנו ממליצים על Workers כשהלקוח כבר על Cloudflare ורוצה להימנע משינויי שרת.

העברת נתונים לאנליטיקס

כדי למדוד המרה נכון, שלחו אירוע עם הגרסה ל-GA4:

const variant = getCookieValue('split_checkout') || 'control';
gtag('set', 'user_properties', { split_test_checkout: variant });
gtag('event', 'page_view', { split_test: 'checkout_redesign', split_variant: variant });
gtag('event', 'purchase', { transaction_id: orderId, value: total, split_test: 'checkout_redesign', split_variant: variant });

הגדירו יעדים ב-GA4 מראש. מבחן Split URL ללא אנליטיקס הוא רק שינוי URL. הלקוחות שלנו חוסכים עד 30% מתקציב השיווק בזכות נתונים ברורים. עם הגדרה נכונה, המבחן מחזיר את עצמו בתוך החודשיים הראשונים. קבלו ייעוץ לפרויקט שלכם.

מה כלול בעבודה

  • הגדרת שרת (nginx, Cloudflare Workers, או Varnish)
  • הגדרת עוגיית sticky
  • אינטגרציה עם GA4 או Yandex.Metrica
  • הגנת SEO (canonical, noindex)
  • בדיקות ואימות
  • תיעוד ההגדרות

לצוות שלנו יש 5 שנות ניסיון בבדיקות A/B והשלמנו מעל 100 פרויקטי split URL. אנחנו מבטיחים ללא באגי הפניה או אובדן סשן. צרו קשר להערכה.

שיטה עוגיית sticky מורכבות בקרת SEO ביצועים
nginx split_clients מובנית בינונית גבוהה גבוהים
Cloudflare Workers ידנית בינונית בינונית גבוהים
Varnish VCL דרך עוגייה גבוהה גבוהה גבוהים מאוד
שלב משך
ניתוח דרישות 2-4 שעות
עיצוב סכמה 2-4 שעות
הגדרת שרת/worker 4-8 שעות
אינטגרציית אנליטיקס 2-4 שעות
הגנת SEO 1-2 שעות
בדיקות 2-4 שעות
סה"כ 1–2 ימים

לוח זמנים ועלות

ההגדרה אורכת בין 1 ל-3 ימים תלוי במורכבות התשתית. עלות: מ-$150–500 בהתאם לפרטי הפרויקט שלכם. בקשו ייעוץ לקבלת הערכה מדויקת.