קובץ Robots.txt: השליטה בגישת הבוטים היא הצעד הראשון לפני הכול

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

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

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

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

השלב הראשון בבדיקת זחילה, לא שכבת אבטחה

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

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

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

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

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

זחילה, אינדוקס והגנה: אלה שלוש החלטות שונות

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

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

כשרוצים למנוע זחילה

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

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

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

כשרוצים למנוע הופעה בתוצאות

האם robots.txt לבדו מספיק? לא.

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

כאשר רוצים למנוע אינדוקס, הכלים המתאימים הם בדרך כלל הוראת noindex, כותרת X-Robots-Tag, קוד מצב 404 או 410 למשאב שהוסר, או הגנה שמונעת גישה. הבחירה תלויה במצב: האם העמוד צריך להישאר פתוח למשתמשים, האם הוא כבר מאונדקס, והאם התוכן הוסר לצמיתות.

כשרוצים להגן על תוכן

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

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

המיקום של הקובץ קובע במה הוא בכלל שולט

הקובץ צריך להיקרא robots.txt, באותיות קטנות, ולהימצא בשורש של ה־origin הרלוונטי. זהו קובץ טקסט פשוט. אי אפשר להניח אותו בתיקייה פנימית ולצפות שהכללים יחולו על האתר כולו.

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

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

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

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

ומה קורה אם הקובץ חסר והשרת מחזיר קוד 404? מבחינת Google, אין זו בהכרח תקלה. המשמעות הרגילה היא שאין מגבלות זחילה. גם קובץ ריק יכול להיות תקין, ו־Disallow: בלי נתיב אינו חוסם דבר.

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

כך נראה קובץ פשוט שעושה את העבודה

Google תומכת בארבעה שדות מרכזיים בקובץ: User-agent, Disallow, Allow ו־Sitemap. המבנה מחלק את הכללים לקבוצות לפי סוג הבוט שאליו הם מיועדים.

User-agent: *
Disallow: /internal-search/
Allow: /internal-search/help/

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

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

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

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

שמות השדות והערכים בשדה User-agent אינם תלויים ברישיות מבחינת Google. נתיבי URL, לעומת זאת, עשויים להיות תלויי רישיות. /File/ ו־/file/ יכולים להיות שני נתיבים שונים, בהתאם לשרת.

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

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

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

קבוצות User-agent: כלל קטן שיכול לשנות מדיניות שלמה

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

נניח שחסמתם את החיפוש הפנימי עבור כל הבוטים, ואז הוספתם קבוצה מיוחדת ל־Googlebot ובה כתבתם רק Allow: /:

User-agent: *
Disallow: /internal-search/

User-agent: Googlebot
Allow: /

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

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

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

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

Disallow ו־noindex יחד: יותר הוראות, פחות שליטה

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

בפועל, הן עלולות להפריע זו לזו.

כדי שזחלן יקרא noindex שמופיע בקוד העמוד או בכותרת X-Robots-Tag, הוא חייב להיות רשאי לבקש את הכתובת. אם Disallow עוצר אותו לפני הבקשה, הוא לא יכול לראות את ההוראה שאמורה למנוע את האינדוקס.

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

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

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

מתי צמצום זחילה באמת משרת את העסק

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

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

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

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

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

חסימה היא אמצעי תפעולי. היא לא הישג SEO בפני עצמו.

בוטים של AI מוסיפים עוד החלטה למדיניות הזחילה

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

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

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

ומה בוודאי לא כדאי לעשות? לחסום User-agent: * רק כדי לעצור בוט AI מסוים. חסימה כזאת עלולה לסגור גם זחלני חיפוש שמביאים לאתר לקוחות.

טעויות בהגדרת קובץ Robots.txt שלא כדאי לאשר

