תגי Hreflang: השגיאה שגורמת לגוגל להתעלם מהעמודים הבינלאומיים שלך

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

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

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

אחת התקלות המשמעותיות ביותר במערכים של תגי Hreflang לאתרים בינלאומיים היא קישור חוזר חסר (Return Link). עמוד אחד מצביע על גרסה חלופית, אבל הגרסה החלופית אינה מצביעה עליו בחזרה. הקוד קיים, הכול נראה מסודר במבט מהיר — והחיבור עצמו לא הושלם.

חשוב לדייק כבר עכשיו: העמוד לא בהכרח ייעלם מ־Google. הבעיה היא ש־Google עלולה להתעלם מקשר ה־hreflang הלא־הדדי, ואז להציג לגולש את גרסת השפה או האזור הלא נכונה.

ממה Google באמת מתעלמת?

אם העמוד הישראלי מצהיר שהעמוד האמריקאי הוא גרסה חלופית שלו, אבל העמוד האמריקאי אינו מצביע עליו בחזרה, Google עלולה להתעלם מהצהרות ה־hreflang שבין אותו צמד עמודים.

האם זה אומר ששני העמודים נמחקים מהאינדקס? לא.

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

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

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

מה Hreflang עושה — ומה ממש לא

hreflang מתאר את הקשר בין כתובות URL שהן וריאציות של אותו תוכן עבור שפות או אזורים שונים. הוא נותן ל־Google אות שעוזר לה לבחור גרסה מתאימה יותר למשתמש.

זה התפקיד שלו. לא פחות, אבל גם לא יותר.

הוא לא קובע באיזו שפה העמוד כתוב

Google קובעת את שפת העמוד בעיקר לפי התוכן הגלוי. ערך כמו he-IL לא יהפוך עמוד באנגלית לעמוד בעברית, וגם שינוי המאפיין lang בתגית ה־HTML אינו תחליף לתרגום וללוקליזציה אמיתיים.

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

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

הוא לא כפתור שמקפיץ דירוגים

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

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

הוא לא מחליף Canonical

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

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

זה נשמע הגיוני כשמסבירים את זה כך, אבל הסתירה הזאת מופיעה במערכות שבהן ה־canonical נוצר מתבנית אחת וה־hreflang נוצר מתוסף אחר. לכן בבדיקה רצינית אני אף פעם לא מסתכל על כל תג בנפרד.

החץ חייב לחזור: כך נוצרת השגיאה המרכזית

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

למה נדרשת הדדיות? מפני שעמוד אחד לא אמור להכריז לבדו שכתובת אחרת היא הגרסה החלופית שלו. הקשר צריך לקבל אישור משני הצדדים. המבנה העקרוני נראה כך:

גרסה ישראלית  →  גרסה אמריקאית
גרסה ישראלית  ←  גרסה אמריקאית

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

האם קישור חסר אחד מפיל את כל האתר הבינלאומי? לא בהכרח. וזה דיוק חשוב.

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

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

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

כל עמוד צריך לזהות גם את עצמו

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

כך נראה מערך עקרוני שאמור להופיע בתוך אזור ה־<head> התקין:

<link rel="alternate" hreflang="he-IL" href="[כתובת מלאה לגרסה הישראלית]" />
<link rel="alternate" hreflang="en-US" href="[כתובת מלאה לגרסה האמריקאית]" />
<link rel="alternate" hreflang="en-GB" href="[כתובת מלאה לגרסה הבריטית]" />

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

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

בתור מקדם בגוגל, אני בודק גם אם לכל הגדרת locale יש משמעות חד־משמעית. נניח שבאותו אשכול שתי כתובות שונות מוגדרות כ־en-US. איזו מהן אמורה לשרת את הקהל האמריקאי? אם לצוות אין תשובה ברורה, קשה לצפות שמנוע החיפוש יפתור את העמימות במקומו.

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

קודי שפה ואזור: לפעמים תו אחד הוא כל התקלה

ערך hreflang מתחיל בקוד שפה, ולאחריו אפשר להוסיף קוד אזור. he מייצג עברית ללא יעד אזורי מסוים, ואילו he-IL מייצג עברית שמיועדת לישראל. באותה צורה, en מייצג אנגלית כללית, en-US מיועד לארצות הברית ו־en-GB לבריטניה.

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

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

