כשהחסימה לא נמצאת ב-robots.txt בכלל
שכבת הגנה או CDN יכולים לחסום את סורקי ה-AI לפני שהבקשה מגיעה לאתר, בלי שורה אחת ב-robots.txt. איך מאבחנים את זה בחמישה שלבים, ומה בדיוק מתקנים.
רוב החסימות שאנחנו מוצאים לא נכתבו בכוונה. מישהו הוסיף שורה נכונה במקום הלא נכון, או הניח שכללים מצטברים כשבפועל רק בלוק אחד נקרא. זה עמוד על התחביר עצמו, לא על מי לחסום.
עודכן:
הכלל היחיד שאם תזכרו רק אותו תמנעו את רוב התקלות: סורק קורא בלוק אחד בקובץ, לא את כולם. הוא מחפש את הבלוק שמכוון אליו בשמו, ואם מצא אותו הוא מתעלם לחלוטין מכל שאר הקובץ, כולל מהבלוק הכללי של User-agent: *. אין ירושה ואין הצטברות. ההנחה ההפוכה, שהכללים מתחברים זה לזה, היא המקור לחלק גדול מהחסימות שלא התכוונתם אליהן.
מי לחסום ומי לא, ומה ההבדל בין סורק אימון לסורק חיפוש, כתוב במדריך הטכני. כאן מדובר בדקדוק: איך הקובץ נקרא בפועל, ואיפה הוא נשבר בשקט.
הקובץ בנוי מקבוצות. כל קבוצה מתחילה בשורה או בכמה שורות User-agent, ואחריהן שורות ההרשאה שחלות עליהן.
הבחירה נעשית בשלושה שלבים. ראשית, הסורק מחפש התאמה לשמו. השם אינו רגיש לאותיות גדולות וקטנות, כך ש-googlebot ו-Googlebot זהים. שנית, אם יש כמה התאמות, נבחרת המדויקת ביותר: בלוק שכתוב בו OAI-SearchBot גובר על בלוק שכתוב בו *. שלישית, אם אין שום התאמה בשם, ורק אז, נקרא הבלוק הכללי.
מכאן נגזרות שתי מסקנות שקל לפספס.
בלוק בשם מבטל את הכללי לגמרי. אם כתבתם בלוק ל-Googlebot שאוסר תיקייה אחת, ובבלוק הכללי חסמתם עשר תיקיות, גוגלבוט תסרוק את כל התשע האחרות. זה לא באג, זו ההגדרה. מי שרוצה שכלל יחול גם על סורק ששמו מופיע בקובץ, חייב לחזור עליו בתוך הבלוק שלו.
שם חלקי לא תופס. מנגנון ההתאמה מסתכל על השם כפי שהסורק מציג את עצמו, ולא מבצע חיפוש חופשי בתוך מחרוזת. User-agent: GPT אינו חוסם את GPTBot, ו-User-agent: Claude לא בהכרח יתפוס את ClaudeBot ואת Claude-SearchBot יחד. אם רציתם לחסום שניים, כתבו שני שמות. שתי שורות User-agent רצופות לפני אותן שורות הרשאה מייצרות קבוצה אחת שחלה על שניהם, וזו הדרך התקינה לעשות את זה.
יש גם מקרה שלישי, פחות מוכר: אם אותו שם מופיע בשני מקומות נפרדים בקובץ, רוב הסורקים המשמעותיים מאחדים את שתי הקבוצות לאחת. כלומר לא בהכרח "האחרון גובר" אלא "שניהם חלים". קובץ שנערך על ידי כמה אנשים לאורך שנים מגיע למצב הזה מהר, והתוצאה כמעט אף פעם לא מה שהאחרון התכוון אליו. אם אתם מגלים שם כפול, אחדו ידנית ואל תסמכו על הפרשנות.
בתוך בלוק אחד, סדר השורות לא קובע. אפשר לכתוב את ה-Allow לפני או אחרי ה-Disallow והתוצאה זהה. מה שקובע הוא אורך הנתיב: הכלל שהנתיב שלו ארוך וספציפי יותר מנצח. אם שני נתיבים יוצאים באותו אורך בדיוק, ההכרעה נוטה לכיוון המתירני, כלומר ה-Allow.
זו הסיבה שאפשר לפתוח חלון קטן בתוך חסימה רחבה, וזה בדיוק המקום שבו כדאי להשתמש בזה. דוגמאות:
| מה יש בקובץ | הכתובת שנבדקת | מה קורה |
|---|---|---|
Disallow: /wp-content/ וגם Allow: /wp-content/uploads/ | /wp-content/uploads/x.jpg | מותר. הנתיב של ה-Allow ארוך יותר |
Disallow: /blog | /blog-2026/ | חסום. בלי לוכסן בסוף, זו התאמת תחילית ולא תיקייה |
Disallow: / וגם Allow: /about | /about-us/ | מותר, וכנראה לא לזה התכוונתם |
Disallow: /Search/ | /search/ | מותר. הנתיב רגיש לאותיות גדולות |
Disallow: (ריק) | כל כתובת | מותר הכול. שורה ריקה כזו היא היתר, לא איסור |
השורה הרביעית מפילה אתרים ישראליים לא מעט, כי הרבה מערכות מייצרות כתובות באות גדולה בהתחלה. הנתיב ב-robots.txt נבדק כפי שהוא, תו מול תו.
השורה האחרונה מבלבלת במיוחד: Disallow: בלי ערך פירושו "אל תחסום כלום", וזו הדרך המקורית לכתוב היתר גורף. Disallow: / עם לוכסן בודד פירושו "חסום את כל האתר". תו אחד מפריד בין השניים, ובקובץ צפוף קל מאוד להוסיף או להוריד אותו בטעות. אם אתם רוצים לוודא שהאתר שלכם לא במצב הזה, בודק ה-robots מציג את ההכרעה הסופית לכל סורק בנפרד.
שורה ריקה היא תו פיסוק. היא מסמנת סוף קבוצה, ומה שבא אחריה מתחיל קבוצה חדשה.
המשמעות המעשית: אם הפרדתם בין שורת User-agent לשורות ההרשאה שלה ברווח, כדי שיהיה מסודר, יצרתם קבוצה עם ראש בלי גוף ואחריה שורות יתומות. יש סורקים שמתאוששים מזה ויש שלא, והמצב לא מוגדר היטב. הכלל הבטוח פשוט: בתוך קבוצה אין שורות ריקות, ובין קבוצות יש בדיוק אחת.
הערות נכתבות עם #, ואפשר לשים אותן בתחילת שורה או בסופה. זה הכלי הכי מוזנח בקובץ הזה ואחד השימושיים בו. ליד כל חסימה שהיא החלטה ולא ברירת מחדל, כתבו תאריך וסיבה בשתי מילים. אנחנו רואים לא מעט אתרים שבהם החסימה נשארה שנים אחרי שהסיבה נעלמה, פשוט כי אף אחד לא ידע אם מותר לגעת. הרקע להחלטה עצמה, אם אתם עדיין מתלבטים בה, נמצא בעמוד ההחלטה לחסום או לא.
שתי שורות בקובץ אינן שייכות לשום קבוצה ולכן מיקומן לא משנה. Sitemap היא הצהרה גלובלית וכדאי לשים אותה בראש או בתחתית, לא באמצע בלוק, כדי שלא תיראה כאילו היא חלק ממנו. Crawl-delay אינה חלק מהתקן: גוגל מתעלמת ממנה, חלק מהסורקים האחרים מכבדים אותה. אם התקנתם אותה בתקווה להאט סורק AI, ההנחה שהיא עובדת אינה בטוחה.
שני תווים מיוחדים נתמכים בנתיבים על ידי הסורקים הגדולים, וגם הם מקור לתקלות.
פירושו רצף תווים כלשהו באורך כלשהו. Disallow: /? חוסם כל כתובת שיש בה סימן שאלה, כלומר כל כתובת עם פרמטרים. זה נשמע כמו ניקיון והוא מסוכן: אם חלק מהתוכן שלכם מוגש דרך פרמטרים, סינון בחנות או עמודי המשך, חסמתם אותו כולו. יש גם מקרה ספציפי לענייננו, פרמטר המקור שמצורף לקישור שמגיע מציטוט ב-ChatGPT. אם כלל גורף כזה נוגע בו, אתם עלולים לפגוע בדיוק במה שאתם מנסים למדוד לפי מדריך המדידה.
$ מסמן סוף כתובת. Disallow: /*.pdf$ חוסם קבצי PDF, אבל לא כתובת שיש אחריה פרמטר. מי שמסתמך עליו לחסימה הרמטית יגלה שהיא דולפת.
שני התווים האלה אינם חלק מהתקן המקורי משנת 1994. הם הרחבה שהתקבעה, ורוב הסורקים שנזכרים במדריך הטכני תומכים בהם, אבל סורק קטן או ישן עשוי לקרוא את הכוכבית כתו רגיל ולהחיל את הכלל על שום דבר. כלל קריטי עדיף לכתוב בלי תווים מיוחדים.
הקובץ הזה מנהל גישה, לא הצגה, וכמה מהציפיות ממנו פשוט לא קיימות.
הוא לא מוציא עמוד מהאינדקס. ההפך: עמוד חסום שיש אליו קישורים יכול להופיע בכל זאת, בלי תיאור, כי הסורק יודע שהוא קיים ולא יכול לקרוא אותו. הכלי להוצאה מהאינדקס הוא תגית noindex בעמוד עצמו, ויש כאן סתירה שקל ליפול בה: עמוד שחסום בקובץ הזה לא ייקרא, ולכן ה-noindex שבו לא ייראה לעולם. מי שרוצה להוציא עמוד באמת צריך להשאיר אותו פתוח לסריקה עם noindex, לא לחסום.
אין בו הוראת Noindex. היא נתמכה בעבר על ידי גוגל באופן לא רשמי ובוטלה. אם היא יושבת אצלכם בקובץ, היא כיום שורה חסרת משמעות.
הוא חל על מארח אחד בלבד. קובץ בכתובת הראשית לא חל על תת-דומיין, ובאופן פורמלי גם לא על גרסה בפרוטוקול אחר או בפורט אחר. אתר שהעביר את הבלוג לתת-דומיין ושכח להעתיק את הקובץ הוא מקרה נפוץ, ולרוב הוא מתגלה רק כשמשהו מפסיק להופיע. באתרים דו-לשוניים זה מצטלב עם מה שכתוב במדריך הרב-לשוני, כשגרסה אחת יושבת על תת-דומיין נפרד.
יש לו גבול גודל. גוגל קוראת עד חצי מגה-בייט ומתעלמת ממה שמעבר. לקובץ שנכתב ביד זה לא רלוונטי, אבל קובץ שנבנה אוטומטית ומייצר שורה לכל כתובת יכול להגיע לשם, ואז החלק החשוב ייחתך בשקט.
זה החלק שכמעט אף אחד לא בודק, והוא משנה התנהגות דרסטית.
קובץ שמחזיר 404 נחשב כאילו אין חסימות בכלל, והכול פתוח. זה בדרך כלל מצב תקין ולא בעיה.
קובץ שמחזיר שגיאת שרת הוא הסיפור המסוכן. סורקים מתייחסים לשגיאת 5xx כאילו כל האתר חסום, מתוך זהירות, עד שהמצב מתייצב. שרת שקורס מדי פעם, או קובץ שנחסם בטעות על ידי שכבת הגנה, מייצר חסימה מלאה שנעלמת ומופיעה מעצמה. אם ירידה בנראות מתאימה בזמן לתקלת שרת ולא לשינוי תוכן, זה הכיוון לבדוק, וזה גם אחד ההסברים לירידת תנועה בלי סיבה נראית לעין.
קובץ שמחזיר 200 עם עמוד שגיאה מעוצב הוא הגרוע מכולם, כי הוא נראה תקין. מערכות מסוימות מגישות עמוד HTML לכל כתובת שלא נמצאה, כולל לכתובת הקובץ. הסורק מקבל תגית HTML במקום הוראות, לא מוצא שורות חוקיות, ומתנהג לפי מה שהוא הצליח לפרש. ההוראות שלכם, אם היו שם, נעלמו.
הפניה מהקובץ לכתובת אחרת נסבלת בדרך כלל בקפיצה או שתיים, ומעבר לזה ההתנהגות אינה אחידה. קובץ שמופנה דרך שרשרת הפניות של אתר שעבר לדומיין חדש הוא מקום טוב לבדוק.
| מה כתוב | למה זה שגוי |
|---|---|
User-agent: OAI-SearchBot, PerplexityBot | אין רשימה מופרדת בפסיקים. צריך שתי שורות נפרדות |
Disallow: example.co.il/private/ | הנתיב מתחיל בלוכסן ולא בדומיין. השורה כנראה תתעלם |
Dissallow: / | שגיאת כתיב היא שורה לא מוכרת, כלומר אין חסימה בכלל |
Allow: / לבד, בלי חסימה כלשהי | לא מזיק אך גם לא מוסיף. היעדר חסימה כבר מתיר |
שורת User-agent אחרי שורות ההרשאה | הראש חייב לבוא לפני הגוף, אחרת הכללים יתומים |
| הקובץ בתיקייה פנימית ולא בשורש | נקרא רק מהשורש המדויק של המארח, ולא מתיקייה |
הבדיקה עצמה בשלושה שלבים. קודם, קראו את הקובץ הקיים מהדפדפן ולא מהעורך שבמערכת, כי לפעמים מוגש משהו אחר ממה שכתבתם. אחר כך, בדקו כתובת אמיתית מכל סוג תוכן שחשוב לכם, לא רק את עמוד הבית: עמוד מוצר, עמוד מאמר, עמוד קטגוריה עם פרמטרים. גוגל מציעה בדיקה של הקובץ בכליה, ולסורקי AI אין כלי מקביל, ולכן האימות היחיד הוא לוגים אחרי כמה ימים. לבסוף, תעדו את תאריך השינוי, כי בלעדיו לא תוכלו לקשור בין השינוי לבין מה שקרה אחריו.
כשהקובץ מנוהל בידי מפתח או ספק אחסון, החלוקה נשמרת: הגדרת השינוי המדויק מול מי שמבצע אותו באתר, כדי שלא ייווצר סבב ניחושים בין שני צדדים שכל אחד מהם מחכה לשני.
אם הכול תקין ואתם עדיין לא מופיעים, הסיבה כנראה אינה כאן, ושווה לעבור על הטעויות החוזרות, על מה שקורה כשאתר לא מופיע ב-ChatGPT ועל רשימת הבדיקה. הצד התוכני, שהוא בדרך כלל הגורם השני בתדירות, נמצא במדריך הכתיבה.
התקן מגדיר את הפרשנות של הקובץ, אבל כל סורק מממש אותו בעצמו ואף חברה לא מפרסמת את קוד הפירוש שלה. ההתנהגות במקרי קצה, למשל שורות פגומות, קידוד לא סטנדרטי או קבוצות סותרות, אינה מתועדת אצל רוב סורקי ה-AI, ואין דרך לבדוק אותה מבחוץ חוץ מלוגים.
גם השאלה מה קורה כשסורק מכבד את הקובץ אבל התוכן שלכם כבר קיים במקור אחר נשארת פתוחה: חסימה מונעת קריאה ישירה, לא הכרה בעובדות שכבר נאספו. עדכונים בהתנהגות הסורקים נרשמים בארכיון העדכונים, המונחים מוסברים במילון והשאלות הנפוצות מרוכזות בעמוד השאלות והתשובות.
שכבת הגנה או CDN יכולים לחסום את סורקי ה-AI לפני שהבקשה מגיעה לאתר, בלי שורה אחת ב-robots.txt. איך מאבחנים את זה בחמישה שלבים, ומה בדיוק מתקנים.
יש סורקים שלא מריצים קוד ורואים שלד ריק במקום הטקסט שלכם. איך בודקים את זה בפחות מדקה, למה זה נפוץ דווקא באתרים חדשים, ומה בדיוק הפתרון בצד השרת.
Organization, LocalBusiness, FAQPage, Article ו-Product: מה כל סוג עושה בפועל, באיזה סדר להטמיע אותם, ולמה סימון שגוי מזיק יותר מהיעדר סימון.
סורקי חיפוש רצים בתדירות גבוהה ומוותרים מהר. מה קורה כשהאתר מחזיר שגיאות או תגובות איטיות, איך מזהים את זה בלוגים ומה לתקן קודם כדי לא לצאת מהתשובות.
שינוי מבנה כתובות בלי הפניות מוחק את היסטוריית האזכורים במנועי AI. מה בדיוק נשבר, למה אין על זה שום התראה, ואיך עושים מעבר בלי לאבד ציטוטים ותנועה.
שני עמודים על אותו נושא מפצלים את הסיגנל ומחלישים את שניהם. איך מזהים כפילות באתר, לפי מה בוחרים את העמוד ששורד, ולמה הפניה עדיפה על מחיקה כמעט תמיד.
בלי מצגת, בלי התחייבות ובלי שיחת מכירה. עשרים דקות שבסופן תדעו אם יש כאן משהו בשבילכם.
לא בקטע של טפסים? info@boostit.co.il