רוב התקלות ב-AX Protocol נפתרות בשלוש בדיקות. הדף הזה מסביר איך לאבחן לבד, מה הסיבות הנפוצות לכל תסמין, ומה כדאי לצרף כשפותחים פנייה כדי לקצר את הטיפול.
רוב השאלות על AX Protocol נענות בתיעוד, כולל סעיף פתרון התקלות. העמוד הזה מסביר איך לאבחן בעיה בעצמכם בשלוש דקות, מה לצרף לפנייה כדי לקבל תשובה מהר, ואיך פונים אלינו בכל אחד מהמסלולים.
שולחים שאלה דרך טופס יצירת הקשר. חשוב לכלול את כתובת האתר ותיאור קצר של הבעיה. אנחנו עונים לפי זמינות, בדרך כלל בתוך כמה ימי עסקים. אין הבדל באיכות המענה — רק בזמן התגובה.
לקוחות Pro מקבלים מענה אישי בתוך יום עסקים אחד. משתמשים באותו טופס, ומוסיפים את ארבעת התווים האחרונים של מפתח הרישיון (מוצגים ממוסכים תחת AX Protocol ← הגדרות ← רישיון). זה מאפשר לנו לזהות את האתר ולשלוף את הסטטוס שלו מה‑hub עוד לפני שאנחנו כותבים תשובה.
אל תשלחו לנו את מפתח הרישיון המלא. ארבעה תווים אחרונים מספיקים לזיהוי. מפתח מלא הוא סוד שצריך להישאר אצלכם.
לפני שכותבים, כדאי לעבור על חמש הבדיקות האלה. בניסיון שלנו הן פותרות את רוב הפניות עוד לפני שהן נשלחות.
https://yoursite.com/.well-known/ax.json בדפדפן. אם מתקבל 404 — שמרו מחדש את הקישורים הקבועים (הגדרות ← קישורים קבועים ← שמור) ונסו שוב.https://yoursite.com/llms.txt. אמור להתקבל טקסט פשוט, לא עמוד HTML ולא הפניה.פנייה טובה חוסכת סבב שלם של שאלות. כדאי לכלול:
זה כמעט תמיד תקין. תנועת סוכנים אינה רציפה — סורק גדול עשוי לבקר באתר קטן פעם בשבוע. תנו שבעה ימים לפני שמסיקים מסקנה, ובמקביל ודאו שאין חסימה ברמת ה‑CDN.
ההפעלה מול ה‑hub נעשית בבקשה יוצאת מהשרת שלכם. אם השרת חוסם תעבורה יוצאת, ההפעלה נכשלת בשקט. התוסף מנסה שוב אוטומטית מדי יום. אם זה נמשך מעבר ל‑48 שעות, פנו אלינו עם ארבעת התווים האחרונים.
המניפסט נבנה מהנתונים שקיימים באתר. אם אין תיאור לאתר, אין עמודי מפתח מפורסמים ואין ערוץ יצירת קשר מוגדר — המניפסט יהיה דל. זו לא תקלה אלא השתקפות: תקנו את המקור והמסמך יתעדכן.
תלוי במי חוסמים. חלק מהסוכנים משמשים לאימון מודלים בלבד וחלקם משמשים להצגת תשובות עם ציטוט ולינק. חסימה גורפת מוציאה אתכם מהתשובות. הסבר מלא על השיקול הכלכלי נמצא בעמוד תשלום עבור סריקה.
הריצו את אתגר ה‑Zero‑Shot. זה מבחן פומבי שכל אחד יכול להריץ בעצמו, על כל סוכן שיודע לשלוף כתובות.
אם מצאתם התנהגות שגויה — לא שאלה, אלא באג — כתבו לנו עם צעדי השחזור המדויקים. אנחנו מטפלים בבאגים לפי חומרה ולא לפי סוג הרישיון: תקלה שמונעת מהתוסף לתפקד מטופלת קודם, גם אם דווחה על ידי משתמש בגרסה החינמית.
בקשות פיצ'ר מתקבלות בברכה. הפרוטוקול נמצא בפיתוח פעיל, וחלק לא מבוטל ממה שיש בו היום הגיע מבקשות של משתמשים שהריצו אותו על אתרים אמיתיים ונתקלו במה שחסר.
כשאתם פונים אלינו אנחנו רואים את מה שכתבתם ואת סטטוס הרישיון של האתר ב‑hub. אנחנו לא רואים את תוכן האתר, לא את משתמשיו ולא את נתוני המבקרים שלו. תיעוד תנועת הסוכנים נשמר אצלכם, בבסיס הנתונים שלכם. השתתפות במפקד הסוכנים היא בהסכמה מפורשת בלבד, וגם אז מדובר בספירות מצרפיות ללא כתובות IP וללא תוכן.
שלב א׳ — האם הנתיב חוזר בכלל. פותחים את נקודת הגילוי בדפדפן. 200 עם JSON תקין = התוסף עובד. 404 = מבנה הקישורים הקבועים לא רוענן; כניסה להגדרות הקישורים הקבועים ושמירה בלי שינוי בדרך כלל פותרת. 403 או תגובה ריקה = חומת אש או שכבת CDN חוסמות, לא התוסף.
שלב ב׳ — האם התוכן מעודכן. אם הנתיב חוזר 200 אבל מציג מידע ישן, זה כמעט תמיד מטמון: תוסף מטמון באתר, מטמון בשרת, או מטמון ב-CDN. ניקוי מלא ובדיקה חוזרת עם פרמטר אקראי בכתובת מבדילים בין השניים.
שלב ג׳ — האם הבוט באמת מגיע. אם הכול תקין בדפדפן אבל סוכן מדווח שאין גישה, בדקו את מדיניות הגישה. חסימה גורפת ב-robots.txt, כלל ב-Cloudflare, או תוסף אבטחה שמחזיר אתגר לכל user-agent לא מוכר — כל אחד מהם מייצר בדיוק את התסמין הזה.
| תסמין | סיבה סבירה | פעולה |
|---|---|---|
| 404 בנקודת גילוי | קישורים קבועים לא רועננו | שמירה מחדש של הגדרות הקישורים |
| מידע ישן ב-llms.txt | מטמון | ניקוי מטמון מלא ובדיקה חוזרת |
| סוכן מקבל 403 | חומת אש / CDN | הוספת חריג לבוטים המורשים |
| ציון AX נמוך למרות התקנה | תוכן שמורכב ב-JS בלבד | הגשת התוכן המרכזי ב-HTML |
| שני בלוקי סכמה | תוסף SEO נוסף מפרסם סכמה | כיבוי אחד מהמקורות |
כדי לחסוך סבב שאלות, צרפו: כתובת האתר, גרסת התוסף וגרסת וורדפרס, הכתובת המדויקת שנכשלת, קוד הסטטוס שקיבלתם, ורשימת תוספי המטמון והאבטחה הפעילים. אם התסמין הוא חסימת בוט — צרפו גם את השורה הרלוונטית מ-robots.txt. ברוב המקרים החומר הזה מספיק כדי לאבחן בלי גישה לאתר.
לא כל תקלה שווה באותה מידה, ולכן כדאי לסווג את הפנייה לפני ששולחים אותה. תקלה שמונעת מסוכנים לקרוא את האתר כולו – למשל מניפסט שמחזיר שגיאת שרת – היא דחופה, כי כל יום שעובר הוא יום שבו האתר לא מיוצג נכון במקורות שסוכנים מסתמכים עליהם. לעומת זאת, שדה חסר בקטלוג או ניסוח לא מדויק בתיאור השירות הם שיפור ולא כשל, ואפשר לטפל בהם במחזור העדכון הבא.
הסיווג הזה משפיע גם על מה שכדאי לעשות בזמן ההמתנה. בתקלה חוסמת עדיף להחזיר את האתר למצב יציב – להשבית זמנית את הרכיב הבעייתי – ורק אחר כך להמשיך בבירור. בתקלה שאינה חוסמת עדיף דווקא להשאיר את המצב כפי שהוא, כי שחזור של תקלה שכבר תוקנה חלקית לוקח יותר זמן מאשר אבחון של מצב חי.
מעבר לאחסון אחר, שינוי דומיין או מעבר לתת-דומיין הם האירועים שהכי מרבים לשבור את הגדרות הפרוטוקול, מפני שכתובות מוחלטות ששמורות בהגדרות ממשיכות להצביע על המיקום הישן. לפני מעבר כדאי לתעד את ההגדרות הנוכחיות, ואחרי המעבר לעבור על כל נתיב במניפסט ולוודא שהוא נפתח בכתובת החדשה. אם האתר עבר מ-HTTP ל-HTTPS, בדקו גם שאין הפניות כפולות בדרך: שרשרת הפניות ארוכה גורמת לחלק מהסוכנים לוותר על הבקשה באמצע.
רוב הפניות שמגיעות אלינו מתארות תקלה שכבר קרתה פעם באותו אתר. שמירה של יומן תקלות קצר – מה קרה, מתי, מה שינינו ומה פתר – חוסכת שעות בפעם הבאה, במיוחד באתרים שבהם מתחלפים אנשי תחזוקה. שורה אחת לכל אירוע מספיקה. אם אתם מנהלים כמה אתרים עם אותה תצורה, יומן משותף יגלה לכם מהר מאוד שרוב התקלות נובעות משלושה או ארבעה גורמים חוזרים, ואז אפשר לטפל בשורש במקום לתקן כל אתר בנפרד.