אי אפשר לציין מדינה בלבד, מפני שהחלק הראשון תמיד מתפרש כשפה. אפשר גם להוסיף קוד כתב כשיש בכך צורך, למשל zh-Hans לסינית בכתב מפושט ו־zh-Hant לסינית בכתב מסורתי.

הצורה הנקייה והמקובלת היא לכתוב את קוד השפה באותיות קטנות, את קוד האזור באותיות גדולות ואת קוד הכתב באות ראשונה גדולה. לדוגמה: en-US או zh-Hans. ההשוואה לפי התקן אינה אמורה להיות רגישה לאותיות גדולות וקטנות, אבל אחידות עושה סדר ומקילה מאוד על הבדיקות.

יש כאן עוד מלכודת שכדאי להכיר: קוד יכול להיות תקין לפי תקן שפה רחב, אך לא להיתמך ביישום של Google. הדוגמה הבולטת היא es-419, שמתאר ספרדית באמריקה הלטינית. זהו תג תקני, אבל Google אינה תומכת בו לצורך יישום hreflang.

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

מתי נכון להשתמש ב־x-default?

x-default אינו קוד שפה ואינו קוד מדינה. הוא מיועד לעמוד ברירת מחדל שאינו פונה לקהל יחיד — למשל גרסה גלובלית, מסך לבחירת מדינה ושפה או עמוד כללי שממנו המשתמש ממשיך לאזור המתאים לו.

האם הוא חובה בכל אתר בינלאומי? לא.

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

מבחינתי, ההחלטה צריכה להתחיל בחוויית המשתמש: לאן באמת תרצו לשלוח אדם שאין עבורו התאמה ברורה? אם התשובה היא עמוד שימושי לבחירת מדינה, יש ל־x-default תפקיד. אם התשובה היא ״לעמוד כלשהו באנגלית״, כדאי לעצור ולחשוב שוב.

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

HTML, כותרת HTTP או מפת אתר: צריך מקור אמת אחד

Google תומכת בשלוש דרכי יישום: תגיות HTML, כותרת HTTP מסוג Link ומפת אתר XML. שלושתן תקינות מבחינתה. אין יתרון חיפוש מובנה ביישום של כולן יחד.

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

תגיות HTML מתאימות לעמודי אתר רגילים, במיוחד כאשר מערכת ניהול התוכן מסוגלת לייצר אותן על בסיס נתוני התרגום. התגיות צריכות להופיע בתוך <head> תקין. אין לשלב באותה תגית link כמה סוגים של ייצוגים חלופיים, למשל hreflang ו־media.

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

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

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

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

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

כשה־Canonical אומר דבר אחד וה־Hreflang דבר אחר

במבנה בינלאומי מסודר, לכל גרסה מקומית מוגדר בדרך כלל canonical שמפנה אליה עצמה, כל עוד היא עמוד עצמאי שראוי לאינדוקס. ה־hreflang מחבר אותה לגרסאות המקבילות. כך כל אחד מהאותות ממלא את התפקיד שלו בלי לדרוך על האחר.

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

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

האם העמוד החלופי זמין? האם הוא מפנה לכתובת אחרת? האם הוא מסומן ב־noindex? האם ה־canonical שלו מוביל למקום בלתי צפוי? תג יכול להיות כתוב בצורה מושלמת ועדיין להצביע על עמוד שאינו מסוגל למלא את התפקיד שהוגדר לו.

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

כך אני בודק מערך Hreflang בלי לנחש

1. מתחילים בהחלטה העסקית

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

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

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

2. בונים מטריצה של כל הגרסאות

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

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

בעמוד בודד הכול עשוי להיראות מסודר. רק כשמציבים את כל החצים זה לצד זה רואים אם נוצרה מערכת או רק אוסף של קישורים.

3. בודקים כתובות, קודים ותוכן אמיתי

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

ואז מגיעה בדיקה ידנית שאסור לדלג עליה: האם התוכן באמת מתאים להגדרת ה־locale שנקבעה? האם המחיר, המשלוח, פרטי הקשר, המידות והקריאה לפעולה מתאימים למדינה? האם המשתמש יכול להשלים את הפעולה באותה שפה?

כאן ה־SEO פוגש את העסק. אין הרבה ערך בהצגת העמוד ״הנכון״ אם ההצעה שבתוכו עדיין שייכת לשוק אחר.

4. בודקים מי מייצר את התגיות ומה קורה בשינוי הבא

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

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

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

