זיהוי וחסימת בוטים מזויפים של גוגל באמצעות .htaccess

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

בוטים רבים המתקיפים אתרים מציגים את עצמם בתור Googlebot, Google-InspectionTool, AdsBot-Google או Googlebot-Image על מנת לעקוף חומות אש ופילטרים פשוטים. בעלי אתרים לרוב חוששים לחסום את הסריקות של גוגל. פער זה עלול לגרום לבעיות כמו כריית תוכן, צריכת משאבים גבוהה, תעבורה מזויפת, ספאם בטפסים, ניסי כניסה והפרת נתוני SEO. במיוחד באירוח משותף, WordPress, WooCommerce, אתרי חדשות ובלוגים שמתעדכנים לעיתים קרובות, תעבורה זו עלולה להעמיס במהירות על מגבלות ה-CPU, ה-RAM וה-I/O. במדריך זה נסקור שלב אחר שלב כיצד לקרוא את ההתנהגויות של בוטים מזויפים של גוגל, כיצד לכתוב כללים בטוחים ב-.htaccess ואילו בדיקות עליכם לבצע כדי לא לחסום בטעות את Googlebot האמיתי. אם אתם זקוקים לתשתית בטוחה, מהירה וניתנת להתרחבות עבור האתר שלכם, אתם יכולים לכלול גם את התכנים על פתרונות אחסון אתרים Hostragons ו-התקנת תעודת SSL בתוכנית שלכם.

מהו בוט מזויף של גוגל ולמה הוא מסוכן?

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

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

במציאות, אנו מזהים בוטים מזויפים לרוב על ידי הסימנים הבאים:

• בקשות שמייצרות מאות תשובות 404, 403 או 500 בפרק זמן קצר.
• סריקות של כתובות רגישות כמו wp-login.php, xmlrpc.php, admin, phpmyadmin, backup.zip.
• כתובת IP שאינה נמצאת בטווחי ה-ASN של גוגל או בכתובות IP הרשמיות של גוגל, למרות שסוכן המשתמש מציג את עצמו כ-Googlebot.
• ביקורים בדפי סינון, חיפוש, סל או חשבון מבלי לכבד את כללי robots.txt.
• בקשות לאותן כתובות URL באותה תדירות גבוהה באופן יוצא דופן בהשוואה ל-Googlebot האמיתי.

למה בדיקת סוכן המשתמש בלבד אינה מספיקה?

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

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

איך לאמת את Googlebot האמיתי?

גוגל ממליצה על שתי שיטות עיקריות כדי לאמת את הדפדפנים האמיתיים שלה: אימות DNS הפוך וטווחי IP רשמיים. בשיטת DNS ההפוכה, שם הדומיין של כתובת ה-IP שמביאה את הבקשה צריך להסתיים ב-googlebot.com או google.com, ולאחר מכן שם הדומיין הזה צריך להתפרש שוב לאותה כתובת IP. אימות דו-כיווני זה מונע הונאה עם רשומת PTR מזויפת.

השיטה השנייה היא להשתמש בטווחי ה-IP הרשמיים שגוגל מפרסמת. Googlebot מפרסם רשימות JSON שונות לדפדפנים מיוחדים ולקובצי ייבוא המופעלים על ידי משתמשים. במיוחד מכיוון שרשימות דינמיות עשויות להשתנות עם הזמן, לא נכון להסתמך על רשימות IP ישנות שנכתבו ידנית בסביבת הפקה לאורך זמן. אם יש לכם VPS או ניהול שרת, גישה בריאה היא למשוך את הרשימות הללו מעת לעת ולעדכן את חומת האש או את קובץ ה-includes של Apache. אם אתם משתמשים באירוח משותף, אתם יכולים להתקדם עם יומני הגישה בלוח הבקרה שלכם, .htaccess ועם מודולים אבטחה אם ישנם.

עקרון חסימת בוטים מזויפים עם .htaccess

.htaccess מאפשר לכם להגדיר כללים מבוססי תיקיות בשרת ה-Web של Apache. הוא משמש להפניית URL, בקרת גישה, דחיסה, קאש ומגבלות אבטחה בסיסיות. תפקידו של .htaccess בחסימת בוטים מזויפים הוא להעריך את הבקשה המתקבלת על פי תנאים מסוימים ולחסום את השנויה במחלוקת עם תשובת 403 Forbidden.

