איך מתקנים בעיית קנוניקל בגוגל? קייס סטאדי מלא עם 301

מה זה קנוניקל בגוגל?

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

לדוגמה, מבחינת בעל האתר יכול להיות ברור לחלוטין שהעמוד הראשי הוא:

ובקוד של האתר אפילו יכולה להופיע תגית תקינה לחלוטין:

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

לכן קיימת ב-Search Console ההבחנה בין
“קנוניקל לפי הצהרת המשתמש”
לבין
“קנוניקל לפי בחירת Google”.

המקרה האמיתי: האתר החדש תקין, אבל Google עדיין בוחר בדומיין הישן

במקרה הזה האתר של אור ששון עבר מהכתובת הישנה
or-sasson.elisasi.co.il
לדומיין העצמאי
orsasson-law.co.il.

האתר החדש כבר היה פעיל, Sitemap חדש היה קיים והקנוניקל שהוגדר באתר הצביע לכתובת החדשה.
למרות זאת, בבדיקת דף הבית ב-Google Search Console הופיעה בעיית אינדוקס:
“עותק משוכפל, Google בחרה דף קנוני שונה מהמשתמש”.

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

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

למה לא מחקתי והתקנתי מחדש את האתר החדש?

אחת המחשבות הראשונות במקרה כזה יכולה להיות שמשהו “נדבק” להתקנת WordPress:
אולי בסיס הנתונים מכיל את הדומיין הישן, אולי Google מזהה את בעל האתר הקודם,
אולי צריך למחוק הכול ולהתחיל מחדש.

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

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

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

אימות הסאב־דומיין הישן ב-Google Search Console

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

הבעיה הייתה שאין יותר WordPress פעיל באתר הישן ולכן לא יכולתי פשוט
להדביק קוד אימות בתוך האתר.
הפתרון היה ליצור נכס מסוג Domain ב-Search Console ולאמת אותו באמצעות
רשומת TXT ב-DNS.

Google יצר קוד אימות שמתחיל ב-
google-site-verification.
את הקוד הכנסתי כרשומת TXT עבור
or-sasson.elisasi.co.il.

לא היה צורך לשנות את רשומות ה-A או לבטל את ההפניה.
רשומת TXT משמשת כאן רק להוכחת בעלות על הנכס.

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

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

השלב הקריטי: Change of Address ב-Search Console

הפניית 301 כבר אמרה ל-Google ברמת השרת שהכתובת עברה.
אבל במקרה של מעבר אמיתי בין דומיינים רציתי להוסיף עוד איתות מפורש:
שינוי כתובת באמצעות Google Search Console.

נכנסתי לנכס של האתר הישן, עברתי אל הגדרות > שינוי כתובת,
ובחרתי את orsasson-law.co.il בתור האתר החדש.

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

לאחר האישור Search Console הציג שהאתר נמצא בתהליך העברה,
עם האתר הישן מצד אחד והדומיין החדש מצד שני.

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

בדיקת כתובת האתר החדש ובקשת אינדוקס מחדש

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

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

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

חשוב להבין מה הפעולה הזאת עושה ומה היא לא עושה.
בקשת אינדוקס אינה כפתור “תקן קנוניקל”.
היא פשוט מבקשת מ-Google לחזור לעמוד ולבחון מחדש את המצב הנוכחי שלו.

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

ומה התפקיד של Sitemap בתיקון קנוניקל?

ה-Sitemap אינו תחליף להפניית 301 ואינו תחליף ל-canonical,
אבל הוא עוד מקום שבו אנחנו רוצים להיות עקביים.

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

והגשתי אותה דרך Search Console של האתר החדש.

למה השילוב הזה חזק יותר מלהחליף רק תגית Canonical?

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

במקרה הזה בנינו רצף עקבי:
הדומיין הישן מבצע 301 אל החדש,
האתר החדש מצהיר על עצמו כקנוניקל,
מפת האתר מכילה את הכתובות החדשות,
Search Console קיבל דיווח רשמי על שינוי הכתובת,
ולבסוף ביקשנו מ-Google לסרוק מחדש את העמוד לאחר שכל השינויים כבר קיימים.

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

שליחת בעיית הקנוניקל לאימות מחדש

לאחר השלמת ההפניה, האימות, שינוי הכתובת ובקשת הסריקה,
חזרתי לדוח האינדוקס שבו הופיעה הבעיה המקורית:
“עותק משוכפל, Google בחרה דף קנוני שונה מהמשתמש”.

הפעלתי מחדש את תהליך אימות התיקון.

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

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

מה הייתי בודק אם הבעיה לא תיפתר?

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

אז האם צריך להשאיר את האתר הישן פעיל?

לא צריך להשאיר עליו אתר WordPress ולא צריך להשאיר את התוכן הישן נגיש.
אבל כן צריך שהכתובת הישנה תמשיך להיות מסוגלת להחזיר את הפניית ה-301.

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

הטעות שהייתי נמנע ממנה: להפנות הכול לדף הבית

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

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

מה למדתי מהקייס הזה?

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

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

במקום “לשכנע את Google” באמצעות עוד ועוד בקשות אינדוקס,
המטרה היא ליצור מצב שבו כל האיתותים מצביעים לאותו כיוון.

שאלות נפוצות על בעיות Canonical בגוגל

סיכום: בעיית קנוניקל פותרים באמצעות עקביות, לא באמצעות ניחושים

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

במקום למחוק את האתר החדש או לשנות את התוכן,
יצרתי תהליך מעבר ברור:
החזרתי את הכתובת הישנה רק לצורך 301,
אימתתי אותה ב-Search Console דרך DNS,
הפעלתי Change of Address,
בדקתי את האתר החדש,
הגשתי אותו לסריקה מחדש,
וידאתי Sitemap חדש ושלחתי את בעיית הקנוניקל לאימות.

עכשיו הכדור אצל Google.
השלב הבא הוא לעקוב אחרי האימות ולוודא שבסריקה החדשה
orsasson-law.co.il
הופך גם לכתובת שהאתר מצהיר עליה וגם לכתובת ש-Google בוחר בפועל.