טעות אחת ב־robots.txt יכולה לחסום 100% מהאתר לסריקה. אני מסתכל על הקובץ הזה כמו על מתג קטן עם השפעה גדולה: הוא לא שולט על אינדוקס, לא מסתיר מידע רגיש, אבל כן קובע אילו אזורים מנועי חיפוש ינסו לסרוק.
אם אני צריך לצמצם את כל המאמר לכמה שורות, זה הסיפור:
- אני שם את
robots.txtרק בשורש הדומיין - אני כותב אותו כ־
plain textב־UTF-8, עם תחביר מדויק - אני פותח כל קבוצה עם
User-agent - אני מגדיר
Allowו־Disallowבלי לוכסנים או נתיבים שגויים - אני מוסיף
Sitemapעם URL מלא - אני לא חוסם בטעות
CSS,JavaScriptאו קבצי מדיה - אני בודק את הקובץ לפני פרסום וחוזר אליו כל רבעון
הנקודה הכי חשובה מבחינתי היא זו: robots.txt שולט על סריקה, לא בהכרח על הופעה בתוצאות החיפוש. לכן, אם המטרה שלי היא למנוע אינדוקס, אני לא נשען על הקובץ הזה לבד.
גם במספרים זה פשוט:
קובץ אחד, 10 כללים, ו־0 מקום לטעויות כמו Disallow: /.
| נושא | מה אני בודק |
|---|---|
| מיקום | https://domain.co.il/robots.txt |
| פורמט | טקסט רגיל, UTF-8 |
| מבנה | כל קבוצה מתחילה ב־User-agent |
| חסימות | אין חסימה רחבה מדי |
| רינדור | CSS ו־JS פתוחים לסריקה |
| Sitemap | כתובת מלאה שמחזירה 200 OK |
| בדיקה | GSC + בדיקה ידנית בדפדפן |
אם אני רוצה קובץ נקי שעושה את העבודה, אני שומר על דיוק, פשטות, ובדיקה לפני כל שינוי.
10 כללים לכתיבת Robots.txt נכון – טבלת עזר מהירה
מה קובץ robots.txt תקין אמור לעשות
קובץ robots.txt תקין נותן לסורקים כיוון ברור, עוזר לשמור על תקציב הסריקה, וגם מאפשר לציין Sitemap. כשהמטרות האלה ברורות מההתחלה, הרבה יותר קל לכתוב כללים מדויקים בלי לחסום בטעות אזורים חשובים באתר. כאן בדיוק נכנס הנושא של ניהול תקציב הסריקה.
אם סורק מבזבז זמן על דפי פילטרים, חיפוש פנימי או תהליך תשלום, נשאר לו פחות זמן לדפי מוצר ולתוכן המרכזי. זה הופך לחשוב במיוחד באתרים עם 5,000 כתובות URL ומעלה. ובאותה נשימה, חשוב להבין גם מה robots.txt לא עושה.
חשוב לזכור: הקובץ הוא הנחיה, לא מנגנון אבטחה. מנועי חיפוש גדולים מכבדים אותו, אבל בוטים אחרים יכולים פשוט להתעלם ממנו לגמרי. זאת נקודה שקל לפספס, והיא פוגעת לא מעט באתרים שחוסמים בלי לשים לב משאבים שקשורים לעיצוב ולקוד.
מנועי חיפוש טוענים את הדף כדי להבין איך הוא בנוי. כשיש חסימה ל־CSS ול־JavaScript, הם עלולים לראות רק חלק מהתמונה ולפרש את הדף בצורה חלקית, מה שעלול לפגוע במאמצי קידום אתרים. בגלל זה, בדיקה של חסימות לפני פרסום היא צעד בסיסי בכתיבה נכונה של robots.txt.
sbb-itb-1ec8384
1. מקמו את robots.txt בשורש הדומיין
אחרי שמבינים מה robots.txt עושה, מתחילים מהדבר הכי בסיסי: המיקום שלו.
הקובץ robots.txt חייב לשבת בשורש הדומיין, למשל: https://yourdomain.co.il/robots.txt. אם שמים אותו בתוך תיקייה פנימית, הסורקים לא ילכו לחפש אותו שם. הם מבקשים את הקובץ מהנתיב הזה בלבד, ולכן קובץ שלא נמצא בשורש מתנהג בפועל כאילו הוא לא קיים.
יש כאן עוד נקודה שקל לפספס: לכל תת־דומיין צריך קובץ robots.txt משלו. גם HTTP ו־HTTPS נבדקים בנפרד, כך שלא מספיק להניח שקובץ אחד מכסה את הכול.
כדאי לבדוק את https://yourdomain.co.il/robots.txt ישירות בדפדפן. אם אתם מקבלים 200 OK, זה סימן שהקובץ נגיש. אם מתקבלת 404, הסורק לא יוכל לקרוא אותו.
אחרי המיקום, מגיע הכלל הבא: שם הקובץ והפורמט שלו.
2. השתמשו בשם קובץ מדויק באותיות קטנות ובפורמט טקסט רגיל
ב־robots.txt, גם טעות קטנה בשם הקובץ או בתחביר עלולה להפוך אותו לחסר ערך. לכן, אחרי שבודקים שהקובץ יושב בשורש האתר, חשוב לוודא שהשם שלו הוא בדיוק robots.txt – באותיות קטנות בלבד.
אחר כך מגיע החלק השני: התחביר. אם הוא לא כתוב נכון, הסורקים פשוט לא יפרשו את הקובץ כמו שהתכוונתם.
תחביר הדירקטיבות
שמרו את הקובץ כקובץ טקסט רגיל ב־UTF-8, בלי Word, HTML, RTF או BOM. את ההוראות עצמן צריך לכתוב בדיוק כך: User-agent, Allow, Disallow, עם נקודתיים.
זה אולי נשמע כמו פרט קטן, אבל כאן אין מקום ל"בערך". אם הפורמט לא תקין, הקובץ עלול לא להיקרא כמו שצריך.
ספציפיות הנתיבים
גם הנתיבים עצמם רגישים לרישיות. למשל, /admin/ אינו זהה ל־/Admin/.
בפועל, זה אומר שאם כתבתם נתיב עם אות גדולה במקום קטנה, ייתכן שהכלל פשוט לא יחול. קל לפספס את זה, במיוחד כשעובדים מהר.
השלכות של קובץ שגוי
אם הקובץ לא נקרא נכון, הסורק יתייחס אליו כאילו הוא לא קיים. במצב כזה, הוא עלול לבזבז סריקה על מסלולים מיותרים או רגישים כמו /wp-admin/ או תוצאות חיפוש פנימיות.
אחרי שהקובץ קריא, שמור נכון, והשם שלו מדויק, אפשר לעבור לשלב הבא: הסדר הנכון של קבוצות הכללים.
3. פתחו כל קבוצת כללים עם User-agent
אחרי שהקובץ יושב במקום הנכון ויש לו שם תקין, מגיע החלק הבא: למי ההוראות מיועדות בכלל. כאן נכנס User-agent. כל קבוצת כללים ב־robots.txt צריכה להתחיל בשורה הזו, כדי לציין איזה סורק אמור לקרוא את ההנחיות.
סדר השורות
אם שמים Allow או Disallow לפני שורת User-agent הראשונה, הסורקים יתעלמו מהשורות האלה. אותו דבר קורה לא פעם עם טעות קטנה בשם הסורק. למשל, Goglebot במקום Googlebot נשמע כמעט זהה לעין, אבל בפועל הקבוצה עלולה לא להיקרא בכלל.
בקיצור, הסדר פה לא קוסמטי. הוא קובע אם ההוראות יעבדו או ייפלו בין הכיסאות.
פנייה לכל הסורקים או לסורק מסוים
User-agent: * מיועד לכל הסורקים. אם רוצים לפנות לסורק מסוים, צריך לכתוב את שמו בדיוק כפי שהוא מוכר, למשל User-agent: Googlebot או User-agent: GPTBot.
כשיש גם קבוצה כללית וגם קבוצה שמיועדת לסורק מסוים, הקבוצה הייעודית היא זו שתקבל עדיפות. זה אומר שאפשר לתת הוראות כלליות לכולם, ואז לחדד או לשנות אותן עבור סורק מסוים.
אחרי שמגדירים את הסורק, כותבים את הכללים עצמם. בלי ניסוחים מעורפלים ובלי קפיצות מבלבלות.
חסימה מלאה של הסריקה
Disallow: / תחת User-agent: * חוסם את כל האתר מכל הסורקים. זו שורה קצרה, אבל עם השפעה גדולה מאוד. טעות כאן עלולה לסגור את כל האתר לסריקה.
כדאי גם להפריד בין קבוצות עם שורה ריקה אחת. בלי ההפרדה הזו, סורק עלול לקרוא שתי קבוצות כאילו הן קבוצה אחת.
| שגיאה | תוצאה |
|---|---|
כללים לפני שורת User-agent |
הדירקטיבות יידחו |
| שגיאת כתיב בשם הסורק | הסורק המיועד עלול להתעלם מהקבוצה |
Disallow: / תחת User-agent: * |
חסימה מלאה של האתר מכל הסורקים |
| אין שורה ריקה בין קבוצות | הסורק עלול לפרש שתי קבוצות כאחת |
אחר כך עוברים לניסוח המדויק של Allow ו־Disallow.
4. כתבו דירקטיבות Allow ו־Disallow במדויק
אחרי שמגדירים את User-agent, מגיע החלק שבו צריך להיות חדים: Allow ו־Disallow.
Disallow אומר לסורק לא לגשת לנתיב מסוים. Allow נכנס לתמונה בעיקר כשצריך לפתוח חריג מדויק בתוך תיקייה שכבר חסומה.
דיוק בתחביר הדירקטיבה
התחביר התקין הוא תמיד: Directive: [path].
כלומר, Disallow: ו־Allow: צריכים להופיע בדיוק כך.
החלת הכלל על הסורק
Allow ו־Disallow עובדים רק בתוך קבוצת כללים שמתחילה ב־User-agent. אם הכתיבה של הנתיב לא מדויקת, הכלל עלול פשוט לא לחול. דוגמה נפוצה ב־WordPress:
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php כאן רואים יפה איך זה עובד: התיקייה /wp-admin/ חסומה, אבל הקובץ admin-ajax.php נשאר פתוח.
כשיש חפיפה בין כללים, הכלל הספציפי יותר גובר. אם שני כללים באותו אורך, Allow גובר.
ספציפיות הנתיב
כל נתיב חייב להתחיל ב־/. לכן Disallow: /private/ הוא הניסוח הנכון, לא גרסה בלי לוכסן בתחילת הנתיב.
ההבדלים הקטנים האלה משנים הרבה בפועל:
| דירקטיבה | מה היא עושה | טעות שכיחה |
|---|---|---|
Disallow: /temp/ |
חוסמת תיקייה שלמה | חסימה רחבה מדי |
Allow: /wp-admin/admin-ajax.php |
פותחת קובץ ספציפי בתוך תיקייה חסומה | שכחת שורת Allow |
Disallow: /*.pdf |
חוסמת קובצי PDF | חסימת נתיבים לא מתוכננים |
אם יש כאן לקח אחד פשוט, הוא זה: ב־robots.txt, כל תו קובע. לוכסן חסר, נתיב לא מדויק, או חריג שלא הוגדר – ופתאום הסורק מקבל הוראה אחרת ממה שהתכוונתם אליה.
5. שמרו על נתיבים מדויקים ועקביים בפורמט
כבר ראינו שב־robots.txt כל תו משנה. וזה לא נעצר בדירקטיבה עצמה. גם הפורמט של הנתיב גורם לא מעט תקלות שקטות: הקובץ נראה תקין, אין שגיאת תחביר, אבל הכלל פשוט לא פועל כמו שציפיתם.
דיוק בתחביר הדירקטיבה
נתיבי URL בתוך robots.txt הם תלויי רישיות. במילים פשוטות, Disallow: /Admin/ לא חוסם את /admin/ – מבחינת הסורק, אלה שני נתיבים שונים.
הדרך הכי פשוטה לצמצם טעויות? להשתמש באותיות קטנות בכל כתובות ה־URL באתר, ולכתוב את הדירקטיבות באותו פורמט.
בהירות מיקוד הסורק
גם לוכסן בסוף הנתיב יכול לשנות לא מעט. Disallow: /admin/ חוסם את התיקייה ואת כל מה שנמצא בתוכה. אבל Disallow: /admin בלי לוכסן סוגר מרחיב את החסימה גם לכתובות שמתחילות באותה מחרוזת, כמו /admin-panel, /administration ו־/admin.html.
| דירקטיבה | מה נחסם בפועל |
|---|---|
Disallow: /admin |
כל נתיב שמתחיל ב־/admin, כולל /admin-panel ו־/administration |
Disallow: /admin/ |
התיקייה /admin/ וכל מה שבתוכה בלבד |
Disallow: /Admin/ |
חוסמת /Admin/ אבל מאפשרת גישה ל־/admin/ |
זה נשמע כמו פרט קטן, אבל כאן בדיוק נופלים. לוכסן אחד מיותר או חסר, והכלל פוגע גם בדפים שלא התכוונתם לחסום.
ספציפיות הנתיב
אם המטרה היא לקבע את הכלל לסוף ה־URL, השתמשו ב־Disallow: /*.pdf. כך תחסמו רק קבצים שמסתיימים ב־.pdf, ולא כל כתובת שמכילה את המחרוזת pdf איפשהו באמצע.
6. הוסיפו את דירקטיבת Sitemap עם ה־URL המלא
אחרי שמגדירים חסימות והיתרים, כדאי להוסיף גם את מפת האתר כדי לכוון את הסורקים לדפים שחשוב לכם שיגיעו אליהם. Sitemap עובד לצד Disallow ו־Allow: במקום להגיד מה לא לסרוק, הוא מראה איפה נמצאים הדפים שכדאי לגלות.
הטעות הכי נפוצה כאן פשוטה מאוד: שימוש בנתיב יחסי במקום בכתובת מלאה. הפורמט הנכון נראה כך:
Sitemap: https://www.example.com/sitemap.xml זה אולי נראה כמו פרט קטן, אבל הוא עושה את כל ההבדל. אם תכתבו /sitemap.xml במקום URL מלא, הסורק עלול לא לזהות את הקובץ בכלל.
עוד נקודה שחשוב לדעת: Sitemap חל על כל הסורקים. ואם יש לכם יותר ממפת אתר אחת, אפשר להוסיף כמה שורות:
Sitemap: https://www.example.com/sitemap.xml Sitemap: https://www.example.com/sitemap-images.xml וגם אם התחביר תקין, זה עדיין לא מספיק. הכתובת עצמה חייבת להיות נגישה. בדקו שה־URL מחזיר 200 OK; כתובת שמחזירה 404 פוגעת בסריקה.
| טעות נפוצה | ההשפעה |
|---|---|
נתיב יחסי (/sitemap.xml) |
הסורק לא מזהה את הקובץ |
כתובת שמחזירה 404 |
הסורק לא מצליח לקרוא את המפה |
7. שמרו על כללים פשוטים והימנעו מסתירות
אחרי שהגדרתם נתיבים מדויקים, עצרו רגע ובדקו שאין חפיפות או סתירות בין הכללים. זה שלב קטן, אבל הוא יכול לחסוך לא מעט כאב ראש.
דיוק תחביר הדירקטיבות
שורה אחת לא נכונה, כמו Disallow: /, יכולה לחסום את כל האתר. וזה לא משהו שתמיד נפתר בן רגע – ההשפעה של תיקון כזה עשויה להימשך בין 7 ל־21 יום. לכן כדאי לשמור על קובץ נקי, ברור, ובלי "טריקים" מיותרים.
הוסיפו הערות # רק כשיש צורך לתעד חריגים או חסימות זמניות. אם כל הקובץ מלא בהסברים, קל לפספס את מה שחשוב.
אחרי שווידאתם שהתחביר תקין, עברו לשאלה הבאה: מי בכלל מקבל את הכלל הזה בפועל?
בהירות בזיהוי הסורק
אם יש בלוק ייעודי ל־User-agent: Googlebot, ובנוסף בלוק כללי ל־User-agent: *, הקבוצה הספציפית גוברת על הכללית. במילים פשוטות: Googlebot יקבל את ההוראות שנכתבו בשבילו, לא את אלה של כולם.
כדי לשמור על סדר, הפרידו בין קבוצות User-agent עם שורה ריקה. זה נשמע שולי, אבל כשחוזרים לקובץ אחרי חודש, סדר כזה עושה הבדל.
כשכמה כללים נוגעים לאותו אזור באתר, מה שקובע הוא לא רק סוג הכלל – אלא גם רמת הדיוק של הנתיב.
ספציפיות הנתיב
במקרה של סתירה בין Allow ל־Disallow, הכלל הארוך יותר גובר. כלומר, המערכת בוחרת את הנתיב היותר מדויק.
השתמשו ב־* רק כשאין דרך פשוטה יותר לכסות כמה כתובות יחד. אחרת, קל מאוד לכתוב כלל רחב מדי ואז לגלות שהוא תפס גם דפים שלא התכוונתם לחסום.
אינדוקס מול סריקה
כאן חשוב לא להתבלבל: robots.txt שולט על סריקה, לא בהכרח על אינדוקס. אם המטרה היא להסתיר דף מתוצאות החיפוש, השתמשו ב־noindex או ב־X-Robots-Tag – לא ב־robots.txt בלבד.
8. אל תחסמו קבצי CSS, JavaScript או מדיה בטעות
אחרי שסידרתם את הנתיבים, שווה לבדוק גם מה לא לחסום.
דיוק תחביר הדירקטיבות
מנועי חיפוש מרנדרים את הדף כדי להבין איך הוא בנוי ואיך הוא נראה. אם אתם חוסמים את /wp-includes/ או /assets/, אתם עלולים להסתיר קבצי CSS, JavaScript ומדיה. במצב כזה, הסורק עלול לראות דף חלקי או דף שלא נטען כמו שצריך.
במקרים כאלה, הפתרון הוא להשתמש ב־Allow כדי להגדיר חריגים בתוך תיקיות חסומות:
Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php זה חשוב במיוחד כשהקבצים האלה משרתים גם את העמודים הציבוריים באתר.
כללים נפרדים למדיה
באתרי מדיה, בדקו גם אם יש כללים נפרדים עבור Googlebot-Image ו־Googlebot-Video.
ספציפיות הנתיב
| הטעות | ההשפעה | התיקון המומלץ |
|---|---|---|
Disallow: /wp-includes/ |
חוסם קבצי CSS/JS נחוצים ועלול לפגוע ברינדור | הסירו את החסימה או הוסיפו Allow לקבצי CSS/JS שנדרשים |
Disallow: /assets/ |
מונע טעינת תמונות, פונטים ועיצוב | חסמו רק תת-תיקיות פרטיות שאין בהן משאבי רינדור |
9. בדקו את הקובץ לפני הפרסום
אחרי שמנעתם חסימות מיותרות, נשאר צעד אחרון: לוודא שהקובץ עובד כמו שתכננתם.
לפני ההעלאה לשרת, עברו על הקובץ ובדקו שהוא חוסם ומתיר בדיוק את מה שרציתם. טעות קטנה כאן יכולה לסגור גישה לדפים, לקבצי CSS, או ל־JavaScript בלי שהתכוונתם.
דיוק תחביר הדירקטיבות
מקום טוב להתחיל בו הוא Robots.txt Tester ב־Google Search Console. הכלי הזה נותן לכם להדביק את הקובץ, לבדוק כתובות URL מסוימות, ולראות אם הן נחסמות.
שימו לב לשמות ההוראות. כתבו אותם בדיוק כמו שצריך, עם אותיות וכתיב תקינים. ב־robots.txt, גם פרט קטן יכול לשנות את התוצאה.
בהירות פנייה לסורקים
בדקו שכל בלוק מתחיל ב־User-agent תקין, ושאין קבוצות שהתאחדו בטעות.
זה נשמע שולי, אבל בפועל זו אחת התקלות שקל לפספס. אם המבנה לא ברור, סורקים עלולים לפרש את הקובץ אחרת ממה שהתכוונתם.
ספציפיות הנתיב
בדקו לכל כלל שני מקרים פשוטים:
- נתיב אחד שאמור להיות חסום
- נתיב אחד שאמור להישאר פתוח
כך קל לזהות חסימות רחבות מדי. אם כלל אחד סוגר יותר ממה שחשבתם, עדיף לגלות את זה עכשיו ולא אחרי שהאתר כבר חי.
בטיחות סריקה ואינדוקס
פתחו בדפדפן את domain.co.il/robots.txt וודאו שהקובץ נטען כ־plain text ומחזיר 200. אחר כך בדקו ב־URL Inspection שדפים חשובים לא חסומים, ושקובצי CSS ו־JavaScript זמינים לרינדור תקין.
שלושת הכלים הבאים עוזרים לכם לכסות את שלושת הכיוונים: תחביר, חסימות, ובדיקה ברמת האתר.
| כלי | שימוש עיקרי |
|---|---|
| GSC Robots.txt Tester | בדיקת תחביר וכתובות URL |
| GSC URL Inspection | בדיקה אם דף חסום וצפייה ב־HTML מרונדר |
| Screaming Frog | סריקה רחבה לאיתור חסימות בטעות |
10. סקרו ועדכנו את robots.txt באופן קבוע
אחרי שבדקתם את הקובץ, זה לא נגמר שם. כדאי לחזור אליו אחת לרבעון, וגם אחרי כל שינוי במבנה האתר, בשרת או בכתובות.
תיעוד כללים זמניים
בסקירה התקופתית, התחילו דווקא מהכללים הזמניים. אלה הכללים שהכי קל לשכוח מהם. ליד כל כלל זמני, הוסיפו תאריך וסיבה. למשל: # חסימה זמנית לקמפיין – מרץ 2026.
בהירות בפנייה לסורקים
בכל סקירה, עברו גם על בלוקים שמיועדים לבוטים מסוימים. למשל GPTBot ו־Google-extended. כך קל יותר לראות מי מקבל איזו הנחיה, ולמנוע בלבול בהמשך.
ספציפיות הנתיב
באתרים עם דפי סינון, עדיף לחסום רק פרמטר מיותר אחד ולא את כל השאילתות. למשל: Disallow: /*?sort=. זה נשמע קטן, אבל זה ההבדל בין חסימה מדויקת לבין חסימה רחבה מדי.
בטיחות סריקה ואינדוקס
באותה סקירה, עברו גם על ההשפעה של חסימות ישנות. לפעמים כלל שנכתב מזמן נשאר במקום, למרות שהוא כבר לא מתאים. בסוף כל סקירה, ודאו שדפים חשובים לא חסומים, ושדפים שצריכים להיעלם מטופלים דרך meta robots.
טבלת עזר מהירה לדירקטיבות
לפני שעוברים להתאמות לאתרים בעברית, הנה סיכום קצר של ארבע הדירקטיבות שחשוב להכיר. זאת טבלת בדיקה מהירה, מהסוג שכדאי לעבור עליה רגע לפני פרסום.
| דירקטיבה | מטרה | שימוש | טעות נפוצה |
|---|---|---|---|
| User-agent | קובע לאיזה בוט הכללים חלים | חייב לפתוח כל קבוצת כללים | כתיבת הנחיות לפני שמגדירים User-agent; שימוש בשמות בוטים שגויים |
| Disallow | חוסם סריקה של נתיבים או קבצים | מגדיר מה אסור לסריקה | בלבול עם noindex; חסימת קבצי CSS/JS; חסימת כל האתר עם / |
| Allow | פותח נתיב חסום | מבטל חסימה ספציפית של Disallow |
שימוש בו על נתיבים שלא חסומים ממילא – מיותר לחלוטין |
| Sitemap | מצביע על קובץ ה-XML של מפת האתר | שורה נפרדת | שימוש ב-URL יחסי במקום כתובת מלאה; הצבתו בתוך קבוצת User-agent ספציפית |
שני דגשים קטנים עושים פה הרבה סדר: ב־Sitemap כתבו תמיד כתובת מלאה, וב־Allow השתמשו רק כשצריך לפתוח חריג מדויק בתוך חסימה רחבה.
אחרי הסיכום הזה, עוברים לשיקולים שמיוחדים לאתרים ישראליים.
הערות לאתרים עסקיים בעברית
באתרים בעברית, כתובות URL לא פעם משלבות עברית ולטינית באותה כתובת. בגלל זה, התאמה מדויקת של ה־slug היא נקודה שאסור לפספס. ב־robots.txt צריך לכתוב את הנתיב בדיוק כפי שהוא מופיע בדפדפן, כולל אותיות עבריות וגם רישיות כשיש כאלה.
אם יש אפילו אי־התאמה קטנה בין הנתיב שבקובץ לבין הכתובת בפועל, הכלל פשוט לא יעבוד. זה קורה הרבה יותר ממה שנדמה, בייחוד באתרים שבהם מערכת האתר מייצרת כתובות בעברית או כתובות מעורבות.
יש גם כשל נפוץ נוסף באתרים עסקיים בעברית: אחרי שבודקים את התחביר, פתחו את /robots.txt וודאו שהוא מחזיר טקסט בלבד. אחר כך פתחו את כתובת ה־Sitemap ובדקו שהיא מפנה לסביבת הייצור, ולא לסביבת בדיקות.
סיכום
קובץ robots.txt אולי קטן, אבל ההשפעה שלו על הנראות של האתר יכולה להיות גדולה מאוד. הכלל המרכזי פשוט: פשטות, דיוק ועדכון שוטף. בפועל, הערך של robots.txt לא נמדד לפי מספר השורות שבו, אלא לפי הדיוק של כל שורה.
כאן אין הרבה מקום לטעויות קטנות. שגיאת תחביר אחת, כמו Disallow: / במקום הלא נכון, עלולה כמעט לעצור את גילוי הדפים החדשים. וזה הקאץ': גם אחרי שמתקנים את השגיאה, הנראות לא חוזרת מיד. לכן כל שינוי צריך לעבור בדיקה לפני פרסום, ואז סקירה קצרה פעם ברבעון.
ארבעת הצירים שליוו את כל המאמר – מיקום, תחביר, חסימות נכונות ועדכון שוטף – הם גם ההמלצה המעשית. קובץ קטן, השפעה גדולה, תחזוקה קבועה.
FAQs
מתי robots.txt לא מספיק לבדו?
קובץ robots.txt נועד לנהל סריקה בלבד. הוא לא כלי אבטחה, ולא דרך להסתיר מידע רגיש.
בפועל, זה יותר סוג של בקשה מאשר חסימה קשיחה: מנועי חיפוש גדולים בדרך כלל מכבדים את ההוראות שבו, אבל בוטים אחרים יכולים פשוט להתעלם מהן.
יש עוד נקודה שחשוב להבין. robots.txt גם לא מונע אינדוקס באופן מוחלט. אם דף חסום לסריקה מקבל קישורים מאתרים אחרים, הוא עדיין יכול להופיע באינדקס.
לתוכן רגיש, השתמשו בהגנה באמצעות סיסמה. אם המטרה היא למנוע אינדוקס, השתמשו ב-noindex.
איך מונעים חסימה בטעות של כל האתר?
כדי לא לחסום בטעות את כל האתר, חשוב לכתוב את קובץ ה-robots.txt בדיוק ולבדוק כל שינוי לפני שמעלים אותו לאוויר. לפעמים טעות קטנה אחת עושה בלגן גדול. למשל, שימוש לא נכון בלוכסן (/) תחת Disallow יכול לחסום את האתר כולו.
בגלל זה כדאי לבדוק את הקובץ מראש, ולא לסמוך על ניחוש. מומלץ להשתמש בכלי בדיקה ל-robots.txt, כולל ב-Google Search Console, כדי לאמת את התחביר, לזהות שגיאות ולראות איך רובוטים מפרשים את ההוראות.
איך בודקים ש־Sitemap ו־CSS/JS פתוחים לסריקה?
בדקו את קובץ robots.txt בדומיין שלכם. המטרה פשוטה: לוודא שאין שם הוראת Disallow שחוסמת תיקיות קוד או עיצוב חשובות, כמו /wp-includes/ או /assets/.
למה זה חשוב? כי חסימה רחבה מדי עלולה למנוע ממנועי חיפוש לגשת לקבצים שהעמוד נשען עליהם כדי להיטען ולהופיע כמו שצריך. לפעמים זה נראה כמו פרט קטן, אבל בפועל זה יכול לעשות בלגן.
אם יש חסימה גורפת, אפשר להשתמש ב־Allow כדי לפתוח גישה לקבצים או נתיבים מסוימים בלי להסיר את כל החסימה.
בנוסף, בדקו שמפת האתר מופיעה בקובץ דרך ההנחיה Sitemap. כך מנועי החיפוש מקבלים נתיב ישיר למפת האתר שלכם, במקום לחפש אותה לבד.
