כתובות מוזרות באתר? לא כל דבר הוא בעיית SEO

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

הסיפור התחיל משאלה של איש SEO שנתקל באתר Squarespace בכתובת פנימית מוזרה שהופיעה בתוך HTML, נחסמה דרך robots.txt, ועדיין נמצאה בזחילה של Screaming Frog. זה בדיוק סוג הממצא שמכניס בעלי אתרים ללחץ: משהו נראה שבור, אי אפשר לערוך אותו דרך המערכת, והכלי מסמן שיש אליו קישורים פנימיים.

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

מה קרה במקרה שגוגל התייחסה אליו?

לפי הדיווח ב-Search Engine Journal, השאלה עסקה בכתובת שנוצרה אוטומטית על ידי Squarespace. הלקוח לא יצר את העמוד בכוונה, הכתובת הייתה חסומה ב-robots.txt, אבל כלי זחילה עדיין מצא קישורים פנימיים שמצביעים אליה.

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

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

למה מערכות CMS יוצרות כתובות שלא נראות טבעיות?

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

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

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

איך אנחנו רואים את השינוי?

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

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

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

איך בודקים אם URL מוזר הוא באמת בעיית SEO?

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

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

מה לעשות באתר וורדפרס כשכלי זחילה מציף כתובות חשודות?

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

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

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

איפה בעלי אתרים נופלים באודיט טכני?

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

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

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

צ’קליסט מהיר לפני שמתקנים

• בדקו אם הכתובת מופיעה בסייטמאפ. אם כן, שאלו למה.
• בדקו אם הכתובת מאונדקסת או מקבלת הופעות ב-Google Search Console.
• בדקו אם יש מאחורי הכתובת תוכן אמיתי או רק מזהה פנימי של המערכת.
• בדקו אם יש canonical תקין לגרסה המרכזית של העמוד.
• בדקו אם הקישור מגיע מתבנית מרכזית, מתוסף, מתוכן ידני או מסקריפט.
• בדקו אם חסימה ב-robots.txt באמת עוזרת, או רק מסתירה את הבעיה מכלי הזחילה.
• תעדפו תיקונים לפי השפעה עסקית, לא לפי מספר השורות בדוח.

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

מקור ועדכון

המאמר הזה מתבסס על דיווח של Search Engine Journal מ-29 ביולי 2026 על תשובה של ג’ון מולר מגוגל בנושא כתובות פנימיות שמערכות CMS מייצרות אוטומטית: Google On SEO Impact Of URLs Injected Into HTML By CMS Platforms.

שאלות נפוצות

האם כל URL מוזר באתר פוגע ב-SEO?

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

אם כתובת חסומה ב-robots.txt, גוגל עדיין יכולה לדעת שהיא קיימת?

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

מה ההבדל בין ממצא בכלי זחילה לבין בעיית SEO אמיתית?

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

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

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

מתי כן צריך לטפל בכתובות פנימיות מוזרות?

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

איך יודעים אם צריך noindex, canonical, robots.txt או הפניה?

זה תלוי במטרה. אם יש עמוד כפול עם גרסה מרכזית, canonical עשוי להתאים. אם עמוד לא צריך להופיע בגוגל אבל צריך להיסרק, noindex עדיף לעיתים. אם URL הוחלף, הפניה 301 נכונה יותר. robots.txt מתאים בעיקר לשליטה בסריקה, לא תמיד לפתרון אינדוקס.

סיכום

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