Google UGC Fresh Data Program היא ערוץ נפרד לשליחת נתונים עבור פלטפורמות מאושרות שמארחות כמויות גדולות של תוכן ציבורי שנוצר בידי משתמשים ומקושר ליוצרים שלו. התוכנית מיועדת לפוסטים חברתיים טריים ופופולריים ולדיונים בפורומים, ולא לדפי אינטרנט רגילים. Google מציינת שהתוכנית נפרדת מסריקה אורגנית מסורתית ומ־Indexing API. ההשתתפות אינה מבטיחה שדף יופיע בחיפוש.
אם אתם מפעילים פורום, קהילה או פלטפורמה חברתית, השתמשו בבדיקות הבאות כדי להחליט אם כדאי להכין בקשה. אם אתם מנהלים בלוג חברה רגיל או אתר תדמית, התמקדו בנגישות לסריקה, בקישורים פנימיים ובמפות אתר.
תחילה בחרו את המסלול המתאים של Google
שלושת המנגנונים האלה פותרים בעיות שונות. תוכנית UGC מספקת צינור נתונים ייעודי לפלטפורמות שעומדות בתנאים; שני המסלולים האחרים נשארים הדרכים המקובלות לתוכן אינטרנט כללי ולסוג מצומצם של דפים רגישים לזמן.
מסלול | שימוש מיועד | מה זה אומר לצוות שלכם |
|---|---|---|
סריקה אורגנית | Google מגלה וסורקת דפי אינטרנט מתאימים ברשת הפתוחה | ודאו שהדפים נגישים וניתנים לאינדוקס, והוסיפו קישורים ברורים ומפת אתר. אין הבטחה לגילוי או לאינדוקס. |
Indexing API | דפים שמכילים | השתמשו ב־API רק לסוגי הדפים הנתמכים. הודעה מאפשרת ל־Google לתזמן סריקה; זה אינו API כללי לאינדוקס מהיר. |
UGC Fresh Data Program | פלטפורמות מאושרות עם פוסטים פופולריים של משתמשים ואותות אינטראקציה | הגישו בקשה לגישה לצינור קליטת נתונים נפרד. לאחר האישור, Google מעבירה לפלטפורמות שנבחרו את פרטי השילוב. |
Google פרסמה את התיעוד לתוכנית ב־8 באוקטובר 2026. התיעוד מבהיר שהתוכנית נפרדת מסריקה אורגנית רגילה ומ־Indexing API. חשוב להבין את ההבדל: הוספת נתונים מובְנים או קריאה ל־Indexing API אינן מצרפות אתר לתוכנית UGC.
בדקו את תנאי הסף לפני הכנת הבקשה
התייחסו לתנאים האלה כשער זכאות, לא כמערכת ניקוד. Google מפרסמת את הקריטריונים, אך אינה מציינת סף מספרי של תנועה, נפח פוסטים או משתמשים פעילים. אל תמציאו סף ואל תניחו שקהל גדול לבדו מספיק.
1. ודאו שפוסטים של משתמשים הם לב המוצר
הפלטפורמה צריכה לארח בעיקר תוכן שהמשתמשים יוצרים בעצמם, כגון פוסטים חברתיים או דיונים בפורום. בלוג חברה עם תגובות, אתר עריכה של מו״ל או דף שמפרסם מחדש בעיקר חומרים ממקומות אחרים אינם התאמה חזקה.
תעדו את סוגי התוכן העיקריים בפלטפורמה ומי יוצר כל אחד מהם. הוסיפו כמה כתובות URL מייצגות. המטרה היא להראות שתוכן משתמשים הוא חלק מרכזי במוצר, ולא תכונה מזדמנת.
2. בדקו את מבנה הדף ואת הגישה הציבורית
לכל פוסט או דיון דרושה כתובת URL יציבה משלו. דף פרופיל או פיד גלילה אינם תחליף לדף נפרד לכל פריט. הדף חייב להיות נגיש לציבור ול־Googlebot; לפי הקריטריונים שפורסמו, תוכן מאחורי כניסה לחשבון, חומת תשלום או מגבלת גישה אחרת אינו זכאי.
פתחו כתובות URL לדוגמה בדפדפן לאחר התנתקות ובדקו אם כללי robots או הוראות ברמת הדף חוסמים את Googlebot. ודאו שהכתובת מחזירה תגובה תקינה ושהפוסט עצמו גלוי ללא חשבון. אם אפשר לקרוא אותו רק באפליקציה או במושב של חבר, פתרו זאת לפני ההגשה.
3. אמתו שיוך ליוצר, ניהול תוכן ודיווח
כל פריט תוכן משתמשים צריך להיות משויך ליוצר שלו, עם פרופיל ציבורי. הפלטפורמה זקוקה גם לניהול תוכן פעיל ולדרך שבה משתמשים יכולים לדווח על תוכן. Google אינה כוללת תוכן בלתי חוקי.
תעדו מי מטפל בדיווחים, איך משתמשים שולחים אותם ומה קורה לאחר מכן. אם התהליך מסתכם בתיבת תמיכה לא רשמית, הפכו אותו לברור ושימושי לפני שתתארו את הפלטפורמה כמי שיש לה מנגנון דיווח.
4. בדקו נתונים מובְנים ואימות זהות
Google מצפה לסימון Schema.org תקין בכתובות הרלוונטיות. הדוגמאות כוללות SocialMediaPosting ו־DiscussionForumPosting, ובמקרה של נתוני מעורבות גם interactionStatistic. אמתו דפי פוסטים אמיתיים ולא רק תבנית בסביבת בדיקה, וודאו שהסימון מתאר את מה שהמשתמש רואה בדף.
השילוב דורש גם אימות API מאובטח באמצעות OAuth 2.0. לפני ההגשה, קבעו איזו קבוצה תהיה אחראית להרשאות, להעברת הנתונים ולבדיקות גישה. Google משתפת תיעוד מפתחים מפורט לאחר האישור, לכן אל תתכננו שילוב על סמך נקודות קצה שלא תועדו ואל תנחשו את מבנה המטען.
5. בדקו אם תפעול הנתונים הטריים מעשי
Google ממליצה לשלוח תוכן חדש בתוך דקות מרגע יצירתו, אם הדבר אפשרי. יש לשלוח עדכונים למוני המעורבות באופן קבוע ולא יאוחר מ־72 שעות לאחר יצירת הפוסט. אלה ציפיות תפעוליות, ולכן השוו אותן לתהליכי הפרסום והאירועים בפועל.
מדדו את הזמן שעובר מיצירת פוסט עד שהאירוע זמין באופן אמין. לאחר מכן בדקו כיצד מתעדכנים לייקים, תגובות וספירות אינטראקציה אחרות. אם הנתונים מועברים בייצוא יומי או שהספירות מתעכבות בקביעות בכמה ימים, תעדו את הפער והעריכו את העבודה הדרושה לסגירתו לפני ההגשה.
השתמשו בארבעת השערים האלה כדי להחליט אם להכין בקשה, לתקן פערים או להסתמך על סריקה רגילה.
הכינו תיק ראיות קצר למוכנות
חבילת ראיות ממוקדת מקלה על מילוי הבקשה וחושפת פערים מוקדם. השתמשו בעובדות ובכתובות URL ציבוריות לדוגמה ככל האפשר.
- תיאור הפלטפורמה: מה המשתמשים מפרסמים, למה זה תוכן משתמשים ומה היקף הפרסום הפעיל והקהל בקירוב. ציינו הערכות פנימיות; Google לא פרסמה סף מינימום.
- דפים לדוגמה: כמה כתובות URL יציבות עבור פורמטי התוכן העיקריים, שנבדקו לאחר התנתקות.
- גישה ושיוך: גישה של Googlebot, פרופילים ציבוריים של יוצרים והקשר בין כל פוסט ליוצר שלו.
- תהליכי בטיחות: האחראים לניהול התוכן, מסלול הדיווח למשתמשים ותיאור תמציתי של הטיפול בדיווחים.
- ראיות טכניות: JSON-LD שעבר רינדור, תוצאות אימות והצוות שאחראי ל־OAuth 2.0 ולאבטחת השילוב.
- ראיות לעדכניות: הזמן שנמדד מיצירת התוכן עד למסירתו, ותדירות עדכון מוני המעורבות.
אל תשלחו נתונים אישיים של משתמשים במקום הסיכום הזה. דף הזכאות הציבורי מפרט את הדרישות; מפרטי קליטת הנתונים המלאים נמסרים לאחר האישור.
הגישו בקשה דרך דף התוכנית הרשמי של Google
לאחר שהבדיקות העיקריות עוברות, השתמשו בטופס ההתעניינות המקושר מתוך התיעוד של Google על UGC Fresh Data Program. תארו את הפלטפורמה בפשטות והתאימו את הראיות לקריטריונים. הימנעו מטענות כמו «כל התוכן ניתן לאינדוקס» או «הכללה מיידית»; התוכנית אינה מבטיחה נראות בחיפוש.
Google אומרת שמועמדים צריכים לצפות לתשובה בתוך שישה עד שמונה שבועות. אם הפלטפורמה תיבחר, היא תקבל תיעוד טכני לשילוב והנחיות להצטרפות. עד אז, המשיכו לתמוך בגילוי ובסריקה הרגילים של הדפים. הגשת הבקשה אינה מחליפה מפת אתר או SEO טכני תקין.
אמתו את ההחלטה ושמרו על מסלול הסריקה הרגיל
לפני השליחה, בקשו מעמית לבדוק את התיק ולענות «כן» על כל דרישה שפורסמה: תוכן משתמשים הוא המטרה העיקרית של הפלטפורמה; לפריטים יש כתובות URL ציבוריות ויציבות; ניתן לזהות את היוצרים; ניהול התוכן והדיווח פועלים; הנתונים המובְנים תקינים; מונה אחראי ל־OAuth 2.0; והצוות יכול לעמוד בציפיות העדכניות.
אם תנאי כלשהו חסר, מנו אחראי וחזרו לבקשה לאחר התיקון. אם המוצר אינו מתאים, פעלו לפי הדרישות הטכניות הרגילות של Google: אפשרו ל־Googlebot לגשת לדף, החזירו תגובת HTTP תקינה ודאגו שהתוכן יהיה ניתן לאינדוקס. הוסיפו קישורים שעוזרים לגלות את הדפים ומפת אתר, ואז השתמשו בבדיקת URL ובדוחות האינדוקס של Search Console כדי לבדוק כתובות ספציפיות ואת הכיסוי הכללי. הבדיקות מסייעות באבחון, אך אינן מבטיחות אינדוקס.
שאלות של צוותי פלטפורמה
האם הוספת הסימון `DiscussionForumPosting` הופכת את האתר לזכאי? לא. נתונים מובְנים תקינים הם רק דרישה אחת מתוך כמה. הם אינם מעניקים לבדם גישה לצינור הייעודי.
האם כל אתר יכול להגיש בקשה? הקריטריונים שפורסמו מיועדים לפלטפורמות שמארחות בעיקר תוכן משתמשים שנוצר באופן עצמאי ובהיקף גדול, עם דפים ציבוריים נפרדים ותהליכי בטיחות וטכנולוגיה נדרשים. Google אינה מפרסמת סף מספרי אחיד.
האם האישור מבטיח אינדוקס או דירוג? לא. Google מציינת במפורש שההשתתפות אינה מבטיחה שהתוכן יופיע בחיפוש.
האם בלוג רגיל צריך להשתמש ב־Indexing API במקום זאת? רק אם הדפים שלו מתאימים למקרי השימוש הנתמכים של JobPosting או BroadcastEvent לשידור חי. עבור דפים אחרים, שמרו על גישה רגילה לסריקה ועל כיסוי במפת האתר.
Martin Hayes כותב מדריכים מעשיים שלב אחר שלב ורשימות בדיקה תפעוליות לצוותי SEO וצמיחה.