טעויות Hreflang שאני לא ממליץ להשאיר באוויר

• קישור חד־כיווני: גרסה אחת מצביעה על גרסה אחרת, אבל אין קישור חוזר. Google עלולה להתעלם מהקשר בין אותו זוג.
• היעדר הפניה עצמית: העמוד מפרט את כל השפות חוץ מעצמו, בניגוד למבנה שאמור להופיע באשכול.
• כתובות יחסיות: שימוש בנתיב בלבד במקום בכתובת מוחלטת הכוללת פרוטוקול, דומיין ונתיב מלא.
• מדינה בלי שפה: ערך כמו IL או US אינו יעד תקין, משום שקוד השפה חייב להופיע ראשון.
• מבנה קוד שגוי: קו תחתון במקום מקף, סדר הפוך או קוד אזור שאינו הקוד הנתמך.
• קוד תקני שאינו נתמך: ההנחה שכל תג BCP 47 יעבוד בהכרח גם ביישום של Google.
• שתי כתובות לאותה הגדרת locale: שני עמודים שונים מוכרזים כגרסה שמיועדת לאותו שוק, בלי הבחנה ברורה ביניהם.
• יעד שמפנה הלאה: התג מוביל לכתובת ישנה במקום לכתובת הסופית והיציבה.
• סתירה מול canonical: העמוד מוצג כגרסה מקומית עצמאית, אך ה־canonical מאחד אותו עם גרסה בשפה אחרת או באזור אחר.
• שיטות יישום לא מסונכרנות: תגיות HTML מציגות מערך אחד ומפת האתר מציגה מערך אחר.
• חיבור בין עמודים שאינם מקבילים: מוצר בשפה אחת מצביע על קטגוריה או על עמוד בית בשפה אחרת.
• השקה חלקית ללא כללים למצבי חסר: המערכת מייצרת תג גם כאשר התרגום עוד לא פורסם או שהמוצר אינו קיים באותו שוק.

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

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

נקודות שחשוב לשאול עליהן לפני שמאשרים את היישום

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

• מי הקהל? האם האתר פונה לדוברי שפות שונות, למדינות שונות או לשילוב ביניהן?
• אילו עמודים באמת מקבילים? האם מדובר באותו מוצר או שירות בגרסה מקומית, או בעמודים שרק דומים בנושא?
• האם נדרשת חלוקה אזורית? האם יש צורך בגרסאות נפרדות כמו en-US ו־en-GB, או שקוד שפה כללי מספיק?
• מה חסר בחלק מהשווקים? אילו מוצרים, קטגוריות או שירותים אינם קיימים בכל המדינות, ומה המערכת עושה במצב כזה?
• האם יש ברירת מחדל אמיתית? האם קיים עמוד שמתאים בפועל לתפקיד x-default, ולא סתם עמוד שנבחר כדי למלא שורה?
• מהו מקור האמת? האם הקשרים מנוהלים ב־HTML, בכותרות HTTP או במפת אתר, ומי אחראי לעדכן אותם?
• מה אומר ה־canonical? מהי הכתובת הקנונית של כל גרסה, והאם אותו עמוד אמור להיות מאונדקס בפני עצמו?
• מה קורה בשינוי? מי מעדכן את הקשרים כאשר כתובת משתנה, מוצר יורד או תרגום מתעכב?
• איך נמנעת עמימות? כיצד המערכת מונעת יצירה של שתי כתובות שונות לאותה הגדרת locale?
• איך מאמתים את התוצאה? איזו בדיקה מתבצעת אחרי שינוי תבנית, מעבר אתר, השקת תרגום או פתיחת שוק חדש?

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

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

טיפ מקצועי: הפכו את בדיקת ההדדיות לתנאי לפריסה

במבט חוזר: התג הוא רק החלק שרואים מבחוץ

השגיאה המרכזית אינה רק שורת קוד חסרה, אלא גם ההנחה שאם עמוד אחד הכריז על גרסה אחרת, העבודה הסתיימה. הקשר צריך לחזור, כל עמוד צריך לזהות גם את עצמו, הקודים צריכים להתאים לקהל וה־canonical צריך לתמוך באותו מבנה.

אם אחד החיבורים נשבר, Google אינה בהכרח מתעלמת מהעמודים עצמם. היא עלולה להתעלם מהקשר ביניהם.

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

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