NotebookLM משנה שם: כך מגנים על תוכן AI

הגנה על תוכן AI כבר לא מסתכמת בשאלה אם האתר פתוח או סגור לסריקה. לפי הדיווח שפורסם ב-Search Engine Journal ב-18 ביולי 2026, שינוי השם של NotebookLM ל-Gemini Notebook משנה גם את ה-user-agent הרלוונטי, ומזכיר לבעלי אתרים נקודה קריטית: יש סוגי גישה לתוכן שלא נשענים על robots.txt.

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

מה קרה בפועל?

לפי הדיווח שסופק בתור המאמרים, Google עדכנה את התיעוד שלה בעקבות שינוי השם של NotebookLM ל-Gemini Notebook. במסגרת העדכון, ה-user-agent הישן Google-NotebookLM ממשיך לקבל תמיכה לתקופת מעבר, אבל בעלי אתרים שהתבססו עליו בכללי חסימה קשיחים צריכים לעדכן את ההגדרות שלהם ל-user-agent החדש: Google-GeminiNotebook.

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

למה זה חשוב לבעלי אתרים בישראל?

הרבה עסקים משקיעים היום בתוכן מקצועי: מדריכים, סקירות, השוואות, FAQ, מאמרי עומק ודפי שירות שנכתבו כדי להוכיח מומחיות. בעולם של AEO ו-GEO, התוכן הזה יכול להפוך לנכס חזק מאוד, כי מערכות AI מחפשות תשובות ברורות, מקוריות ומובנות.

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

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

robots.txt לבד לא מספיק כאן

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

במילים פשוטות: אם בניתם רק קובץ robots.txt, ייתכן שהוא לא המקום שבו תיפתר הבעיה. במקרים שבהם רוצים למנוע גישה בפועל, צריך לבדוק שכבות כמו WAF, Cloudflare rules, חוקי שרת או .htaccess, בהתאם לסביבת האחסון.

איך אנחנו רואים את השינוי?

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

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

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

מה כדאי לבדוק עכשיו?

הצעד הראשון הוא להבין אם בכלל יש לכם כללי חסימה קיימים שמתייחסים ל-NotebookLM. בהרבה אתרים אין כלום, ואז אין מה “לעדכן”, אלא צריך להחליט אם בכלל רוצים חסימה. באתרים שכן הטמיעו כללים, חשוב לבדוק אם הם משתמשים בשם הישן בלבד.

דוגמה לכלל טכני שדורש בדיקה

אם האתר שלכם רץ על Apache ויש לכם מדיניות לחסום את ה-fetcher הזה, כלל ברמת .htaccess יכול להיראות כך. חשוב להתאים אותו לאחסון ולבדוק בסביבת staging או בשעה שבה הסיכון נמוך:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Google-GeminiNotebook [NC]
RewriteRule ^ - [F,L]

באתרים שעובדים מאחורי Cloudflare, בהרבה מקרים עדיף לנהל את זה ב-WAF rule ולא בקובץ שרת. כך אפשר למדוד, להפעיל מצב challenge או לחסום רק אזורים מסוימים באתר.

איך מאזנים בין הגנה לנראות ב-AI?

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

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

טעויות נפוצות סביב הגנה על תוכן AI

הטעות הראשונה: להניח ש-robots.txt חוסם הכול. הוא חשוב, אבל הוא לא תמיד אכיפה בפועל.

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

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

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

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

מקורות

המאמר הזה מבוסס על מקור התור שסופק לאוטומציה: Search Engine Journal, Google NotebookLM Rebrand May Expose Your Site To More AI Scraping.

שאלות נפוצות

האם צריך לחסום את Gemini Notebook?

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

האם robots.txt מונע שימוש בתוכן על ידי כלי AI?

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

מה ההבדל בין Google-NotebookLM לבין Google-GeminiNotebook?

לפי הדיווח, מדובר בשינוי שם של NotebookLM ל-Gemini Notebook, עם user-agent חדש. השם הישן אמור להמשיך לקבל תמיכה לתקופת מעבר עד אוגוסט 2026.

האם כדאי לחסום גם את Googlebot?

בדרך כלל לא. Googlebot אחראי לאינדוקס אורגני רגיל, וחסימה שלו יכולה לפגוע בדירוגים. צריך להבחין בין crawler של חיפוש לבין fetcher שמופעל על ידי מוצר ספציפי.

איך יודעים אם האתר שלי חשוף לשימוש כזה?

בודקים לוגים, WAF, קבצי שרת, robots.txt וכללי cache/security. אם אין לכם גישה ללוגים, אפשר להתחיל ממיפוי תוכן: אילו עמודים פתוחים, אילו עמודים רגישים, ואילו עמודים צריכים להופיע בתשובות AI.

סיכום

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