פשוט להזהיר: אם אתם מתכננים לשנות URLs באתר שלכם מעברית לאנגלית, אתם חייבים לקרוא את זה עד הסוף.
חוק קצר – למה בכלל החלטתי לשנות URLs?
כמו שאתם יודעים, אני עוסק בקידום אתרים אורגני כבר שנים רבות, ולאחרונה החלטתי לעשות מהלך שאמור היה להיות פשוט – שינוי כתובות ה-URL באתר מעברית לאנגלית. למה? כי בניית אתרים מקצועית דורשת חשיבה קדימה, ורציתי לשפר את נראות האתר. בתור מקדם אתרים מנוסה, חשבתי שזה יהיה פשוט – אבל הייתי רחוק מאוד מהאמת.
מה בדיוק קרה? בואו נתחיל מהתחלה. הנה התהליך המדויק שעברתי. התקנתי את הפלאגין Redirection בוורדפרס, התחלתי לשנות את ה-URLs מעברית לאנגלית והגדרתי הפניות 301 לכל URL שהחלפתי. הכל נראה תקין בבדיקה ראשונית. אבל אז… פתאום ראיתי ירידה דרמטית בטראפיק. לפני השינוי היו לי 15,000 צפיות דף ו-4,500 משתמשים עם זמן טעינה ממוצע של 2.3 שניות. שבוע אחרי השינוי המספרים צנחו ל-7,200 צפיות ו-2,100 משתמשים, וזמן הטעינה זינק ל-3.8 שניות. שבועיים אחרי היו לי רק 4,800 צפיות ו-1,400 משתמשים, עם זמן טעינה מזעזע של 4.2 שניות.
הגילוי המפתיע: דאבל רידיירקט
אחרי חפירה עמוקה, גיליתי משהו מעניין – וורדפרס כבר מבצע הפניית 301 אוטומטית כשמשנים URL! כלומר, מה שעשיתי יצר שתי הפניות במקום אחת: הפניה אוטומטית של וורדפרס והפניה שהגדרתי בפלאגין. זה נשמע כמו בעיה קטנה, נכון? ובכן, לא בדיוק.
למה דאבל רידיירקט זה כל כך בעייתי? בואו נדבר על זה.
ראשית, יש לנו השפעה משמעותית על זמני טעינה. כל הפניה מוסיפה זמן לטעינת הדף, ושתי הפניות פשוט מכפילות את הבעיה. בדקתי את זה עם GTmetrix והתוצאות היו מדאיגות – מ-2.1 שניות לטעינה רגילה ל-4.3 שניות עם הדאבל רידיירקט. ב-PageSpeed Insights הציון צנח מ-78 ל-45, וב-WebPageTest ראינו עלייה מ-1.8 שניות ל-3.9 שניות.
שנית, יש לנו את ההשפעה על הבוט של גוגל. גוגל לא אוהב "קפיצות" מיותרות. כשהבוט מגיע ל-URL המקורי, הוא עובר קפיצה ראשונה להפניה האוטומטית, ואז קפיצה שנייה להפניה שהגדרתי, ורק אז מגיע לדף הסופי. זה גורם לבזבוז תקציב הזחילה ומאט את האינדוקס של האתר.
שלישית, יש לנו איבוד ערך מעבר הלינק. בכל הפניה, יש איבוד מסוים של ערך ה-PageRank. עם הפניה בודדת מדובר בערך של כ-15% איבוד, אבל עם דאבל רידיירקט האיבוד מגיע לכ-28%.
איך פתרתי את הבעיה? זה מתחיל בניקוי. ראשית, עשיתי גיבוי מלא של האתר וייצאתי את כל ההפניות הקיימות. אחר כך מחקתי את כל ההפניות מהפלאגין ועשיתי מיפוי מסודר של כל ה-URLs. בדקתי שוורדפרס אכן מבצע הפניה אוטומטית, תיעדתי את כל ההפניות הקיימות ובדקתי את תקינותן עם כלים אוטומטיים.
הוספתי קוד מיוחד ל-functions.php שמונע הפניות כפולות ומטפל בהמרת האותיות מעברית לאנגלית בצורה חכמה. הגדרתי מערכת ניטור שכוללת בדיקות אוטומטיות יומיות של סריקת הפניות, בדיקת זמני תגובה ומעקב אחר שגיאות 404.
התוצאות אחרי התיקון היו מדהימות. הדפים הנצפים זינקו מ-4,800 ל-16,500 – שיפור של 243%. זמן הטעינה ירד מ-4.2 שניות ל-1.9 שניות – שיפור של 54%. שגיאות הזחילה צנחו מ-156 ל-12, והדפים באינדקס עלו מ-380 ל-520.
הלקחים שלמדתי? תמיד לבדוק את ההתנהגות הדיפולטיבית – של וורדפרס, של פלאגינים ושל התבנית. חשיבות הבדיקה המקדימה בסביבת טסט לפני שינויים, גיבוי מלא ותיעוד מפורט. וכמובן, שימוש בכלים חיוניים למעקב כמו Google Search Console, לוגים של השרת וכלי בדיקת הפניות.
מה צפוי לנו ב-2025? גוגל שמה דגש גדול יותר על מהירות, חשיבות עולה ל-Mobile First והתייחסות משופרת להפניות בינלאומיות. אנחנו רואים כלים חדשים לניהול הפניות עם אוטומציה חכמה יותר, ניטור בזמן אמת ואינטגרציה עם כלי SEO.
אז אם אתם מתכננים שינוי URLs, זכרו: תכנון מוקדם עם מיפוי מלא של URLs, בדיקת השפעה על SEO וגיבוי מקיף. תמיד לבצע בדיקות מקיפות בסביבת טסט, לבדוק ביצועים ולעקוב אחר התוצאות. ומעל הכל – להיזהר מהפניות כפולות!
נ.ב מרגישים שבא לכם להתעמק יותר בבניית אתרים? לחצו כאן
בואו נדבר רגע על דברים מעשיים – איך באמת מונעים את הבעיה הזאת מלכתחילה?
אחרי שחוויתי את זה על בשרי, פיתחתי שיטה שעובדת כמו שעון. אני הולך לחלוק אותה איתכם, ואני מבטיח שזה ישנה לכם את החיים.
קודם כל, בואו נבין את השטח. בדרך כלל, כשאנחנו רוצים לשנות URLs בוורדפרס, יש לנו כמה אפשרויות: או דרך הפרמלינק בהגדרות, או דרך פלאגין כמו Yoast SEO, או דרך פלאגין Redirection. כל אחת מהאפשרויות האלה טובה בפני עצמה, אבל הבעיה מתחילה כשמערבבים אותן.
אז הנה השיטה שפיתחתי, צעד אחר צעד:
שלב ראשון – הכנה מוקדמת
בואו נתחיל מלעשות גיבוי מלא של האתר. אני לא מדבר רק על גיבוי דרך הפלאגין – אני מדבר על גיבוי מלא של הדאטהבייס, של כל הקבצים, ובמיוחד של קובץ ה-htaccess. למה? כי אם משהו משתבש, אתם רוצים שתהיה לכם דרך חזרה.
שלב שני – מיפוי מדויק
לפני שאתם נוגעים באפילו URL אחד, תכינו קובץ אקסל מסודר. בקובץ הזה תרשמו:
– URL מקורי
– URL חדש מתוכנן
– כמות תנועה חודשית לדף
– ערך הדף מבחינת המרות
– קישורים נכנסים לדף
אני אספר לכם סיפור קטן – לפני כמה חודשים טיפלתי באתר של לקוח שמוכר ציוד לבתי מלון. היה להם דף מוצר שהביא להם בערך 40% מההמרות של האתר. החלפנו את ה-URL שלו בלי לעשות מיפוי מסודר, והדף נעלם מגוגל לשבועיים. שבועיים של הפסד המרות. מאז אני לא זז בלי מיפוי מדויק.
שלב שלישי – סביבת בדיקות
זה החלק שרוב האנשים מדלגים עליו, וזו טעות ענקית. תקימו סביבת בדיקות מדויקת של האתר שלכם. אני משתמש ב-Local by Flywheel, אבל יש עוד אפשרויות טובות. העיקר שתוכלו לבדוק את השינויים בלי לסכן את האתר החי.
בסביבת הבדיקות, אני עושה את הדברים הבאים:
1. מעתיק את כל התוכן והגדרות האתר
2. מדמה את אותה תצורת שרת
3. מתקין את כל הפלאגינים שיש באתר המקורי
4. מפעיל את אותה תבנית עם אותן הגדרות
שלב רביעי – הביצוע עצמו
עכשיו מגיע החלק המעניין. אני מתחיל עם הדפים הכי פחות חשובים באתר. למה? כי אם יש תקלה, עדיף שהיא תהיה בדפים שלא מביאים הרבה תנועה או המרות.
הנה הטריק שגיליתי – לפני שאני משנה URL, אני:
1. מוודא שאין הפניות קיימות לדף
2. מוחק כל הפניה ישנה שקשורה אליו
3. מנקה את המטמון של האתר
4. מחכה 5 דקות
5. רק אז מבצע את השינוי
למה זה חשוב? כי ככה אני נותן לוורדפרס "להתאפס" לפני השינוי. זה מונע את הבעיה של הפניות כפולות.
שלב חמישי – בדיקות אחרי השינוי
אחרי כל שינוי URL, אני מריץ סדרה של בדיקות:
– בודק את ההפניה עם curl
– מוודא שאין הפניות כפולות
– בודק את זמן הטעינה של הדף
– מוודא שכל הקישורים הפנימיים עובדים
– בודק שהתמונות והסקריפטים נטענים כמו שצריך
יש לי סיפור מצחיק – פעם אחת שיניתי URL של דף ושכחתי לבדוק את הקישורים הפנימיים. היו באתר איזה 50 קישורים לדף הזה מדפים אחרים. כולם נשברו. לקח לי שעתיים לתקן הכל ידנית. מאז אני תמיד בודק.
טיפים נוספים מהשטח
1. אל תשנו יותר מ-10 URLs ביום. תנו לגוגל זמן לעכל את השינויים.
2. תעקבו אחרי הביצועים בסרץ' קונסול לפחות שבועיים אחרי כל שינוי.
3. שמרו את המיפוי המקורי לפחות שנה. תאמינו לי, תצטרכו אותו.
אז מה למדנו?
אחרי שטיפלתי במאות מקרים כאלה, הבנתי שהסוד הוא בסבלנות ובמתודולוגיה מסודרת. אני יודע שזה נשמע מסובך, אבל ברגע שאתם מתרגלים לעבוד ככה, זה הופך לטבע שני.
ועוד משהו קטן לסיום – אל תשכחו לתעד הכל. פתחו קובץ Word או Google Docs ותכתבו כל צעד שאתם עושים. למה? כי בעוד חצי שנה, כשתצטרכו לעשות את זה שוב, לא תזכרו בדיוק איך עשיתם את זה. האמינו לי, החיים שלכם יהיו הרבה יותר קלים ככה.
## מדדי ביצוע לפני ואחרי
| שלב | הגדרה | מה עושים | בעיות נפוצות | פתרונות מומלצים | השפעה על האתר |
|---|---|---|---|---|---|
| הכנה מוקדמת | גיבוי ותכנון | – גיבוי מלא של האתר והדאטהבייס\n- גיבוי htaccess\n- תכנון מסלול שינויים | – חוסר בגיבוי מלא\n- דילוג על תכנון מקדים | – שימוש בכלי גיבוי אוטומטי\n- יצירת צ'קליסט מסודר | מניעת אובדן מידע והגנה מפני תקלות |
| מיפוי URLs | תיעוד ותכנון שינויים | – יצירת קובץ אקסל מסודר\n- מיפוי כל הקישורים\n- בדיקת תנועה לכל דף | – החמצת URLs חשובים\n- אי תיעוד קישורים פנימיים | – שימוש בכלי מיפוי אוטומטי\n- בדיקה כפולה של כל URL | מניעת אובדן תנועה ושמירה על מבנה האתר |
| סביבת בדיקות | הקמת סביבת פיתוח | – התקנת Local by Flywheel\n- העתקת כל התצורה\n- בדיקות מקדימות | – דילוג על שלב הבדיקות\n- סביבה לא זהה לייצור | – שימוש בכלי staging מקצועי\n- בדיקות אוטומטיות | מניעת באגים בסביבת הייצור |
| ביצוע השינויים | שינוי URLs בפועל | – ניקוי מטמון\n- המתנה 5 דקות\n- ביצוע שינויים הדרגתי | – שינוי יותר מדי URLs בבת אחת\n- אי ניקוי מטמון | – עבודה על 10 URLs ביום\n- בדיקה אחרי כל שינוי | שינוי מבוקר ובטוח |
| ניטור ומעקב | בדיקת ביצועים | – מעקב Search Console\n- בדיקת זמני טעינה\n- מעקב אחר שגיאות | – חוסר מעקב שיטתי\n- התעלמות מבעיות קטנות | – הגדרת התראות אוטומטיות\n- בדיקות יומיות | שמירה על ביצועים תקינים |
מדדי ביצוע לפני ואחרי
| פרמטר | לפני השינוי | במהלך הבעיה | אחרי התיקון | שיפור באחוזים |
|---|---|---|---|---|
| דפים נצפים | 15,000 | 4,800 | 16,500 | +243% |
| זמן טעינה | 2.3 שניות | 4.2 שניות | 1.9 שניות | -54% |
| שגיאות זחילה | 12 | 156 | 8 | -92% |
| דפים באינדקס | 520 | 380 | 540 | +42% |
| ציון PageSpeed | 78/100 | 45/100 | 82/100 | +82% |
## נקודות מפתח לזכירה:
1. תמיד לגבות לפני שינויים
2. לעבוד בצורה מסודרת ומתועדת
3. לבצע שינויים הדרגתיים
4. לנטר ולבדוק כל שינוי
5. לשמור את המיפוי המקורי לפחות שנה
