כיצד לאפשר לסורק של Shoply AI לעבור דרך חומת האש שלך

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

ברוב המקרים הפתרון הוא כלל אחד: לאפשר בקשות שה-User-Agent שלהן מכיל ShoplyAIBot. המדריך הזה מסביר למה הסורק נחוץ, איך לזהות אותו, ואיך לאפשר אותו ב-Cloudflare ובחומות אש אחרות.

מי צריך לעשות את זה?

• בעלי אתרי SiteChat. SiteChat הוא הצ’אט והחיפוש של Shoply לכל אתר שאינו חנות Shopify, כולל חנויות Magento.
• סוכנויות ומפתחים שמנהלים אחסון, CDN (רשת אספקת תוכן), או הגדרות אבטחה עבור אתרים כאלה.

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

למה Shoply צריכה לקרוא את האתר שלי?

Shoply קוראת את העמודים שרשמתם בהגדרות הסריקה שלכם כדי שהתשובות, המחירים והקישורים של הצ’אטבוט יתאימו לאתר החי שלכם.

עבור חנויות Magento, Shoply גם קוראת את קטלוג המוצרים הציבורי שלכם דרך נקודת הקצה GraphQL של החנות (/graphql). היא שולחת שאילתות מוצר לקריאה בלבד עבור פרטים כמו שמות, מק”טים, מחירים, וריאציות וכתובות URL של מוצרים.

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

מה קורה אם הסורק נחסם?

• הסריקות נכשלות. Shoply לא יכולה למשוך את העמודים או את נתוני המוצרים שלכם.
• ה-AI ממשיך לענות לפי הסריקה המוצלחת האחרונה. קונים עלולים לראות מחירים ישנים, מוצרים שכבר הסרתם, וקישורים מיושנים או שגויים. במקרה אמיתי אחד, חנות עברה מאתר פיתוח לדומיין הייצור שלה, אבל חומת האש שלה חסמה את הסורק, ולכן הצ’אטבוט המשיך להפנות קונים לאתר הפיתוח הישן.
• “Last updated … ago” מפסיק להתקדם בלוח הניהול של Shoply.

סימנים נפוצים לכך שהסורק חסום

בניהול של Shoply, זמן הסריקה מפגר. בלוח הבקרה, הזמן “Last updated at: … ago” תחת Content crawled by Shoply AI ממשיך לגדול במקום להתאפס כל כמה שעות, למשל “770 hours ago” (בערך חודש). הוא נשאר בפיגור גם אחרי שלוחצים על Recrawl Now, כי סריקה חסומה לעולם לא מסתיימת.

אם תבדקו את יומני חומת האש שלכם, הסימפטום הרגיל הוא ש-Cloudflare מחזירה HTTP 403 לבקשות של Shoply, באחת מהצורות הבאות:

• Error 1010, כלומר בעל האתר חסם את הבקשה על סמך חתימת הדפדפן שלה. הפתרון של Cloudflare עצמה לשגיאה הזו מפנה אל Browser Integrity Check.
• עמוד אתגר של “Just a moment…”, שסורק אינו יכול להשלים.

איך מזהים את הסורק של Shoply?

כל בקשה מהסורק של Shoply משתמשת ב-User-Agent הזה:

ShoplyAIBot/1.0 (https://shoplyai.ai; support@shoplyai.ai; For sites installed Shoply AI Search & Chatbot)

כתבו את הכללים שלכם כך שיתאימו לטקסט הקצר יותר ShoplyAIBot (למשל, “User-Agent contains ShoplyAIBot”). כך הכלל שלכם ימשיך לעבוד גם אם מספר הגרסה ישתנה.

אפשרו לפי user agent, לא לפי כתובת IP. הסורק של Shoply לא משתמש בכתובות IP קבועות, לכן רשימת היתרים לפי IP לא תעבוד בצורה אמינה.

איך הסורק פועל

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

מתי הסורק רץ

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

איך לאפשר את Shoply ב-Cloudflare?

ב-Cloudflare, צרו custom rule עם פעולת Skip. כלל דילוג מאפשר לבקשות תואמות לעקוף את בדיקות האבטחה שאחרת היו חוסמות אותן או מציגות להן אתגר.

שלב 1: יצירת כלל הדילוג

1. בלוח הבקרה של Cloudflare, פתחו את האתר שלכם (zone) ועברו אל Security rules.

2. בחרו Create rule > Custom rules.

3. בשדה Rule name, הזינו שם ברור, למשל Allow Shoply AI crawler.

4. תחת When incoming requests match, הגדירו:

   • Field: User Agent
   • Operator: contains
   • Value: ShoplyAIBot

   אם אתם מעדיפים את עורך הביטויים, השתמשו ב:

   text

   (http.user_agent contains "ShoplyAIBot")

5. תחת Then take action > Choose action, בחרו Skip.

6. בחרו מה לדלג עליו (ראו את הטבלה למטה).

7. השאירו את Log matching requests מופעל. כך הבקשות של Shoply יופיעו ב-Security Events של Cloudflare, מה שעוזר בפתרון תקלות.

8. בחרו Deploy.

שלב 2: בחירת מה לדלג עליו

התחילו עם השורות המסומנות “כן”. אם Security Events של Cloudflare עדיין מראה שהבקשות של Shoply נחסמות או מאותגרות, האירוע יספר לכם איזו תכונה פעלה. הוסיפו את התכונה הזו לכלל הדילוג.

שלב 3: לשים את הכלל ראשון

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

אם אתם משתמשים ב-Bot Fight Mode (תוכנית Cloudflare Free)

אי אפשר לעקוף את Bot Fight Mode באמצעות כלל Skip. Cloudflare מפעילה אותו בנפרד מהכללים המותאמים, ולכן לכללי skip ו-allow אין עליו השפעה. יש לכם שתי אפשרויות:

• לכבות את Bot Fight Mode: עברו אל Security > Settings, סננו לפי Bot traffic, וכבו את Bot fight mode.
• לשדרג לתוכנית Pro או גבוהה יותר ולהשתמש ב-Super Bot Fight Mode, שכן תומך בכללי skip.

אם Under Attack mode פעיל

Under Attack mode מציג עמוד אתגר לכל מבקר, וסורקים לא יכולים לעבור אותו. Cloudflare ממליצה להשתמש בו רק במהלך מתקפה פעילה. Shoply לא תוכל לקרוא את האתר שלכם עד שהוא יכובה.

האם בטוח לאפשר user agent?

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

איך לאפשר את Shoply בחומות אש אחרות?

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

• חומות אש של יישומי ווב בענן (WAFs) כמו Sucuri, AWS WAF ו-Akamai: הוסיפו כלל היתר או חריגה שמתאים לכותרת ה-User-Agent.
• תוספי אבטחה ל-WordPress כמו Wordfence: חפשו הגדרות של חסימת בוטים, rate limiting, או חסימה לפי user-agent.
• מסננים ברמת השרת כמו כללי ModSecurity, וחוסמי בוטים שספק האחסון שלכם מספק: הוסיפו את ה-user agent לרשימת ההיתרים, או בקשו מספק האחסון לעשות זאת.

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

אל תסתמכו על רשימת היתרים לפי IP. הסורק של Shoply לא משתמש בכתובות IP קבועות.

איך בודקים שזה עבד?

1. בניהול של Shoply, לחצו על Recrawl Now.
2. המתינו לסיום הסריקה, ואז בדקו שהשדה “Last updated” בלוח הבקרה שלכם התאפס לזמן עדכני.
3. שאלו את הצ’אטבוט על מוצר או עמוד ששיניתם לאחרונה, ואשרו שהתשובה והקישור תואמים לאתר החי שלכם.

אפשר גם לבצע בדיקה מהירה מהמחשב שלכם. החליפו את https://your-site.com/ בכתובת האתר שלכם:

curl -I -A "ShoplyAIBot/1.0 (https://shoplyai.ai; support@shoplyai.ai; For sites installed Shoply AI Search & Chatbot)" https://your-site.com/

תגובה של HTTP/2 200 (או HTTP/1.1 200 OK) פירושה שהכלל שלכם מאפשר לאותו user agent לעבור. 403 פירושו שמשהו עדיין חוסם אותו.

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

צריכים עזרה?

שלחו אימייל ל-support@shoplyai.ai עם כתובת האתר שלכם, חומת האש או ספק האחסון שבהם אתם משתמשים, וצילום מסך של כל בקשה חסומה ביומני חומת האש שלכם. אנא אל תשלחו סיסמאות או מפתחות API.