עם זאת, יש מגבלה חשובה: .htaccess הסטנדרטי אינו המקום האידיאלי לבצע שאילתות DNS הפוכות בזמן אמת. ב-Apache, HostnameLookups בדרך כלל כבויים מסיבות של ביצועים. לכן, השיטה המעשית ביותר ב-.htaccess היא להשוות בקשות שטוענות להיות Googlebot עם רשימת IP שמותרת או לסנן דרכים חשודות בצורה נחרצת יותר. עבור אימות מתקדם יותר, ניתן להשתמש ב-WAF, חומת אש של השרת, CDN או אוטומציה המוזנת מיומנים. התוכן על מה זה CDN והשפעתו על ביצועי האתר יכול לעזור לכם לתכנן את השכבה הזו.

יישום שלב אחר שלב: זיהוי וחסימת בוטים מזויפים של גוגל

1. בדקו את יומני הגישה

לפני כתיבת כלל החסימה, בדקו את יומני הגישה במשך לפחות 24-72 שעות. אם נפח התנועה שלכם גבוה, אפילו שעה אחת של יומן יכולה לספק אותות מספקים. התחומים שבהם צריך להתמקד הם כתובת ה-IP, תאריך, URL המבוקש, קוד מצב HTTP, גודל בתים, מפנה ומידע על סוכן המשתמש. לדוגמה, אם אותה כתובת IP מבקשת 800 בקשות בעשר דקות, רובם חוזרים 404 ומזדהים כ-Googlebot, זהו אות חשד חזק.

ב-cPanel או בלוחות בקרה דומים, תוכלו להוריד את היומנים מאזור Raw Access Logs. אם יש לכם גישה ל-SSH, תוכלו להשתמש בכלים כמו grep, awk ו-sort כדי לחלץ את העומס על בסיס IP עבור הבקשות המתחזות ל-Googlebot. המטרה היא לראות את ההתנהגות של ה-IP שמזדהה כ-Googlebot, ולא את כל הבקשות שכתובות כך.

2. אמת את ה-IPים המתחזים ל-Googlebot

לאחר שזיהיתם IPים חשודים, בצעו בדיקה של DNS הפוך ו-DNS ישיר. אם לרשומת PTR של IP יש צורת crawl-66-249-66-1.googlebot.com, היא עוברת את השלב הראשון. לאחר מכן, כאשר אתם פותרים שוב את שם הדומיין, הוא צריך לחזור לאותה כתובת IP. אם אין רשומת PTR, אם היא מפנה לדומיין אחר, או אם הפתרון הישיר לא מחזיר את אותה כתובת IP, יש להתייחס אליה כאל לא Googlebot אמיתי.

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

3. קודם לרשום, לאחר מכן לחסום

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

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

דוגמאות לכללי .htaccess בטוחים

הדוגמאות הבאות יש לבדוק לפני העברתם לסביבת ההפקה, בהתאם לגרסת Apache של השרת שלכם, המודולים הפעילים והרשאות האירוח. Apache 2.4 ו-mod_rewrite נתמכים בדרך כלל; עם זאת, בסביבות משותפות מסוימות, הפקודות עשויות להיות מוגבלות. אל תשכחו לגבות את קובץ .htaccess שלכם לפני ביצוע שינויים. שגיאה בודדת בכתיבה יכולה לגרום לשגיאת 500 Internal Server Error באתר שלכם.

מסנן התנהגות פשוט: חסימת בוטים מזויפים בכתובות רגישות

גישה זו חוסמת את גישתם של בוטים המתחזים ל-Googlebot לקבצים רגישים ולמטרות תקיפה. Googlebot האמיתי אינו צריך לסרוק את wp-login.php, phpmyadmin או קבצי zip גיבוי. לכן, הסיכון לשגיאות חיוביות נמוך.

• RewriteEngine On
• RewriteCond %{HTTP_USER_AGENT} (Googlebot|Google-InspectionTool|AdsBot-Google|Mediapartners-Google) [NC]
• RewriteCond %{REQUEST_URI} (wp-login[.]php|xmlrpc[.]php|phpmyadmin|adminer|backup|[.]sql|[.]zip) [NC]
• RewriteRule ^ - [F,L]

כלל זה מחזיר 403 אם לקוח המתחזה ל-Googlebot מנסה לגשת לדרכים רגישות. הסיכון להשפיע על סריקות SEO הוא נמוך, מכיוון שאין רצון שהדרכים הללו יופיעו באינדקס של גוגל. אם אתם משתמשים ב-WordPress, יש לוודא גם לגבי תוספי אבטחה, הצורך ב-XML-RPC ושירותי פרסום מרוחקים.

