הגדרת תת-דומיינים אזוריים: DNS, hreflang, הפניות

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

דמיינו משתמש גרמני נוחת באתר שלכם מגוגל גרמניה, רואה ממשק באנגלית, ועוזב תוך 3 שניות. שיעור נטישה 80%, המרה—אפס. הסיבה היא היעדר ניתוב אזורי. אנו פותרים בעיה זו: אנו מגדירים תת-דומיינים לכל אזור (ru.wikipedia.org, de.wikipedia.org), מפנים נכון על בסיס גיאוגרפיה ושפה, ומסמנים hreflang. להלן הערימה הטכנולוגית והתצורות הספציפיות שבהן אנו משתמשים בסביבת ייצור.

במהלך 10 השנים האחרונות, יישמנו יותר מ-50 פרויקטים עם תת-דומיינים רב-לשוניים—מחנויות מסחר אלקטרוני ועד פלטפורמות SaaS. תמונה אופיינית: לקוח מאבד עד 60% מהתנועה עקב גיאולוקציה שגויה. תת-דומיינים פותרים בעיה זו פי 3 יותר ביעילות מאשר תיקיות משנה.

מדוע תת-דומיינים אזוריים ולא תיקיות משנה?

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

אילו בעיות אנו פותרים?

• גיאולוקציה שגויה: משתמש מגרמניה נוחת בגרסה האנגלית—שיעור הנטישה עולה. ראינו פרויקטים שבהם הנטישה זינקה ל-70%. לאחר יישום תת-דומיינים עבור לקוח מסחר אלקטרוני, שיעור הנטישה ירד מ-72% ל-34% תוך חודש, וההמרה עלתה ב-25%.
• תוכן כפול: ללא hreflang, מנועי חיפוש מענישים על טקסטים זהים בתת-דומיינים שונים. לקוח אחד איבד 40% מהמיקומים עקב כך.
• טעינה איטית: היעדר CDN ושרתים אזוריים מעלה את TTFB. התצורות שלנו מפחיתות את TTFB ל-80 אלפיות השנייה.
• קשיי אינדוקס: הפניות שגויות והיעדר sitemap לכל תת-דומיין.

כיצד אנו מגדירים תת-דומיינים אזוריים

שלב 1: DNS ו-SSL

אנו מגדירים רשומות A עבור כל תת-דומיין, המצביעות על השרת הנדרש או מאזן העומס. לדוגמה, עבור הדומיין wikipedia.org, אנו יוצרים:

• *.site.com מצביע על שרת ברוסיה
• ; Каждый поддомен указывает на нужный сервер или балансировщик ru.example.com. IN A 185.10.1.1 ; сервер в России en.example.com. IN A 52.18.2.2 ; сервер в ЕС de.example.com. IN A 52.18.2.2 ; тот же сервер ЕС www.example.com. IN CNAME ru.example.com. מצביע על שרת באיחוד האירופי
• LOCALE מצביע על אותו שרת באיחוד האירופי

עבור SSL, אנו משתמשים בתעודת wildcard # ru.example.com server { listen 443 ssl http2; server_name ru.example.com; root /var/www/example.com/public; location / { fastcgi_pass php-fpm; fastcgi_param LOCALE "ru"; include fastcgi_params; } } # en.example.com server { listen 443 ssl http2; server_name en.example.com; root /var/www/example.com/public; location / { fastcgi_pass php-fpm; fastcgi_param LOCALE "en"; include fastcgi_params; } } או בתעודות נפרדות. תעודות Let's Encrypt הן בחינם, מה שמאפשר חיסכון משמעותי ב-SSL עבור כל תת-דומיין.

שלב 2: שרת האינטרנט (Nginx)

אנו יוצרים מארחים וירטואליים עבור כל תת-דומיין. אנו מעבירים את המשתנה // Middleware: LocaleFromSubdomain class SetLocaleFromSubdomain { public function handle(Request $request, Closure $next): Response { $subdomain = explode('.', $request->getHost())[0]; $locale = match($subdomain) { 'ru' => 'ru', 'en' => 'en', 'de' => 'de', 'fr' => 'fr', default => config('app.locale'), }; App::setLocale($locale); Carbon::setLocale($locale); return $next($request); } } ליישום.

; Каждый поддомен указывает на нужный сервер или балансировщик ru.example.com. IN A 185.10.1.1 ; сервер в России en.example.com. IN A 52.18.2.2 ; сервер в ЕС de.example.com. IN A 52.18.2.2 ; тот же сервер ЕС www.example.com. IN CNAME ru.example.com. 

