שיווק דיגיטלי
unavailable_after בגוגל: מה קורה כשאף אחד לא יודע מתי לשנות את התאריך
גארי אילייס לא בטוח מתי לשנות תאריכי unavailable_after. מה זה אומר לאינדוקס שלך ואיך להגן על תוכן עם תאריך תפוגה. קראו עכשיו.
תקציר
תג unavailable_after אמור לאותת לגוגל להוציא דף מהאינדקס בתאריך מוגדר מראש. גארי אילייס, Search Advocate של גוגל, הודה בפומבי שאינו בטוח כיצד גוגל מטפלת בשינוי רטרואקטיבי של אותו תאריך, מה שהופך את ההסתמכות עליו בלבד לסיכון אינדקסציה אקטיבי. תוכן עם מועד תפוגה שנסמך על המטה-תג הזה ללא שכבת הגנה נוספת עלול להיעלם מהאינדקס בזמן הלא נכון, או להישאר בו זמן ארוך מדי.
מה בדיוק עושה תג unavailable_after ואיך גוגל אמורה לפרש אותו
תג unavailable_after הוא מטה-תג HTTP שמאפשר לבעלי אתרים לקבוע תאריך מדויק שבו גוגל אמורה להפסיק לאנדקס דף מסוים ולהוציאו מתוצאות החיפוש. הלוגיקה מאחוריו ברורה, ומיועדת לתוכן שתוקפו פג בוודאות: מבצעים זמניים, אירועים חד-פעמיים ודפי נחיתה של קמפיינים.
על פי התיעוד הרשמי של גוגל, הפורמט הנכון כולל תאריך ב-RFC 850 או ISO 8601, לדוגמה <meta name="unavailable_after" content="2026-03-15T23:59:59Z">. בתיאוריה, ה-Googlebot אמור לבדוק את הערך בכל סריקה ולאחר חציית התאריך להוציא את הדף מהאינדקס ביזמה, מבלי שבעל האתר יצטרך להגיש בקשת deindex ידנית.
מה הכוונה ב"אמורה לפרש"
למה גארי אילייס אמר שהוא לא בטוח ומה המשמעות הטכנית של זה
בדיון פומבי נשאל גארי אילייס, Search Advocate של גוגל, שאלה ישירה: מה קורה אם בעל אתר שינה תאריך unavailable_after לאחר שהדף כבר נסרק עם הערך הקודם, ובמיוחד אם התאריך הוזז קדימה כך שהתוכן אמור "לחזור" לזמינות. תשובתו לא הייתה הכחשה ולא הבהרה טכנית; היא הייתה אי-ודאות מפורשת.
אילייס הודה שאינו בטוח כיצד המערכת מתייחסת לשינוי רטרואקטיבי של הערך, ושהנושא מצריך בדיקה מצד הצוות הטכני. זו לא תשובה ענווה בלבד: זוהי הודאה שהמדיניות הרשמית אינה מכסה את כל תרחישי השימוש הנפוצים.
מה המשמעות הטכנית של חוסר הוודאות הזה
unavailable_after מה-15 לינואר ל-15 למרץ 2026, אין מנגנון מוסמך שמבטיח שגוגל תרים את הדגל הנכון בפברואר. המערכת עשויה לשמור בזיכרונה הפנימי את הערך הישן, לסרוק מחדש רק שבועות לאחר מכן, או לפרש את הדף כ"פג תוקף" גם לאחר שהתאריך הוארך.האפקט ההפוך קיים גם הוא. אם הזזת תאריך אחורה, כלומר ביקשת מגוגל שהדף ייצא מהאינדקס מוקדם יותר ממה שהוגדר מלכתחילה, אין ודאות שגוגל תפעל לפי הגרסה המעודכנת בזמן אמת. הדף עשוי להישאר חי ולהמשיך לקבל קליקים על תוכן שאינו רלוונטי עוד, מה שפוגע בחוויית המשתמש ובציון האיכות של הדומיין.
Information Gain Capsule
רוב המדריכים הקיימים עוסקים בשאלה "איך מגדירים unavailable_after נכון", ואף אחד מהם אינו עוצר לשאול את השאלה הקריטית: מה קורה אחרי שמגדירים אותו ואז מחליטים לשנות. הודאתו של אילייס חושפת ש-gap זה אינו טכני בלבד: הוא תיעודי. גוגל לא פרסמה הנחיה רשמית לתרחיש שינוי-תאריך, מה שאומר שכל SEO שמסתמך על המטה-תג ככלי גמיש לניהול מחזור חיים של תוכן עושה זאת ללא רשת ביטחון. הסיכון כפול: תוכן שנשאר חי זמן ארוך מדי, ותוכן שנעלם מוקדם מדי, ושניהם בלי יכולת לחזות את העיתוי המדויק.
המסקנה המעשית: הניסיון שלנו מלמד ש-unavailable_after ראוי להיחשב כ-hint בלבד, לא כ-instruction. גוגל מתייחסת לרוב ה-meta signals ככאלה, ואילייס אישר בעקיפין שהמנגנון הזה אינו חריג לכלל.
אילו סוגי תוכן בסיכון הגבוה ביותר וכיצד לזהות אם הבעיה כבר פוגעת באינדקס שלך
לא כל תוכן עם תאריך תפוגה סובל מהבעיה באותה עוצמה. הסיכון הגבוה ביותר מרוכז בתוכן שיש לו מחזור חיים דינמי: תוכן שנוצר עם כוונה לשנות את מועד הסיום בהמשך.
תוכן בסיכון גבוה במיוחד
unavailable_after מעודכן, מדובר בדיוק בתרחיש שאילייס לא ידע לענות עליו.תוכן חינוכי עם גרסאות, כגון מדריכים שמתעדכנים מדי שנה. אם פרסמת "המלצות SEO לשנת 2025" עם unavailable_after לדצמבר 2025, ועכשיו יצאה גרסת 2026 אבל הישן אמור להישאר כ-archive עד מרץ 2026, לוח הזמנים של גוגל אינו מסונכרן עם ההחלטה הזו.
דפי אירועים ברמת event schema שלרוב משולבים עם unavailable_after ועם EventStatus markup. השילוב יוצר שכבות של סיגנלים שגוגל עשויה לפרש בדרכים סותרות.
כיצד לזהות אם הבעיה כבר קיימת אצלך
unavailable_after שעדיין לא עבר, גוגל ביצעה פרשנות עצמאית שאינה תואמת את ההגדרה שלכם.השלב השני הוא בדיקת crawl log. כלים כמו Screaming Frog עם log analysis מראים מתי גוגל סרקה לאחרונה כל דף עם unavailable_after. פער של יותר משבועיים בין שינוי התאריך לסריקה הבאה הוא איתות אדום שמצריך התערבות ידנית.
מה הפרוטוקול המעשי שמגן על תוכן עם תאריך תפוגה כשמדיניות גוגל עצמה לא ברורה
כשכלי רשמי אינו אמין בצורה שמתועדת, בונים שכבות הגנה. הכוונה אינה לזנוח את unavailable_after, אלא להפסיק לסמוך עליו לבדו.
- מגדירים
unavailable_afterכ-hint, לא כ-command.
מכניסים אותו לקוד, אבל לא מסתמכים עליו כמנגנון הבלעדי. הוא תורם לסריקה עתידית, ואינו מבטיח פעולה בזמן מוגדר. - מגבים עם noindex מתוזמן ידנית.
ביומן הצוות, מסמנים לוח זמנים של הוספת מטה-תגnoindexידנית שלושה ימים לפני תאריך התפוגה המתוכנן. כך גם אם גוגל מתעכבת בסריקה, הדף מקבל סיגנל כפול שקשה להתעלם ממנו. - מגישים בקשת URL Removal ב-GSC לתוכן בעדיפות גבוהה.
ה-URL Removal Tool ב-Search Console מסיר תוצאות זמנית תוך שעות. לתוכן רגיש כגון מחירים ישנים, תנאי מבצע שפגו או תאריכי אירוע שחלפו, זהו הכלי הנכון לשימוש, לאunavailable_after. - מיישמים 410 Gone במקום 404 לדפים שמוצאים לגמרי.
תגובת שרת 410 מאותתת לגוגל שהמשאב הוסר בכוונה ואינו צפוי לחזור. היא מעובדת מהר יותר מ-404 ומעדכנת את ה-crawl priority של הדומיין בצורה נקייה יותר. - מעדכנים Sitemap באופן אקטיבי.
מסירים URLs עם תאריך תפוגה שעבר מה-Sitemap ומגישים אותו מחדש ב-GSC. גוגל מתייחסת לאי-הכללה ב-Sitemap כסיגנל שדף פחות חשוב, מה שמאיץ ירידה בסריקה. - אם שינוי תאריך הוא הכרחי, מבצעים אותו ומיד מגישים את ה-URL ל-Fetch & Index ב-GSC.
כך גוגל מקבלת את הגרסה המעודכנת של התג בסמוך לשינוי, במקום להמתין שבועות לסריקה אורגנית.
שאלות נפוצות
האם unavailable_after עדיין שווה שימוש ב-2026?
מה קורה אם מועד התפוגה עבר ולא עשינו כלום?
האם יש הבדל בין unavailable_after ב-meta לבין X-Robots-Tag ב-HTTP header?
X-Robots-Tag עם ערך unavailable_after פועל באותה לוגיקה, אבל ברמת ה-HTTP response. ההבדל המעשי הוא שה-header מאפשר יישום גמיש יותר לפי סוג קובץ ולא לפי URL ספציפי. חוסר הוודאות שאילייס הביע חל על שני המנגנונים, שכן שניהם תלויים באותו מנוע פרשנות של ה-Googlebot.תוכן עם תאריך תפוגה הוא פצצת זמן שדורשת מערכת, לא השערות
אנחנו בונות ב-BusyMom פרוטוקולי GEO ו-SEO טכני שמתייחסים לאינדקס כמו נכס עסקי, לא כנגזרת של מדיניות שמשתנה. אם יש לך תוכן עם מועד תפוגה, קמפיינים מתחלפים, או אתר שנסמך על מטה-תגים ללא שכבת הגנה, בואו נדבר.