עקרון רשימת IP מותרים: השוואת תביעת Googlebot עם טווחים רשמיים

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

• RewriteEngine On
• RewriteCond %{HTTP_USER_AGENT} (Googlebot|Googlebot-Image|Googlebot-News|Google-InspectionTool|AdsBot-Google) [NC]
• RewriteCond expr "! ( %{REMOTE_ADDR} -ipmatch '66.249.64.0/19' || %{REMOTE_ADDR} -ipmatch '64.233.160.0/19' || %{REMOTE_ADDR} -ipmatch '72.14.192.0/18' )"
• RewriteRule ^ - [F,L]

טווחי ה-IP כאן ניתנים כדוגמה בלבד. בסביבת הפקה יש להשתמש בטווחים המיוצרים אוטומטית מתוך רשימת ה-IP JSON המעודכנת של גוגל. אם הפקודה של Apache או -ipmatch לא נתמכות בשרת שלכם, אשרו את תמיכת הפקודות של Apache 2.4 מספק האירוח שלכם. לחלופין, תוכלו ליצור כלל עם רשימת IP בשכבת CDN/WAF.

צמצום מהירות בקשות חשודות

.htaccess אינו הכלי הטוב ביותר להגביל מהירות באופן מתקדם; אך הוא עשוי לעזור לקטוע כמה התנהגויות רעות מוקדם. למגבלת מהירות אמיתית יש להשתמש ב-mod_evasive, mod_security, הגבלת קצב CDN או הגנה ברמת האפליקציה. במיוחד, בוטים ששולחים יותר מ-5-10 בקשות בשנייה עשויים להגדיל את השאילתות במסד הנתונים גם באתרים קטנים. במערכות דינמיות כמו WordPress, דפי חיפוש, קטגוריות עם מסננים ודפי תגיות עשויים להיות מנוצלים על ידי בוטים. עבור אזורים אלו יש לשקול את השימוש ב-robots.txt, canonical, noindex וכללי אבטחה יחד. התוכן על מדריך לאופטימיזציית מהירות WordPress משלים את הצד של הביצועים.

טבלת השוואה: מתי להשתמש בכל שיטה?

רשימת בדיקה למניעת חסימת Googlebot האמיתי בטעות

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

• בדקו אם יש ירידה פתאומית או עלייה ב-403 בדו"ח הסטטיסטיקות של סריקות ב-Google Search Console.
• בדקו ביומני השרת אם הבקשות מכתובות IP אמיתיות של גוגל מחזירות קודים 200, 301 או קודים מתאימים.
• ודאו שהקובץ robots.txt שלכם אינו חוסם גישה לגוגל לקטגוריות קריטיות שאינן סגורות.
• בדקו את המפת האתר, דף הבית, דפי הקטגוריה ודפי מוצרים חשובים לפני ואחרי שינוי ב-.htaccess.
• תעדו את מקור רשימת ה-IP שבה השתמשתם ותאריך העדכון.

מבחינת SEO טכנית, תשובת 403 היא אות חזק. אם Googlebot האמיתי רואה 403 שוב ושוב בדפים חשובים, הסריקות של כתובות URL אלו עשויות לרדת. לכן, יש להפעיל 403 רק על בוטים בלתי רצויים לחלוטין ועל דרכים רגישות. במקרים של תחזוקה, עומס זמני או הגבלת קצב, 429 Too Many Requests עשוי להיות מתאים יותר בכמה תרחישים; אך ב-.htaccess, חסימת בוטים פשוטה עם 403 היא נפוצה ומובנת יותר.

צעדים נוספים עבור אתרי WordPress ואתרי מסחר אלקטרוני

בתוך אתרי WordPress, תנועת בוטים מזויפים של גוגל מתמקדת לרוב על xmlrpc.php, wp-login.php, קצוות REST API, כתובות URL חיפוש וארכיונים של כותבים. באתרים מסחריים, הפרמטרים של הסינון, שאילתות המלאי, קצוות הסל וריאציות המוצרים הם המטרות. לכן, עליכם להתמודד לא רק עם אלה המתחזים ל-Googlebot, אלא גם עם היגיינת הבוטים הכללית.

