// מדריך
איך עושים GEO באתר שלכם בפועל?
מאת: Dmitry Filippov, Founder, GET-GEO.AI
פורסם: 2026-08-03 · עודכן: 2026-09-22
// תשובה קצרה
בבדיקה טכנית של get-geo.ai איחדנו את כתובות האתר וההפניות, עברנו לנכס דומיין ב-Search Console והוספנו את תוכן המדריכים לקובצי llms-full לפי שפה. הקבצים מתעדכנים מאותו מקור שממנו נבנים הדפים. השינויים נועדו לאפשר גישה עקבית לתוכן; הם אינם מבטיחים שהעוזרים יבחרו בו כמקור.
- GEO על האתר שלנו לקח חצי יום ולא דרש דפים חדשים: מארח ראשי אחד, נכס דומיין ב-Search Console וייצוא llms-full שנבנה מחדש.
- כל האותות הצביעו על ה-apex בעוד ה-apex ענה בהפניית 308 ל-www: לולאה שמנגנוני שליפה של AI עם תקציב של בקשה אחת לעולם לא עוברים.
- רשימת הבדיקות של סוכן AI קבעה שרשומת ה-A של ה-apex צריכה להצביע על 76.76.21.21; ה-DNS החי הראה 216.198.79.1, התשתית החדשה של Vercel, ולכן אמתו עצות של מודל מול המערכת החיה.
- sitemap שהוגש זה עתה עשוי להציג "Couldn't fetch" יומיים-שלושה; בדקו שלושה דברים: הקובץ נפתח, כל loc משתמש במארח הנכון, robots.txt מונה אותו.
- llms-full יוצא כעת כקובץ אחד לכל שפה עבור 9 שפות; דוונאגרי תופס 3 בתים לתו, ולכן קובץ ההינדי הגיע ל-85 KB והתקרה עלתה ל-300 KB.
נקודת המוצא: אתר שנראה תקין
אנחנו מיישמים את עבודת ה-GEO גם באתר שלנו. המדריך הזה מתעד בדיקה טכנית אחת: מה מצאנו, איך תיקנו ומה בדקנו לאחר מכן. כל הדוגמאות הן מהאתר הזה.
get-geo.ai נבנה "לפי הספר" מהיום הראשון: רינדור בצד השרת, 9 שפות עם hreflang, JSON-LD של Schema.org, מבנה answer-first, llms.txt. מה כבר יכול להיות פה לתקן? הביקורת מצאה בעיה שאי אפשר לראות בעיניים.
ממצא מס' 1: הקונפליקט בין apex ל-www
האתר חי פיזית על www.get-geo.ai, בעוד שכל האותות — canonical, sitemap, hreflang, JSON-LD, llms.txt — הצביעו על get-geo.ai (ה-apex, הדומיין ללא תת-דומיין). וה-apex עצמו ענה בהפניית 308 בחזרה ל-www.
התוצאה — לולאה: "הגרסה הקנונית היא ה-apex" → ה-apex מפנה ל-www → www מכריז "הגרסה הקנונית היא ה-apex". סורק קלאסי של Google שורד את זה, גם אם תוך שריפת תקציב סריקה. מנגנוני שליפת דפים של AI — לא תמיד: לרבים מהם תקציב של בקשה אחת או שתיים לעמוד, וחלקם פשוט לא מגיעים לתוכן דרך הפניה. עבור GEO זה קריטי: קובץ שאינו נראה למנגנון השליפה הוא קובץ שאינו קיים.
התיקון: ה-apex הוגדר כדומיין ראשי אצל ספק האחסון (Vercel), ו-www הופנה ב-308 אל ה-apex. מתג אחד — וכל האותות נעשו עקביים: הכתובת בפועל, ה-canonical, הקישורים הפנימיים, ה-sitemap ו-llms.txt מצביעים עכשיו לאותה נקודה.
יש לבחור כתובת ראשית אחת, עם www או בלעדיו, ולהפנות אליה את החלופה. הקישורים הפנימיים, התגיות הקנוניות ומפת האתר צריכים להיות עקביים עם הבחירה הזאת.
ממצא מס' 2: עצה מיושנת של סוכן AI
את האבחון ביצע סוכן AI, וברשימת הבדיקות שלו נכתב: "ודאו שרשומת ה-A של ה-apex מצביעה על 76.76.21.21". בדיקת ה-DNS האמיתי הראתה אחרת: הדומיין נפתר ל-216.198.79.1 — התשתית החדשה של Vercel, שאליה עבר ספק האחסון אחרי מועד חיתוך נתוני האימון של המודל.
העצה לא הייתה מזיקה — רק מיושנת. המודל ציטט את העבר בביטחון מלא.
מומלץ לבדוק עצות טכניות של מודל מול המערכת והתיעוד העדכניים. במקרה הזה, שאילתת DNS הראתה מהי הכתובת שהדומיין משתמש בה בפועל והבהירה שההמלצה התבססה על מידע ישן.
שלב 3: Google Search Console — נכס דומיין
אחרי החלפת המארח הראשי, הנכס הישן ב-GSC (קידומת URL על https://www.get-geo.ai/) איבד את ערכו: הוא מכסה רק את www, בעוד העמודים עוברים ל-apex.
התצורה הנכונה היא נכס דומיין (get-geo.ai, בלי פרוטוקול ובלי תת-דומיין): הוא מכסה בבת אחת apex, www, http, https וכל תתי-הדומיינים. אימותו אפשרי רק דרך רשומת DNS TXT — ופה פרט משמח: הטוקן google-site-verification קשור לחשבון, לא לשיטת האימות, ולכן רשומה שנוספה ל-DNS קודם לכן עברה אימות באופן מיידי. לאחר מכן — שליחת ה-sitemap בכתובת ה-apex: https://get-geo.ai/sitemap.xml.
הלקח: sitemap שזה עתה נשלח ב-GSC נשאר לעיתים קרובות עם סטטוס אדום "לא ניתן היה לאחזר" ואפס עמודים. זו אינה שגיאה אלא ממלא-מקום עד לעיבוד הראשון — הוא אסינכרוני ועשוי לקחת עד יומיים. לפני שנבהלים, בודקים שלושה דברים: הקובץ נפתח בכתובת הישירה שלו; כל <loc> בפנים מצביע על המארח הנכון; ב-robots.txt קיימת שורת Sitemap:. אם שלושתם מתקיימים — פשוט ממתינים.
שלב 4: ה-sitemap ככלי GEO, לא כפורמליות
ה-sitemap שלנו כולל יותר מעמודים. הוא מונה את llms.txt, את llms-full.txt ואת כל גרסאות השפה llms-full/{locale} — עם תאריכי lastmod ועדיפויות.
למה: סורקים של AI (GPTBot, ClaudeBot, PerplexityBot) נצפו קוראים sitemap, וציון מפורש של קובצי ה-LLM נותן להם מסלול ישיר לגרסה המכונה-קריאה של האתר — בלי להסתמך על כך שמנגנון השליפה מכיר את מוסכמת /llms.txt.
מפת האתר צריכה לכלול את הכתובות שרוצים לחשוף לסורקים ולציין תאריכי lastmod שמשקפים שינויים אמיתיים.
שלב 5: llms-full — התוכן המלא, לא תוכן העניינים
המוסכמה מבחינה בין שני קבצים: llms.txt — תוכן עניינים עם קישורים; llms-full.txt — התוכן המלא למערכות שאינן עוקבות אחר קישורים. בגרסת ה-full שלנו היה בתחילה רק דף הנחיתה: המדריכים — הנכס הציטוטי ביותר שלנו — היו זמינים רק עמוד-עמוד.
מה שינינו:
- קבצים לפי שפה. הטקסטים המלאים של המדריכים עברו ל-llms-full/{locale}, כל קובץ כולו בשפתו. לדחוס 9 שפות לקובץ אחד פירושו לדלל פי תשעה את הצפיפות המועילה לכל שאילתה ספציפית.
- כתובת URL מתחת לכל כותרת. בתוך הקובץ, כל מדריך נפתח בכותרת וב-URL הקנוני מיד מתחתיה — כדי שמודל שנוטל את הטקסט יוכל לצטט את העמוד, לא את קובץ ה-txt עצמו.
- יצירה אוטומטית ממקור אחד. קובצי הייצוא ודפי המדריכים נבנים מאותו מאגר תוכן, כך שפרסום מדריך מעדכן גם את האתר, גם את מפת האתר וגם את llms-full.
- טיפול בחריגה ממגבלת הגודל. כשהקובץ מגיע לתקרה, מצורפת רשימה עם קישורים למדריכים שלא נכנסו במלואם.
- לקח ממקום בלתי צפוי: את מגבלת ה-100 KB הראשונה כמעט שברה מערכת כתב. Devanagari (הינדי) תופסת 3 בייטים לתו ב-UTF-8 לעומת 1 בלטינית — קובץ ההינדי הגיע ל-85 KB כשהאנגלי שקל מחצית מזה. העלינו את המגבלה ל-300 KB. אם האתר שלכם רב-לשוני, תקצבו בהתחשב בכתב: מערכות CJK והודיות שוקלות פי כמה.
סיכום היום
חצי יום עבודה, אף לא עמוד תוכן חדש אחד — ובכל זאת:
- כל אות באתר מצביע על מארח אחד, בלי לולאות והפניות מיותרות;
- מנגנון שליפת דפים של AI עם תקציב של בקשה אחת מקבל את התוכן בניסיון הראשון;
- GSC אוסף נתונים על הדומיין כולו, לא על תת-דומיין אחד;
- קורפוס המדריכים המלא ב-9 שפות זמין למכונות בקובץ אחד לכל שפה;
- פרסום מדריך חדש מעדכן אוטומטית את האתר, את ה-sitemap ואת llms-full.
מה אפשר להסיק מהבדיקה הטכנית?
גישה תקינה מאפשרת למערכות לקרוא את התוכן. איכות המידע, התאמתו לשאלה והמקורות התומכים בו משפיעים על האפשרות להשתמש בו בתשובה. לכן כדאי לבדוק את התשתית לצד עבודת התוכן, ולא לראות בתיקון הטכני הבטחה לציטוט.
שאלות קשורות
האם apex מול www חשוב ל-GEO?
הבחירה עצמה לא. מה שחשוב הוא שהאתר יחיה בדיוק על מארח אחד וכל האותות — canonical, sitemap, hreflang, JSON-LD, llms.txt — יצביעו לשם, עם hostname השני בהפניה קשיחה. לולאה בין apex ל-www שורפת תקציב סריקה ולעיתים קרובות עוצרת מנגנוני שליפת דפים של AI שעושים רק בקשה אחת או שתיים.
האם להשתמש בנכס דומיין ב-Google Search Console?
כן, אם אכפת לכם גם מ-apex וגם מ-www (או http ו-https). נכס דומיין מכסה את כולם בבת אחת ומאומת דרך DNS TXT. נכס קידומת URL על www בלבד מתעוור ברגע שהמארח הראשי עובר ל-apex.
למה לציין llms.txt ב-sitemap?
סורקים של AI נצפו קוראים sitemap. ציון llms.txt וקבצי llms-full לפי שפה נותן להם מסלול ישיר לקורפוס המכונה-קריא בלי להסתמך על כך שכל מנגנון שליפה מכיר את מוסכמת /llms.txt.
למה קבצי llms-full לפי שפה במקום קובץ רב-לשוני אחד?
קובץ אחד עם תשע שפות מדלל פי תשעה את הצפיפות המועילה לכל שאילתה ספציפית. קובץ אחד לכל שפה שומר על קורפוס צפוף, שם URL קנוני תחת כל כותרת מדריך, וניתן לייצר אותו מאותו רישום כמו עמודי ה-HTML.
מדריכים קשורים
מקורות
// שיתוף
איך לצטט את העמוד הזה
מוזמנים לצטט ולעשות שימוש חוזר — עם ייחוס וקישור לעמוד זה.
“איך עושים GEO באתר שלכם בפועל?” — GET-GEO.AI, 2026-09-22. https://get-geo.ai/he/guides/how-we-do-geo-ourselves