שלב 3: Middleware של היישום (Laravel)

אנו קובעים את ה-locale מתוך תת-הדומיין ומגדירים אותו ביישום.

# ru.example.com server { listen 443 ssl http2; server_name ru.example.com; root /var/www/example.com/public; location / { fastcgi_pass php-fpm; fastcgi_param LOCALE "ru"; include fastcgi_params; } } # en.example.com server { listen 443 ssl http2; server_name en.example.com; root /var/www/example.com/public; location / { fastcgi_pass php-fpm; fastcgi_param LOCALE "en"; include fastcgi_params; } } 

שלב 4: hreflang ל-SEO

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

// Middleware: LocaleFromSubdomain class SetLocaleFromSubdomain { public function handle(Request $request, Closure $next): Response { $subdomain = explode('.', $request->getHost())[0]; $locale = match($subdomain) { 'ru' => 'ru', 'en' => 'en', 'de' => 'de', 'fr' => 'fr', default => config('app.locale'), }; App::setLocale($locale); Carbon::setLocale($locale); return $next($request); } } 

שלב 5: הפניה לתת-דומיין אזורי

אנו מפנים משתמשים מהדומיין הראשי לתת-הדומיין המתאים על בסיס GeoIP ו-Accept-Language.

// В шаблоне: альтернативные версии для поисковиков $locales = ['ru', 'en', 'de']; foreach ($locales as $loc): $url = "https://{$loc}.example.com" . request()->getPathInfo(); ?> <link rel="alternate" hreflang="<?= $loc ?>" href="<?= $url ?>" /> <?php endforeach; ?> <link rel="alternate" hreflang="x-default" href="https://en.example.com<?= request()->getPathInfo() ?>" /> 

כיצד לקבוע את האזור של המשתמש?

אנו משתמשים בשילוב של שיטות: מסד נתונים של GeoIP (MaxMind), כותרת HTTP Accept-Language, וקובצי Cookie של העדפות משתמש. סדר העדיפויות הוא בדרך כלל: cookie > Accept-Language > GeoIP. אנו מיישמים לוגיקה זו ב-middleware של היישום.

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

• רשומות DNS ותעודות SSL עבור כל תת-הדומיינים
• תצורת Nginx/Apache עם העברת locale
• Middleware לזיהוי והגדרת locale
• hreflang סימון בכל העמודים
• הפניות מהדומיין הראשי לתת-הדומיינים האזוריים
• תיעוד תחזוקה
• בדיקות על שרת staging

רשימת בדיקה מפורטת להגדרה:

• לוודא ש-SSL מוגדר עבור כל תת-דומיין (Let's Encrypt או wildcard)
• לוודא ש-Nginx מעביר את המשתנה LOCALE ליישום
• להגדיר middleware לזיהוי locale אוטומטי מתוך תת-הדומיין
• לייצר תגי hreflang עבור כל גרסאות השפה
• להגדיר הפניות מהדומיין הראשי לתת-הדומיין האזורי (301)
• לבדוק הפניות ואינדוקס ב-Google Search Console
• להגדיר sitemaps עבור כל תת-דומיין

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

הגדרה בסיסית (עד 5 תת-דומיינים)—מיומיים עד 3 ימי עבודה, עלות מ-$500 עד $1,000. תצורות מורכבות (GeoIP, CDN, לוגיקה מותאמת אישית)—מ-5 עד 7 ימים, עלות מ-$1,500 עד $3,000. העלות מחושבת באופן אישי, בהתאם להיקף העבודה ולערימה הטכנולוגית. חיסכון בתקציב הפרסום עקב מיקוד גיאוגרפי נכון יכול להגיע ל-50%, כלומר הכנסה משוחזרת של אלפי דולרים.

כיצד מתנהלת העבודה

1. ניתוח: זיהוי אזורים, בחירת אסטרטגיה (תת-דומיינים לעומת תיקיות משנה).
2. תכנון: תכנית DNS, תצורות שרת, middleware.
3. יישום: הגדרת שרת, קידוד, סימון hreflang.
4. בדיקות: בדיקת הפניות, אינדוקס, מהירות.
5. פריסה וניטור.

צרו קשר כדי לדון בפרויקט שלכם. הזמינו הגדרה מוכנה לשימוש של תת-דומיינים אזוריים—קבלו ייעוץ ממהנדס עם ניסיון של 10+ שנים. אנו מבטיחים הגדרה חלקה וידידותית ל-SEO.