• השתמשו באימות דו-שלבי ובמגבלה על ניסי כניסה לדף הכניסה.
• כיבו או הגבילו פונקציות XML-RPC שאינן בשימוש.
• תכננו אסטרטגיה משולבת של noindex, canonical ו-robots.txt עבור כתובות URL חיפוש וסינון.
• השתמשו בגרסת PHP עדכנית, בתבנית עדכנית ובתוספים מהימנים.
• שמרו על תעודת SSL שלכם פעילה; העברת נתונים מאובטחת וטפסים עם HTTPS היא חובה. תעודות SSL Hostragons
• בצעו בדיקה סדירה של רשומות ה-DNS של שם הדומיין שלכם; רשומות DNS שגויות ודוא"ל חלש מגדילות את הסיכון לאבטחה. בדיקת דומיין וניהול DNS

השפעת ביצועים: איך תנועת בוטים צורכת משאבי שרת?

תנועת בוטים אינה רק בעיית אבטחה; היא גם בעיית ביצועים של האירוח. בקשה לתמונה סטטית היא בעלת עלות נמוכה, בעוד שבקשה לתוצאת חיפוש ב-WordPress או בקשה לסינון ב-WooCommerce מביאות לשאילתות במסד הנתונים. אם בוט מזויף שולח 300 בקשות דינמיות בדקה, בדפים שאינם מאוחסנים, מעבדי ה-PHP עלולים להתמלא, מספר החיבורים למסד הנתונים עלול לגדול, ומשתמשים אמיתיים עלולים לחוות האטה.

נביא דוגמה פשוטה: אם דף סינון מוצר צורך בממוצע 250 ms זמן עיבוד PHP, 600 בקשות בוט בדקה יוצרות 150 שניות של עומס עיבוד. עומס זה פועל במקביל ומגיע לגבולות ה-CPU, מה שמעלה את ערכי TTFB. בצד של Core Web Vitals, תגובה איטית של השרת משפיעה בעקיפין על חוויית המשתמש ועל שיעורי ההמרה. לכן, חסימת בוטים היא לא רק חלק מהצוות האבטחתי, אלא גם חלק מאופטימיזציית SEO וביצועים.

בדיקות: האם הכללים שלכם עובדים?

לאחר שהוספתם את כלל .htaccess, בצעו שלוש בדיקות. קודם כל, בדקו את דף הבית של האתר שלכם, דפי קטגוריה חשובים ואת תהליך הכניסה בעזרת דפדפן רגיל. שנית, בצעו בדיקה חיה של URL חשוב בכלי בדיקת ה-URL של Google Search Console. שלישית, בדקו ביומנים אם ה-IPים החשודים המגיעים עם סוכן המשתמש Googlebot קיבלו 403, בעוד ש-IPים שעברו את האימות של גוגל לא נחסמו.

אם אתם מבצעים בדיקות בשורת הפקודה, אתם יכולים להציג את עצמכם כ-Googlebot; אך בדיקה זו אינה מוכיחה שאתם Googlebot אמיתי, אלא רק מספקת הבנה אם חלק סוכן המשתמש של הכלל הופעל. האימות האמיתי צריך להתבצע דרך IP ו-DNS. אם קיבלתם שגיאת 500 לאחר הבדיקה, ייתכן שיש שגיאת תחביר בקובץ .htaccess שלכם. במקרה זה, החזירו את השורות שהוספתם לאחרונה, בדקו את יומני השגיאות וודאו את הפקודות הנתמכות של Apache בשרת שלכם.

תוכנית תחזוקה: באיזו תדירות יש לעדכן את הכללים?

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

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

סיכום

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

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

שאלות נפוצות

האם בוטים מזויפים של גוגל משפיעים על דירוגי גוגל שלי?

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

האם נכון לחסום את כל סוכני המשתמש של Googlebot עם .htaccess?

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

באיזו תדירות עליי לעדכן את רשימות ה-IP של Googlebot?

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

קיבלתי שגיאת 500 לאחר שהוספתי כלל .htaccess, מה לעשות?

שגיאת 500 נובעת בדרך כלל משגיאת תחביר, פקודה של Apache שאינה נתמכת או תו בריחה שגוי. החזירו את הכללים שהוספתם לאחרונה, בדקו את יומני השגיאות ואשרו את תמיכת הפקודות של Apache 2.4, mod_rewrite ופקודות אחרות בסביבת האירוח שלכם. לכן חשוב לגבות את .htaccess לפני השינויים.

אם אני משתמש ב-CDN או WAF, האם עדיין יש צורך בכלל .htaccess?

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