מדוע תגי מטא של Open Graph שוברים תצוגות מקדימות במסנג'רים
לרוב הבעיה אינה ברשת החברתית, אלא בסימון של הדף. המסנג'ר או הפלטפורמה החברתית מבקשים את הדף, קוראים את תגי המטא של Open Graph ובונים תצוגה מקדימה של הקישור — כרטיס עם תמונה, כותרת ותיאור.
אם התגים אינם מוגשים בצד השרת, אלא מוזרקים על ידי סקריפט רק לאחר הטעינה, הרובוט של הפלטפורמה פשוט אינו רואה אותם: הוא אינו מריץ קוד צד לקוח ומקבל שלד ריק. אז נשלח לצ'אט קישור חשוף ללא תמונה — והקליק עליו נכשל, כי לנמען אין במה להיאחז בעין.
הסיבה השנייה בשכיחותה — og:image אינו מוצג בגלל שהתמונה חסומה לבקשות חיצוניות, מוגשת בנתיב יחסי או נמצאת בדומיין שהרובוט של הפלטפורמה אינו יכול להגיע אליו.
לפעמים מפריע ההגשה: הקובץ מוגש עם סוג שהפלטפורמה אינה מחשיבה כתמונה, או שהגודל והפרופורציות אינם עומדים בדרישות שלה — התצוגה המקדימה או שאינה נבנית, או שנחתכת כך שבכרטיס נראית חצי מהלוגו.
בנפרד יש להתייחס למטמון התצוגה המקדימה: הפלטפורמות שומרות את הכרטיס הבנוי אצלן ואינן קוראות מחדש את הדף בכל בקשה. תיקון התגים ללא איפוס המטמון נראה כמו "שום דבר לא השתנה", אף שבשרת כבר הכול תקין.
המחיר של הטעות אינו קוסמטי. הכרטיס במסנג'ר הוא המגע הראשון עם המותג לפני המעבר לאתר: בלעדיו הקישור בהתכתבות נראה כמו ספאם, שיעור המעברים יורד, ובמודעות ובניוזלטרים הולך לאיבוד חלק מהתקציב לגיוס.
בהמשך נפרק כיצד זה נסגר: אילו תגים הם חובה, כיצד להגיש אותם כך שהרובוט של הפלטפורמה יראה אותם, וכיצד לבדוק את התוצאה לפני הפרסום.
מה נותנת סימון נכון של Open Graph ו-Twitter Card
סימון נכון של Open Graph ו-Twitter Card קובע מה יראה האדם כאשר קישור לאתר שלכם יודבק במסנג'ר, ברשת חברתית או ברשת מקצועית. בלי זה הפלטפורמה עצמה מחליטה איזה כותרת ותמונה להציג: לעתים קרובות היא שולפת לוגו אקראי, חותכת את התמונה בקצה מקרי או לוקחת תיאור מטקסט שירותי. הכרטיס נראה גולמי, והמשתמש ממשיך לגלול הלאה בלי ללחוץ על הקישור.
עם הסימון כל פלטפורמה מקבלת סט מוכן: כותרת, תיאור, תמונה בפורמט הנדרש וסוג תוכן. Twitter Card מגדיר תרחיש נפרד לתצוגה מקדימה גדולה, ו-Open Graph מכסה את שאר המקורות.
כתוצאה מכך אותו קישור נפתח לאותה צורת כרטיס בכל מקום — מצ'אט עבודה ועד פיד ברשת חברתית, בלי עריכה ידנית לכל פלטפורמה.
האפקט מדיד בשני כיוונים. הראשון — שיעור הקלקות מרשתות חברתיות: תצוגה מקדימה מסודרת עם כותרת ברורה ותמונה אוספת noticeably יותר מעברים מאשר קטע אקראי מהעמוד, כי האדם מבין לאן מוביל הקישור עוד לפני הלחיצה.
השני — עבודה ידנית שנחסכת: יצירה אוטומטית של תצוגה מקדימה מתבנית מסירה את הצורך להכין תמונה ותיאור לכל חומר באופן ידני.
בנפרד זה מסיר סוג של שגיאות שמתגלות לא מיד. קישור שנשלח למסנג'ר נשמר במטמון של הפלטפורמה — ואם הסימון לא היה קיים, הכרטיס המתוקן יופיע לא אצל כולם ולא מיד. כאשר תגי המטא מוגדרים ברמת תבנית העמוד, כל פרסום חדש מקבל תצוגה מקדימה תקינה באופן אוטומטי, ולא לפי הזיכרון של העורך.
דרכים להגדיר תגי מטא: השוואת גישות
הבחירה של הדרך להגדיר תגי מטא של Open Graph קובעת עד כמה צפויה תיראה כרטיסיית העמוד ברשתות החברתיות ובאפליקציות המסרים.
בדף נחיתה סטטי די בסימון ידני בתבנית, ואילו בקטלוג עם אלפי עמודים אותה גישה בדיוק הופכת למקור לאי-התאמות: כותרות משוכפלות, תמונות מוצגות בפורמט הלא נכון, ומדורים חדשים עולים לאוויר בלי סימון כלל.
בפועל משלבים בין הגישות: את מערך התגים הבסיסי מגדירים בתבנית, ואת החלקים המשתנים — כותרת, תיאור, תמונה — מכניסים מתוך נתוני העמוד. להלן השוואה בין שלוש אפשרויות, שביניהן בוחרים בדרך כלל.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סימון ידני בתבנית | עמודים סטטיים, דפי נחיתה, בודדים במספרם | עריכות רק דרך מפתח, עם גידול מספר העמודים מופיעות אי-התאמות ותגים נשכחים |
| סימון דרך מערכת ניהול תוכן | עורכים מנהלים את העמודים בעצמם, נדרש שליטה על טקסט הכרטיסייה | דורש שדות לכל תג וולידציה, קל לקבל תיאור ריק או תמונה במידה הלא נכונה |
| יצירה דינמית לפי סוג העמוד | קטלוגים, כרטיסי מוצר, מאמרים, אלפי כתובות מאותו סוג | נדרשים כללי הצבה וערכי גיבוי, אחרת על נתונים חלקיים הכרטיסייה נבנית עקום |
סימון ידני נותן שליטה מלאה, אך מתקשה להתרחב: כל שינוי עובר דרך שחרור גרסה. מערכת ניהול תוכן מסירה את העומס מהמפתח, אולם מעבירה את האחריות לאיכות הכרטיסייה לעורך — בלי בדיקות בצד השרת התגים נכנסים לסימון כמו שהם.
יצירה דינמית מכסה את הנפח: כותרת, תיאור ותמונה נבנים מנתוני העמוד לפי כללים, והתבנית מגדירה ערכי גיבוי למקרה שהשדה ריק.
האמין ביותר הוא השילוב: התבנית אחראית על התגים הקבועים, מערכת ניהול תוכן — על דריסות ידניות במקומות שדרוש בהם טקסט מיוחד, והיצירה — על סוגי עמודים המוניים. גישה כזו מסירה את העבודה הידנית בנפח ומשאירה לעורך שליטה ממוקדת.
כיצד אנו מיישמים תגיות: שלבי העבודה
תגיות תצוגה מקדימה הן לא "להוסיף כמה תגים לתבנית", אלא תהליך מנוהל: לכל עמוד יש את הישות שלו (מוצר, מאמר, קטגוריה), וכמה נכון היא מתוארת, כך תיראה הקישור במסרים, ברשתות החברתיות ובתוצאות החיפוש. להלן כיצד אנו מבצעים עבודה זו כך שהתוצאה תהיה ניתנת לשחזור ולא חד-פעמית.
- ביקורת מטא-תגים קיימים. אנו אוספים את כל סוגי העמודים, בודקים מה כבר מוחזר בתגיות, היכן הערכים משוכפלים, היכן הם מוזרקים אוטומטית מהכותרת, והיכן הם חסרים. בנפרד אנו בודקים עמודים עם תוכן דינמי ועימוד — שם לרוב נשברת תמונת התצוגה המקדימה.
- תכנון סכמת התגיות. אנו קובעים עבור כל סוג עמוד את מערך המאפיינים החובה: כותרת, תיאור, תמונה, סוג האובייקט, כתובת קנונית. אנו מגדירים אילו ערכים נלקחים ממסד הנתונים, אילו מוגדרים ידנית, וכיצד התגיות מתנהגות בהיעדר נתונים.
- הכנת תמונות תצוגה מקדימה. אנו קובעים פרופורציות אחידות ודרישות לתוכן התמונה, כדי שהיא לא תיחתך בפלטפורמות שונות. עבור מוצרים וכרטיסים אנו מזריקים תמונה מהקטלוג, ועבור שאר העמודים — תבנית עם הזרקת הכותרת.
- הטמעה בתבניות והצגת נתונים. את הכללים אנו רושמים ברמת התבניות והמודלים, ולא בעמודים בודדים: ישות חדשה מקבלת תגיות תקינות אוטומטית, ללא עריכה ידנית. זהו ההבדל המרכזי מתיקונים "ממוקדים" שמתפוררים ב-release הבא.
- בדיקת תצוגה מקדימה בפלטפורמות אמיתיות. אנו מריצים קישורים דרך כלי דיבאג ופרסומים חיים: מסרים, רשתות חברתיות, ערוצים מקצועיים. אנו בודקים לא רק את תקינותם, אלא גם באיזו תדירות הפלטפורמה מושכת נתונים מעודכנים במקום נתונים מהמטמון.
- נוהל עדכון. אנו מוסרים מסמך: אילו שדות הם חובה בעת הוספת סוג עמוד חדש, מי אחראי על התמונות, כיצד לבדוק שינויים לפני release. בלי זה התגיות מתדרדרות כבר לאחר כמה איטרציות פיתוח.
בסיום הלקוח מקבל לא סט תגים, אלא מנגנון עובד: התגיות מתעדכנות יחד עם התוכן, ותצוגת הקישורים נשארת צפויה בכל הפלטפורמות.
מה הלקוח מקבל לידיו
בסיום העבודה — לא "תיקנו משהו בקוד", אלא ערכה שלמה שלצוות שלכם יהיה אפשר להמשיך איתה הלאה בלעדינו. כל מה שקשור ל-Open Graph מטא-תגים מועבר כקבצים עובדים וכללים, ולא כהסברים בעל פה.
- תבניות מטא-תגים — בלוקים מוכנים לכל סוג עמוד: מוצר, מאמר, קטגוריה, כרטיס שירות, דף נחיתה. התבנית מכניסה את הכותרת, התיאור והתמונה מהשדות של העמוד, כך שהעורך לא ממלא את הסימון ביד ולא שובר אותו.
- מפת סוגי עמודים — טבלה שבה לכל תבנית מצוין אילו שדות חובה, מאיפה נלקחת התמונה ואיזה גודל תצוגה מקדימה לצפות. לפיה רואים מיד מה יקרה לכרטיס בעת הוספת עמוד חדש.
- ערכת תמונות תצוגה מקדימה — וריאנטים מוכנים לסוגי תוכן שונים ולחיתוך בפידים: מרובע ורחב. בנוסף כללים כיצד מקור אחד מפיק פריים תקין ללא דחיסה יתרה.
- תיעוד — תיאור קצר: איזה תג אחראי למה, כיצד לבדוק את התוצאה לפני פרסום, מה לעשות בעת שינוי עיצוב או דומיין.
- נוהל עדכון — סדר הפעולות בעת מיתוג מחדש, החלפת תבנית או עריכה גורפת של כותרות: מי מבצע את השינוי, היכן הוא נבדק וכיצד מבטלים אותו.
- ולידציה מוגדרת — בדיקת הסימון מוטמעת בתהליך הפרסום, כך שכרטיס שבור לא עולה לפיד בלי ששמים לב.
בנפרד מתעדים נקודות שבהן הסימון קשור למערכות אחרות — מחולל העמודים, מערכת ניהול התוכן, המטמון. אם קיים קשר, הוא מתואר בתיעוד: בשינוי הבא של האתר אף אחד לא מנחש למה התצוגה המקדימה הפסיקה להתעדכן.
מקרה בוחן: איך תצוגות מקדימות הפסיקו להישבר בכל הפלטפורמות
הלקוח — רשת מרכזי שירות — התלונן שקישורים למאמרים בבלוג במסנג'רים וברשתות החברתיות נפתחו כטקסט חשוף: בלי תמונה, בלי כותרת, ולפעמים עם תיאור של מישהו אחר. מנהל התוכן בדק בכל פעם לאחר הפרסום ידנית את התצוגה המקדימה בארבעה ערוצים ותיקן אם משהו הוצג לא נכון. על הבדיקה נדרשו 20-30 דקות לחומר, ובעת עדכון המאמר הכרטיס мог "להישבר" מחדש.
מה היה לפני
הסימון נבנה באופן ספונטני: חלק מהדפים החזירו רק כותרת בסיסית, חלק — תמונה בלי ציון מידות, ולחלק מהחומרים בכלל לא היו תגיות לרשתות חברתיות.
הפלטפורמות השלימו את התצוגה המקדימה בדרכן: במקום כלשהו הציבו את הלוגו של האתר במקום תמונת השער, במקום אחר קיצרו את הכותרת, ובמקום נוסף שמרו בגרסה מטמון של גרסה ישנה ולא עדכנו אותה לאחר תיקונים. לא היה אפשר לאתר את הסיבה בלי בדיקה ידנית של כל ערוץ.
מה שינו
תיארנו תבנית אחידה של תגיות מטא לכל סוגי הדפים — מאמרים, כרטיסי שירותים, מדורי קטלוג — והוצאנו אותה לשכבה משותפת של סימון, כך שמנהל התוכן ממלא רק כותרת, תיאור ותמונת שער. עבור תמונות הגדרנו פרופורציות קבועות ותמונה חלופית למקרה שתמונת השער לא נטענה.
בנפרד כתבנו כללים לפלטפורמות שקוראות את הסימון בדרכים שונות, והוספנו בדיקת תגיות לשלב הבנייה: דף בלי שדות חובה פשוט לא עובר פרסום.
מה נהיה
התצוגות המקדימות הפסיקו להישבר: שיעור הכרטיסים המוצגים כראוי עלה מכ-60% ל-98%, והתיקונים הידניים יצאו מהתהליך לחלוטין. הזמן לפרסום חומר התקצר מחצי שעה לכמה דקות, ומנהל התוכן הפסיק להחזיק בראש רשימת פלטפורמות לבדיקה. בעת עדכון המאמר הכרטיס מושך את הגרסה החדשה בלי התערבות מפתח.
את הפרויקט הוביל המהנדס שלנו, שאחראי על הסימון והבנייה. מקרה בוחן דומה עשינו עבור פורטל מדיה על WordPress — שם הבעיה הייתה זהה: הסימון חי בתבנית הערכה ולא כיסה סוגי רשומות חדשים.
במה שונה Open Graph מ-Twitter Card?
Open Graph הוא תקן שהוגדר במקור על ידי Facebook, וכיום כמעט כל הפלטפורמות הגדולות קוראות אותו: אפליקציות מסרים, רשתות חברתיות, אגרגטורי קישורים. Twitter Card הוא מפרט נפרד, שצמח מצרכי Twitter, עם סט מאפיינים משלו והתנהגות משלו בעת ניתוח הדף.
ההבדלים בין התקנים אינם באידיאולוגיה, אלא באילו תגים כל פלטפורמה מביאה בחשבון באופן מובטח וכיצד היא בונה תצוגה מקדימה אם המאפיין הנדרש חסר.
ההבדל הטכני המרכזי הוא עדיפות התגים וכללי הנסיגה לאחור. Open Graph מתאר את האובייקט בשלמותו: סוג, כותרת, תיאור, תמונה, כתובת, שם האתר. Twitter Card נשען במידה רבה על אותם נתונים, ובהיעדר מאפיינים משלו מציב ערכים מ-Open Graph.
אך אם שני הסטים מוגדרים, הפלטפורמה נותנת עדיפות לתגים שלה — לכן חוסר סנכרון ביניהם מניב תצוגה מקדימה שונה בפלטפורמות שונות עבור אותו קישור.
בפועל זה נראה כך: כרטיס באפליקציית מסרים מציג כותרת ותמונה אחת, ובפרסום ברשת אחרת נמשך מטמון מיושן או תמונה חתוכה. הסיבה כמעט תמיד אחת — חלק מהמאפיינים מוגדרים רק בתקן אחד, והמידות והפרופורציות של התמונה אינן תואמות את ציפיות הפלטפורמה.
כאב ראש נפרד הוא דפים דינמיים, שבהם תגי מטא נוצרים בצד האפליקציה: בעת כשל ברינדור הסורק רואה תבנית ריקה ובונה תצוגה מקדימה ללא תמונה.
מתי נדרשים שני הסטים? אם הקישור יופץ דרך מספר ערוצים — כן, כמעט תמיד. Open Graph מכסה את התרחיש העיקרי, Twitter Card מדייק את ההתנהגות של פלטפורמה מסוימת ומסיר אי-התאמות.
אנחנו מגדירים את שני התקנים באופן מתואם, קובעים מידות תמונה מפורשות בהתאם לדרישות הפלטפורמות ובודקים את התוצאה על סורקים אמיתיים, ולא רק בכלי דיבוג. זה מסיר סוג שלם של שגיאות, שבהן התצוגה המקדימה נראית תקינה אצל המפתח ונשברת אצל מקבל הקישור.
בנפרד כדאי לזכור את המטמון: פלטפורמות שומרות את המטא-נתונים שנותחו ואינן קוראות אותם מחדש באופן מיידי לאחר עריכה. לכן בודקים את התגים לפני הפרסום, ולא אחריו — אחרת תיקון אי-ההתאמה בין התקנים יימשך ימים של המתנה לרענון המטמון.
ספקות טכניים נפוצות
תצוגה מקדימה במסנג'רים וברשתות חברתיות נשמרת במטמון בצד הפלטפורמה: לאחר עריכת הכותרת או התמונה, הגרסה הישנה עשויה להופיע עוד יממה ויותר.
זה לא מטופל ב"המתנה", אלא ברענון כפוי דרך לוחות הדיבאג של הפלטפורמות ובשינוי כתובת התמונה — הצמדה לשם קובץ חדש מאפסת את מטמון התצוגה המקדימה באופן מובטח.
התנגשות תגים היא הסיבה הנפוצה השנייה לתצוגה מקדימה "ריקה". אם בעמוד קיימים בו-זמנית שני מערכי סימון (למשל, מהתבנית ומהמודול), הפלטפורמה לוקחת את הראשון שנתקלת בו ומציגה לא את מה שצריך.
אנחנו מפשטים את הסימון למקור יחיד ובודקים את סדרי העדיפויות בכל סוגי העמודים — כרטיס מוצר, מאמר, קטגוריה, עמוד הבית.
מה יקרה אם התמונה לתצוגה המקדימה תהיה גדולה מדי או קטנה מדי?
פלטפורמות חותכות או מתעלמות מתמונות מחוץ ליחס הרוחב-גובה המומלץ. אנחנו מכינים תצוגה מקדימה ביחס 1.91:1, עם שוליים לחיתוך וגרסה מרובעת נפרדת למסנג'רים — כך הכרטיס נראה תקין בכל פיד.
כמה מהר תתעדכן התצוגה המקדימה לאחר פרסום תוכן חדש?
בסימון תקין — מיד עם הבקשה הראשונה של הפלטפורמה לעמוד. אם התצוגה המקדימה "נתקעה", אנחנו מריצים את הכתובת דרך כלי דיבאג, ובמידת הצורך משנים את שם קובץ התמונה: מטמון התצוגה המקדימה מתאפס, ובפיד מופיע הכרטיס המעודכן.
האם אפשר להגדיר תצוגה מקדימה שונה לאותו עמוד ברשתות חברתיות שונות?
כן. מערך Open Graph בסיסי מכסה את רוב הפלטפורמות, ותגים נפרדים לכרטיסי Twitter ו-Telegram מאפשרים לכוונן בדיוק את מראה הקישור. אנחנו בודקים שמערכים אלה לא מתנגשים ביניהם ולא חופפים זה לזה.
כל הספקות לעיל — מהפרקטיקה: אנחנו מגדירים את הסימון כך שהתצוגה המקדימה תהיה צפויה בעת פרסום, עדכון ושינוי עיצוב העמוד.
נדון במשימה שלכם בנוגע לתגי מטא
כדי שהשיחה תהיה עניינית ולא "ספרו בשתי מילים", לפני השיחה הראשונה מספיק לאסוף מינימום: כתובות העמודים שבהם התצוגות המקדימות כרגע עקומות, ודוגמאות לאיך הן נראות במסנג'רים וברשתות החברתיות. זה מספיק כדי להבין את ההיקף ולחזור עם הערכה ותוכנית, ולא עם מילים כלליות.
מה כדאי להכין מראש:
- רשימת עמודים או תבניות שעבורם חשובות תצוגות מקדימות תקינות (עמוד הבית, כרטיסי מוצרים, מאמרים, דפי נחיתה של קמפיינים);
- צילומי מסך של המראה הנוכחי של הקישורים בעת שליחה למסנג'ר או פרסום — כך רואים היכן נטען הכותרת הלא נכונה או תמונה ריקה;
- גישה למאגר הקוד או לתבניות שבהן מוצגים תגי המטא, ולפאנל הניהול של האתר;
- דרישות לתמונות התצוגה המקדימה: יחס גובה-רוחב, מה צריך להיות בתמונה, האם יש לוגו וטקסט;
- רשימת סוגי העמודים שנוצרים אוטומטית — עבורם התגים מוצגים לפי תבנית, ולא ידנית;
- העדפות לגבי לוחות זמנים ולגבי מי בצד שלכם מאשר את התוצאה.
בהמשך אנחנו משווים זאת מול הסימון הנוכחי, בודקים איך התגים מוחזרים עבור סוגי עמודים שונים, ומקבעים מה בדיוק משנים: ערכי ברירת מחדל, תבניות לכרטיסים, תמונות תצוגה מקדימה.
בסופו של דבר אתם מקבלים הערכה לפי היקף העבודה, תוכנית תיקונים לפי תבניות ולוחות זמנים, וכן פורמט עבודה — שינויים חד-פעמיים או תמיכה עם בדיקת תצוגות מקדימות לאחר כל שחרור.
תארו את המשימה בצורה נוחה לכם: בקישורים, בצילומי מסך או ברשימה קצרה של עמודים. נחזור עם הערכה, תוכנית ולוחות זמנים — ונאמר מיד היכן מספיק תיקון תבנית והיכן נדרשת לוגיקת הצגה נפרדת.
