// מדריך
איך עושים GEO באתר שלכם בפועל?
עודכן: 2026-08-03
// תשובה קצרה
GEO טכני הוא היגיינה, לא קסם. ב-get-geo.ai חצי יום עבודה גרם לכל האותות להצביע על מארח אחד, נתן לפצ'רים של AI את התוכן בניסיון הראשון, העביר את Search Console לנכס דומיין, ושם את קורפוס המדריכים המלא בקבצי llms-full לפי שפה שמתעדכנים אוטומטית מאותו רישום כמו העמודים. התוכן מכריע אם יצטטו אתכם; ההנדסה מכריעה אם מישהו יגיע לקרוא רחוק מספיק כדי לצטט.
נקודת המוצא: אתר שנראה תקין
אנחנו מוכרים GEO — ולכן האתר שלנו חייב להיות מימוש-מופת. המדריך הזה אינו תיאוריה אלא פרוטוקול של יום עבודה אמיתי: מה מצאנו, איך תיקנו ומה בדקנו. כל הדוגמאות — מהאתר הזה עצמו.
get-geo.ai נבנה "לפי הספר" מהיום הראשון: רינדור בצד השרת, 8 שפות עם 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 מצביעים עכשיו לאותה נקודה.
הלקח: הבחירה בין apex ל-www אינה חשובה. חשוב שהאתר יחיה בדיוק על אחד מהם, והשני יפנה אליו באופן חד. כל פער בין "היכן האתר חי" ל"לאן האותות מצביעים" הוא מס שנגבה בכל ביקור של קרולר.
ממצא מס' 2: עצה מיושנת של סוכן AI
את האבחון ביצע סוכן AI, וברשימת הבדיקות שלו נכתב: "ודאו שרשומת ה-A של ה-apex מצביעה על 76.76.21.21". בדיקת ה-DNS האמיתי הראתה אחרת: הדומיין נפתר ל-216.198.79.1 — התשתית החדשה של Vercel, שאליה עבר ספק האחסון אחרי מועד חיתוך נתוני האימון של המודל.
העצה לא הייתה מזיקה — רק מיושנת. המודל ציטט את העבר בביטחון מלא.
הלקח: סוכן AI ללא כלי אימות הוא זיכרון, לא ידע. כל המלצה טכנית של מודל יש להצליב עם מצבה החי של המערכת: שאילתת DNS אחת אורכת שנייה וסוגרת את השאלה. וזה, אגב, העיקרון של GEO עצמו: מודלים עונים מתוך מה שהצליחו לקרוא — ובדיוק בגלל זה אנחנו הופכים תוכן לקריא.
שלב 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.
הלקח: התייחסו ל-sitemap כאל תפריט למכונות, לא כאל תיבת סימון. כל מה שאתם רוצים להראות למערכות AI צריך להיות מנוי שם, עם תאריכי lastmod כנים.
שלב 5: llms-full — התוכן המלא, לא תוכן העניינים
המוסכמה מבחינה בין שני קבצים: llms.txt — תוכן עניינים עם קישורים; llms-full.txt — התוכן המלא למערכות שאינן עוקבות אחר קישורים. בגרסת ה-full שלנו היה בתחילה רק דף הנחיתה: המדריכים — הנכס הציטוטי ביותר שלנו — היו זמינים רק עמוד-עמוד.
מה שינינו:
- קבצים לפי שפה. הטקסטים המלאים של המדריכים עברו ל-llms-full/{locale}, כל קובץ כולו בשפתו. לדחוס 8 שפות לקובץ אחד פירושו לדלל פי שמונה את הצפיפות המועילה לכל שאילתה ספציפית.
- כתובת URL מתחת לכל כותרת. בתוך הקובץ, כל מדריך נפתח בכותרת וב-URL הקנוני מיד מתחתיה — כדי שמודל שנוטל את הטקסט יוכל לצטט את העמוד, לא את קובץ ה-txt עצמו.
- יצירה אוטומטית מרישום אחד. הקבצים נבנים מאותו מקור שממנו נבנים עמודי המדריכים. מדריך חדש מגיע לאתר, ל-sitemap ול-llms-full בפעולה אחת. סנכרון ידני מת בתוך חודש — אנחנו אפילו לא התחלנו בו.
- מגבלה עם הידרדרות הוגנת. לקובץ יש תקרת גודל; בחריגה, במקום קיצוץ שקט — מצורפת רשימת המדריכים שלא נכנסו, עם קישורים.
- לקח ממקום בלתי צפוי: את מגבלת ה-100 KB הראשונה כמעט שברה מערכת כתב. Devanagari (הינדי) תופסת 3 בייטים לתו ב-UTF-8 לעומת 1 בלטינית — קובץ ההינדי הגיע ל-85 KB כשהאנגלי שקל מחצית מזה. העלינו את המגבלה ל-200 KB. אם האתר שלכם רב-לשוני, תקצבו בהתחשב בכתב: מערכות CJK והודיות שוקלות פי כמה.
סיכום היום
חצי יום עבודה, אף לא עמוד תוכן חדש אחד — ובכל זאת:
- כל אות באתר מצביע על מארח אחד, בלי לולאות והפניות מיותרות;
- פצ'ר AI עם תקציב של בקשה אחת מקבל את התוכן בניסיון הראשון;
- GSC אוסף נתונים על הדומיין כולו, לא על תת-דומיין אחד;
- קורפוס המדריכים המלא ב-8 שפות זמין למכונות בקובץ אחד לכל שפה;
- פרסום מדריך חדש מעדכן אוטומטית את האתר, את ה-sitemap ואת llms-full.
היגיינה, לא קסם
זה הצד הטכני של GEO: לא קסם, היגיינה. התוכן מכריע אם יצטטו אתכם. הטכניקה מכריעה אם מישהו יגיע לקרוא עד התוכן.
שאלות קשורות
האם 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.