• השארת Disallow: / אחרי העלייה לאוויר: חסימה שנועדה לסביבת פיתוח נשארת באתר הפעיל, וכל הזחלנים התואמים מתבקשים להתרחק ממנו. סביבת הפיתוח עצמה צריכה להיות מוגנת ולא להסתמך רק על הקובץ.
• ניסיון להסיר עמוד מאונדקס באמצעות Disallow: החסימה עלולה למנוע מהזחלן לקרוא noindex, קנוניקל או קוד מצב חדש.
• שימוש בקובץ כהגנה על מידע: הוראת זחילה אינה בקרת גישה, ולכן מידע רגיש דורש הגנה ברמת השרת.
• עריכת הקובץ במארח הלא נכון: שינוי בדומיין הראשי לא משנה בהכרח את הקובץ בתת־דומיין, בפרוטוקול אחר או בפורט נפרד.
• יצירת קבוצה ייעודית לבוט בלי לחזור על הכללים הדרושים: הקבוצה הספציפית לא יורשת אוטומטית את קבוצת הכוכבית.
• חסימת תיקייה רק משום ששמה נשמע טכני: היא עשויה להכיל קובצי עיצוב, סקריפטים, תמונות או רכיבים שנחוצים לרינדור ולהפעלת האתר.
• התעלמות מאותיות גדולות וקטנות: הכלל נראה נכון, אך אינו מתאים לנתיב שהשרת מגיש בפועל.
• הסתמכות על Crawl-delay עבור Google: ההוראה אינה נתמכת ולכן לא תפתור עומס זחילה.
• כתיבת אלפי כללים פרטניים: הקובץ נעשה קשה לתחזוקה, מועד לסתירות ועלול לחרוג ממגבלת העיבוד. עדיף לטפל בתבנית שיוצרת את הכתובות.
• חסימת עמודים רק מפני שהם כפולים: חסימה אינה הפניה ואינה בחירה קנונית. לפעמים היא רק מונעת מהזחלן לראות את האותות הדרושים לו כדי להבין את הכפילות.

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

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

שאלות שחשוב לשאול לפני שמשנים את הקובץ

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

1. מה המטרה המדויקת? האם רוצים להפחית עומס, למנוע זחילה, להסיר עמוד מתוצאות, להגן על מידע או להגביל בוט מסוים? אם המטרה אינה שליטה בזחילה, כנראה דרוש כלי אחר.
2. אילו תבניות של כתובות יושפעו? צריך להכין רשימה של כתובות שאמורות להיחסם לצד כתובות דומות שחייבות להישאר פתוחות. כלל שאין לו מקרי בדיקה הוא הימור.
3. האם הכתובות כבר מאונדקסות? אם כן, חסימה מיידית עלולה להפריע לקריאת noindex, קנוניקל או קוד ההסרה.
4. האם יש להן ערך עסקי או אורגני? אפשרות סינון שנראית טכנית למפתח יכולה להיות דף נחיתה שמשרת צורך אמיתי ומביא קהל ממוקד.
5. האם העמודים תלויים במשאבים שנחסמים יחד איתם? צריך לבדוק קובצי CSS, JavaScript, תמונות וקריאות נוספות שהרינדור דורש.
6. על אילו מארחים וסביבות השינוי צריך לחול? דומיין ראשי, תת־דומיינים, גרסאות שפה ומערכות חיצוניות לא בהכרח משתמשים באותו קובץ.
7. איזה בוט אמור לקבל את הכלל? חסימה כללית ומדיניות ייעודית הן שתי החלטות שונות. קבוצה מיותרת עלולה לשנות את התאמת הכללים הקיימים.
8. מי מאשר, מי מעלה לאוויר ומי אחראי להחזיר את המצב לקדמותו במקרה הצורך? קובץ קטן ראוי לבקרת גרסאות, לתיעוד ולגיבוי בדיוק כמו שינוי קוד.

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

כך בודקים שינוי לפני הפריסה ואחריה

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

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

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

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

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

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

הטיפ האישי שלי: החסימה שהסתירה את ה־noindex

במבט חוזר: קובץ קטן, החלטה מערכתית

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

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

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

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