www, apex ו-wildcard forwarding בלי לשבור SEO

host normalization נראה כמו משימת DNS קטנה. אבל ברגע שנכנסים ל-migration או rebrand עם traffic אמיתי, זה הופך מהר מאוד לעניין של URL policy.

המותג רוצה apex domain. האתר הישן משתמש ב-www. חלק מהתוכן או הקמפיין יושב על subdomain. הסוכנות מבקשת wildcard forwarding. קישורי פרסום עדיין צריכים לשמור path ו-UTM. אם כל החלטה מתקבלת בנפרד, בדרך כלל נוצר redirect chain.

השאלה החשובה איננה האם www או apex טובים תמיד. השאלה היא: איזה host יהיה canonical, ואיך שאר ה-variants יישרו קו.

אם זה חלק מ-migration גדול יותר, התחילו ב-רשימת הבדיקה ל-Website Migration Redirects. המאמר הזה מתמקד רק ב-host layer.

host הוא חלק מ-URL policy

example.co.il, www.example.co.il ו-*.example.co.il לא זהים מבחינה תפעולית.

apex נראה נקי יותר ב-marketing.
www נפוץ ב-stack ישן.
subdomain יכול להיות product, docs, support או store.
wildcard מתאים כשכמה host-ים צריכים לעקוב אחרי אותו rule.

העיקר הוא לא להשאיר את זה למקריות.

Host normalization map for apex, www, and wildcard subdomains

בחרו canonical host לפני ה-launch

ענו מוקדם על השאלות הבאות:

שאלה	למה זה חשוב
האם האתר יפעל על apex או `www`	קובע את ה-canonical URL הנראה
אילו subdomains הם aliases	לא כל subdomain צריך להתאחד
האם path נשמר	SEO, bookmark ו-deep links תלויים בזה
האם query string נשמר	UTM, coupon ו-ID עלולים להיעלם
האם יש exceptions זמניים	קמפיינים ו-launch עשויים לדרוש כלל שונה

אם התשובות האלה נשארות פתוחות, כמה layers יתחילו לנסות לעזור בו-זמנית.

DNS לא פותר הכול

DNS אומר לאן traffic צריך ללכת. הוא לא קובע לבד את שינוי ה-URL הנראה.

זרימה נקייה:

http://www.old-brand.example/pricing?utm_source=email
  -> https://new-brand.example/pricing?utm_source=email

זרימה שבירה:

http://www.old-brand.example/pricing
  -> https://www.old-brand.example/pricing
  -> https://old-brand.example/pricing
  -> https://new-brand.example/pricing

hop אחד קל יותר לבדוק, להסביר ולתחזק.

Wildcard forwarding עובד כשהמבנה נשאר תואם

Wildcard rule מועיל כשה-path נשארים תואמים:

old.example.co.il/* -> new.example.co.il/$1

מתאים כאשר:

יש הרבה URL-ים ישנים שצריך לשמר
מבנה ה-path השתנה מעט
לא רוצים לכתוב rule לכל page
subdomain ישן הוא alias אמיתי

אם הארכיטקטורה השתנתה מאוד, חשוב למפות את ה-URL-ים החשובים במפורש.

שמרו על path ועל query

שינוי host לא אמור למחוק את ההקשר של הבקשה.

http://old.example.co.il/docs/api?ref=partner&utm_source=newsletter

אם המבנה מאפשר זאת, זה צריך להסתיים ב:

https://new.example.co.il/docs/api?ref=partner&utm_source=newsletter

זה חשוב עבור:

דפי SEO
תיעוד
קמפיינים בתשלום
affiliate links
bookmarks של משתמשים

אם path או query נעלמים, ה-redirect נראה נכון טכנית אבל מאבד ערך.

הימנעו מ-chain

הטעות הנפוצה היא לפצל אחריות:

HTTP ל-HTTPS במקום אחד
www ל-apex במקום אחר
domain migration ב-CDN או hosting
האפליקציה מוסיפה עוד canonical rule

התוצאה היא http -> https -> www -> final.

אם ה-stack שלכם כבר נראה כך, ראו Redirect Chains and Loops.

בדקו launch matrix

לפני ההשקה, בדקו וריאנטים אמיתיים.

Test	Example
Apex root	`https://example.co.il/`
`www` root	`https://www.example.co.il/`
Deep path	`https://example.co.il/pricing`
Deep path with query	`https://example.co.il/pricing?utm_source=email`
Old host with path	`https://old.example.co.il/blog/post-1`
Wildcard subdomain	`https://docs.example.co.il/guide`

Launch QA matrix for canonical host, path preservation, query preservation, and redirect hops

בדקו:

final host נכון
path נשמר
query נשמר
status code תואם לכוונה
אין hop נוסף

איפה UrlEdge מתאים

UrlEdge מתאים כאשר host normalization צריך להיות מנוהל כ-routing policy, ולא כ-snippet מפוזר.

Free Redirect Service עבור HTTPS אוטומטי ו-wildcard forwarding
Advanced Redirect Rules עבור host logic מותנה
Redirect Checker לבדיקת hops אמיתיים
Domain redirect without losing path and query עבור הדפוס המלא

היתרון הוא מקום אחד שאחראי ל-canonical host, variants, path, query ו-status code.

FAQ

האם תמיד עדיף apex על פני www?

לא. שני הפתרונות יכולים לעבוד. העיקר הוא לבחור canonical host אחד ולגרום לשאר ה-variants לזרום אליו בצורה נקייה.

אפשר לטפל ב-wildcard subdomains עם rule אחד?

כן, אם המבנה נשאר תואם. אם הוא השתנה מאוד, צריך mapping מפורש ל-URL-ים החשובים.

האם DNS מספיק?

לא. DNS לא מחליף HTTP redirect policy שרואה המשתמש.

האם צריך לשמור campaign parameters?

בדרך כלל כן, אלא אם יש סיבה מפורשת להסיר אותם. attribution שאבד קשה לשחזר.

הפניות בסיסיות

ניתוב חכם

אבטחה וניטור

בדיקות וקמפיינים

בנו הפניה ראשונה

חברה וידע

משפטי ואמון

תיעוד UrlEdge