Speakable Schema, מדריך לעידן voice search

🔊 מה זה Speakable schema (וההבדל מ-Article רגיל)

תקשיבו. אני אפתח עם הסיפור הקלאסי. לקוח מגיע אליי, אומר "שמוליק, אני רוצה שאם מישהו שואל את Google Assistant על הנושא שלי, הוא יקריא את האתר שלי". אני אומר לו, "אתה יודע שיש סכמה ייעודית בדיוק לזה?". הוא, "לא, מעולם לא שמעתי". אני, "זה נקרא Speakable. גוגל הציג אותו ב-2018, רבים שכחו ממנו כי הוא לא קיבל את כל הזרקורים של FAQ ו-HowTo, אבל הוא חי ובועט".

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

זה ההבדל המהותי מ-Article schema. Article אומר "זה מאמר". Speakable אומר "אם אתה הולך להקריא משהו מהמאמר הזה בקול, תקריא את הפסקאות האלה ספציפית". זה הבדל גדול. Article מתאר את התוכן. Speakable מנחה את ההצגה הקולית.

במאמר הזה, אני אעבור איתכם על כל מה שצריך לדעת על Speakable. מה ה-properties, איך משתמשים ב-cssSelector מול xpath, מה לסמן (וחשוב יותר, מה לא לסמן), איך זה משתלב עם Article ו-WebPage, איך גוגל מפרש את זה בפועל, ומה הקשר ל-AI engines החדשים. ואני אדבר גם על למה דווקא ב-2026 הסכמה הזאת חשובה יותר מתמיד, גם אם גוגל לא הפך אותה לפיצ'ר ויזואלי. שמוליק דורינבאום, נצא לדרך.

📣 למה זה חשוב לעידן voice (וזה לא רק Google Assistant)

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

הערוצים הקוליים שצריך לדבר עליהם

Google Assistant, עדיין הגדול ביותר במובייל אנדרואיד, ועדיין מבצע מיליארדי תשובות קוליות בחודש. Alexa, על מיליוני מכשירי Echo בבית, גם אם פחות מדוברת היום. Siri על אייפון, שעוברת רענון מקיף בעידן Apple Intelligence. ChatGPT Voice Mode, שמאפשר שיחה זורמת עם המודל. Gemini Live של Google, השיחה הקולית הטבעית של המודל. כל אלה צורכים תוכן ומחזירים אותו בקול.

למה Speakable הוא הסיגנל הכי ישיר

כי הוא אומר במפורש, "זה החלק שהכי מתאים להקראה". בלי Speakable, המנוע צריך לנחש. הוא קורא את כל ה-HTML, מנסה להבין מה מתאים, ולפעמים מקריא משפט באמצע פסקה שאיבד את ההקשר. עם Speakable, אתם מנחים אותו ישירות. "קריא את ה-summary. קריא את התשובה לשאלה הראשית. אל תקרא את ה-byline או את התאריך".

זה ההבדל בין לתת ל-AI לנחש, לבין להגיד לו בדיוק. ובעידן שבו תוכן קולי הופך לדומיננטי יותר, להיות הקול שמושמע בפועל, זה ה-real estate החדש.

🧩 ה-@type SpeakableSpecification, ‏cssSelector ו-xpath

schema.org מגדיר את הסכמה הזאת בשם הרשמי "SpeakableSpecification". זה ה-@type שאתם מצהירים עליו ב-JSON-LD, והוא מכיל בעיקר property אחד מרכזי שאומר לגוגל איפה למצוא את הטקסט להקראה. שני המנגנונים הם cssSelector ו-xpath, ושניהם תקפים, אבל יש העדפה ברורה.

cssSelector, המומלץ

זה ה-property שמשתמש בסלקטור CSS רגיל כמו שאתם מכירים מ-styling. למשל, ".article-summary", "#lead-paragraph", "section.tldr > p:first-child". כל סלקטור CSS תקין הוא תקף כאן. גוגל ימצא את האלמנט באמצעות הסלקטור הזה ויחשיב אותו כתוכן ה-speakable.

זה המנגנון המומלץ של גוגל בתיעוד הרשמי שלו, וגם של שאר המנועים. הסיבה, CSS selectors קרובים לעולם של מפתחי frontend, קלים לכתיבה, וקלים לאימות בדפדפן (פשוט querySelector בקונסול).

xpath, הוותיק

זה ה-property שמשתמש ב-XPath, שפת ניווט ב-XML/HTML שהייתה דומיננטית בעידן שבו DOM parsing נעשה דרך מנועי XML. למשל, "/html/body/main/article/section[2]/p[1]". זה תקין, אבל הרבה יותר שביר. כל שינוי במבנה ה-DOM שובר את הסלקטור.

אני אישית כמעט אף פעם לא משתמש ב-xpath ל-Speakable. cssSelector מספיק לכל מקרה רגיל. xpath שמור למקרים מאוד ייחודיים שבהם אין דרך אחרת, למשל כשאתם עובדים עם CMS שמייצר HTML אוטומטי ולא מאפשר לכם להוסיף class names משלכם, או כשהאלמנט שאתם רוצים לסמן מוגדר רק על ידי המיקום שלו (למשל "הפסקה השלישית בכל מאמר"). גם במקרים האלה אני מנסה קודם לעקוף, להוסיף wrapper עם class, ורק כשבאמת אין ברירה, אני נופל ל-xpath.

שווה להזכיר שהבחירה אינה רק טכנית, היא גם פילוסופית. cssSelector קורא לכם להגדיר את התוכן באופן semantic, כי אתם נותנים לו class name משמעותי כמו ".article-summary". xpath בעצם מבקש מכם להגדיר את התוכן באופן מבני, "זה האלמנט במיקום הזה". הראשון יציב ויעבור שינויים, השני שביר ויקרוס בכל refactor. בעידן שבו אתרים עוברים restyle כל שנה, יציבות שווה זהב.

🔑 Required pattern, ‏Speakable כ-property של WebPage (עם דוגמת קוד)

הפסקה הזאת היא הבסיס. אם תזכרו רק את החלק הזה, כבר תוכלו להתחיל. Speakable לא עומד לבדו. הוא תמיד מוצמד ל-WebPage או ל-Article, כ-property שלהם בשם "speakable". זאת הדרך הקנונית לפי תיעוד גוגל. הנה איך זה נראה במבנה המינימלי ביותר.

הקוד המינימלי

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "איך לבחור יועץ SEO",
  "url": "https://example.co.il/seo-consultant-guide/",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".article-summary"]
  }
}
</script>

שימו לב לכמה דברים קריטיים. ראשית, ה-cssSelector הוא תמיד array, גם אם יש בו ערך אחד. זה דרישה של schema.org, ואי עמידה בה תפיל את האימות. שנית, ה-WebPage עצמו חייב את כל ה-properties הרגילים שלו, name ו-url, בלי קשר ל-speakable.

למה זה חשוב להקפיד על המבנה

גוגל מצפה לראות את ה-speakable מקונן בתוך WebPage (או type שמרחיב את WebPage, כמו Article). הוא לא מצפה לראות SpeakableSpecification עומד לבד בשורש ה-graph. אם תכניסו אותו לבד, הוא לא יזוהה.

בפרקים הבאים נראה איך להרחיב את המבנה הזה לשילוב עם Article, איך לסמן כמה אזורים, ואיך לבחור את הסלקטור הנכון מבחינה אסטרטגית. אבל הבסיס תמיד נשאר אותו דבר, speakable כ-property של WebPage עם cssSelector כ-array.

📰 שילוב Speakable עם Article (עם דוגמת קוד מלאה)

במאמרים אמיתיים, אתם תרצו לא רק WebPage אלא גם Article schema, כדי לתת לגוגל ולמודלי AI את ההקשר העריכתי המלא (מי הכותב, מתי פורסם, על מה זה). השילוב הוא טבעי, ושניהם יכולים לחיות יחד באותו @graph.

הקוד המלא, WebPage + Article + Speakable

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://example.co.il/voice-seo-guide/#webpage",
      "url": "https://example.co.il/voice-seo-guide/",
      "name": "voice SEO, המדריך המעשי",
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [
          ".pillar-hero h1",
          ".article-summary",
          ".key-answer"
        ]
      }
    },
    {
      "@type": "Article",
      "@id": "https://example.co.il/voice-seo-guide/#article",
      "headline": "voice SEO, המדריך המעשי",
      "author": {
        "@type": "Person",
        "name": "שמוליק דורינבאום",
        "url": "https://www.shmul.co.il/אודות/"
      },
      "datePublished": "2026-05-30",
      "image": "https://example.co.il/images/voice-seo.jpg",
      "mainEntityOfPage": {
        "@id": "https://example.co.il/voice-seo-guide/#webpage"
      }
    }
  ]
}
</script>

שימו לב למספר נקודות. ראשית, השתמשתי ב-@graph כדי להחזיק שני schemas באותו script. שנית, Speakable יושב על ה-WebPage, לא על ה-Article. זה נכון מבחינת schema.org. שלישית, ה-mainEntityOfPage של ה-Article מצביע על ה-@id של ה-WebPage, וכך נוצר קשר ברור בין שני האובייקטים.

למה זה השילוב המומלץ

גוגל מבין שיש לכם תוכן עריכתי (Article), ויש לכם הנחיה ל-voice (Speakable על WebPage). שני המנגנונים עובדים במקביל, ה-Article תורם ל-knowledge graph וה-Speakable מנחה את ערוצי הקריאה הקולית. שילוב חכם.

למידע מקיף על Article schema יש לי מדריך נפרד, ועל הסכמות בכלל יש את המדריך השלם לסכמות schema. שני אלה הם רקע חיוני להבנה מלאה של איך Speakable משתלב בתוך מבנה schema רחב יותר.

🎯 CSS selector best practices, ‏ספציפי תמיד מנצח רחב

הבחירה של ה-cssSelector היא קריטית. סלקטור רחב מדי וגוגל יבחר משהו שלא רציתם להקריא. סלקטור צר מדי וגוגל לא ימצא כלום. הנה ה-best practices שעובדות בשטח.

השתמשו בשמות class ייעודיים

הדרך הטובה ביותר היא להגדיר class names ייעודיים ל-speakable, ולסמן אותם בקוד ה-HTML. למשל, <div class="speakable-summary">...</div> ואז cssSelector של [".speakable-summary"]. זה ברור, יציב, ולא תלוי במבנה ה-DOM.

אל תסתמכו על tag names כלליים

סלקטור כמו "p" או "div" הוא רחב מדי. גוגל יבחר את כל הפסקאות או את כל ה-divs בעמוד, מה שלא נכון. תמיד הוסיפו ספציפיות, כמו ".article p:first-child" או "#summary p".

השתמשו ב-IDs כשרלוונטי

אם יש לכם אזור ייחודי במאמר, תנו לו id (ה-id חייב להיות יחיד בעמוד). למשל, <section id="tldr">. סלקטור של ["#tldr"] תמיד יחזיר בדיוק את האלמנט הנכון.

שמרו על יציבות

הסלקטור שלכם צריך לשרוד שינויים עתידיים בעיצוב. אם תשנו את ה-grid layout אחרי חצי שנה, וה-cssSelector תלוי במבנה זה, הוא יישבר. תכננו את ה-class names בהתאם, שמות semantic שמתארים את התוכן, לא את העיצוב.

טסטו בקונסול

לפני שאתם מטמיעים את הסלקטור ב-Speakable, פתחו את הדפדפן, ה-DevTools, וב-Console רוצו document.querySelectorAll('.your-selector'). וודאו שהתוצאה היא בדיוק האלמנט שאתם רוצים, ולא יותר ולא פחות. זה ה-litmus test הכי טוב לסלקטור שיעבוד.

✂️ מה לסמן (lead, key answer, summary), ‏ולמה NOT הכל

זאת אולי השאלה הכי חשובה במאמר הזה. "שמוליק, מה אני בעצם מסמן?". התשובה הקצרה, את החלקים הכי תמציתיים, הכי בעלי ערך עצמאי, והכי מתאימים להקראה בקול. החלקים הארוכים? תשאירו אותם בחוץ. תקשיבו, האינסטינקט הראשון של רוב מקדמי ה-SEO הוא "אני אסמן את כל המאמר כ-speakable, ככה הכי הרבה תוכן יוקרא". זאת טעות יסודית. תאמינו לי, פחות זה יותר.

סמנו את ה-lead

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

סמנו את התשובה הישירה

אם יש לכם מאמר שעונה על שאלה ("מה זה X?", "איך עושים Y?"), סמנו את הפסקה שמכילה את התשובה הישירה. עוזרי קול אוהבים את זה כי הם מקבלים תשובה גמורה להקראה, בלי לחפש בעצמם.

סמנו את ה-summary בסוף

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

אל תסמנו את כל המאמר

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

הכלל הפרגמטי שאני נותן ללקוחות

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

🤖 Google Assistant בפועל, ‏איך הוא בוחר מה להקריא

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

תרחיש 1, שאילתה ישירה עם תשובה מסומנת

משתמש שואל את Google Assistant, "איך מטמיעים HowTo schema?". יש לכם מאמר על הנושא עם Speakable על פסקת התקציר. סבירות גבוהה, Assistant יקריא את הפסקה הזאת בדיוק, ויציין שהמקור הוא האתר שלכם.

תרחיש 2, שאילתה כללית עם תשובה רחבה

משתמש שואל "מה זה SEO?". יש לכם מאמר מקיף עם Speakable על ה-lead. Assistant עשוי לבחור את התשובה שלכם, או עשוי לבחור תשובה ממקור אחר. כאן הסלקטור שלכם הוא רק אחד מהפרמטרים, ה-authority של האתר, ה-freshness של המאמר, וה-ranking הכללי גם משחקים.

תרחיש 3, שאילתת follow-up

משתמש שאל קודם משהו, ועכשיו שואל שאלת המשך. Assistant מחפש המשך הגיוני. אם הסיגנל של Speakable שלכם תואם ל-context של השאלה, יש סיכוי שתוקראו. אחרת, Assistant ילך למקום אחר.

איך לבדוק שזה עובד

אין דרך 100% לבדוק שגוגל קורא את הסלקטור שלכם. אבל יש שיטות עקיפות. ראשית, בדקו ב-Search Console את ה-Performance עם פילטר על voice queries (אם יש בנתונים שלכם). שנית, שאלו את Google Assistant באמת על מילות מפתח שאתם רוצים לדרג עליהן, ותקשיבו אם הוא מצטט את האתר שלכם. שלישית, השוו את ה-traffic ממקורות voice לפני ואחרי ההטמעה.

ההבדל בין מובייל לבית חכם

זה נקודה שרבים מפספסים. Google Assistant פועל בשני הקשרים מאוד שונים. במובייל, המשתמש בדרך כלל רואה גם תוצאות ויזואליות בנוסף לקול, ולכן הקריאה הקולית קצרה יותר. במכשירי בית חכם (Google Home, Nest Hub Speaker), אין מסך, אז התשובה הקולית היא הכל, ולכן היא ארוכה יותר ומפורטת יותר. ההשלכה ל-Speakable שלכם, אם אתם רוצים לדרג גם במכשירי בית חכם, סמנו פסקאות שיש להן ערך עצמאי גם כשהן הקריאה היחידה (לא רק תיזכורת חלקית של תוצאה ויזואלית). זה בדרך כלל פסקה ארוכה יותר, 80 עד 150 מילים, לעומת 30 עד 60 מילים במובייל.

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

🧠 Parsing strategy של גוגל, ‏מתי הוא מכבד ומתי לא

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

מתי גוגל מכבד את הסלקטור

כשהסלקטור ברור וייחודי, כשהאלמנט שהוא מצביע עליו מכיל טקסט קריא וקצר (פחות מ-300 מילים, אידאלי 50 עד 150), כשהטקסט עצמאי וניתן להבנה ללא הקשר נוסף, וכשהוא כתוב בשפה טבעית שמתאימה להקראה (משפטים מלאים, לא רשימת מילות מפתח).

מתי גוגל יבחר אחרת

כשהסלקטור מצביע על אזור גדול מדי (גוגל יקצץ או ידלג), כשהטקסט מלא ב-jargon לא מתאים להקראה, כשהאלמנט מכיל code blocks או צילומי מסך שלא ניתנים לקריאה בקול, כשהאלמנט עצמו לא קיים בעמוד (שגיאה!), או כשגוגל זיהה אזור אחר שלדעתו מתאים יותר. כן, גוגל יכול "לעקוף" את הסלקטור שלכם אם הוא חושב שהוא יודע יותר טוב.

למה לא להתבסס רק על Speakable

אם אתם רוצים להגדיל את הסיכוי שתוקראו בקול, Speakable הוא חיוני, אבל לא מספיק לבד. תוסיפו גם Article או FAQPage או HowTo (תלוי בסוג התוכן), ותדאגו שהטקסט עצמו כתוב בצורה שמתאימה להקראה, משפטים קצרים, שאלה ותשובה, ללא הפניות פנימיות ("ראו בפרק הקודם" לא עובד בקול). גוגל בוחנת את התוכן עצמו וגם את הסיגנלים סביבו, ושני הצדדים חייבים להיות מיושרים.

הגיון הבחירה של גוגל בשלוש שכבות

השכבה הראשונה, התאמת השאלה לתוכן. גוגל קודם כל בוחר את האתרים שהמאמר שלהם רלוונטי לשאלה. בלי relevance, Speakable לא יעזור. השכבה השנייה, sigaling. בין האתרים הרלוונטיים, גוגל מעדיף את אלה שמסמנים בבירור איזה חלק להקריא. כאן Speakable נכנס לתמונה. השכבה השלישית, איכות הטקסט עצמו. גוגל סורקת את ה-text-to-speech readability של הפסקה, ואם היא כתובה בצורה מסורבלת, גם עם Speakable, גוגל יבחר אחרת.

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

🌐 Bing, ‏Alexa ו-Siri ו-Speakable, ‏מצב האימוץ ב-2026

נראה את התמונה הרחבה. Google הוא הגדול, אבל לא היחיד. מה קורה עם שאר השחקנים, וכמה הם מכבדים את Speakable?

Bing

Bing תמכה ב-Speakable כסכמה כללית (היא חלק מ-schema.org אחרי הכל), אבל לא הציעה פיצ'רים ייעודיים סביבה. עם זאת, Bing Chat (החלק של Microsoft ב-AI search) משתמש ב-structured data בכלל, וזה כולל בעקיפין גם את Speakable. אם הסכמה שלכם תקינה ב-Bing, היא לא תזיק, ויכולה לעזור.

Alexa

Alexa מסתמכת על Alexa Skills ופחות על web crawling רגיל לזרימת תוכן קולי. ה-Speakable הרגיל פחות רלוונטי שם ישירות. אבל, אלקסה כן בודקת תוצאות web כשהיא לא מוצאת skill ספציפי, ובאותם רגעים, Speakable הוא סיגנל שאפשר להישען עליו. ההשפעה מוגבלת, אבל לא אפס.

Siri

סירי לא הכריזה תמיכה רשמית ב-Speakable, אבל עברה רענון מקיף בעידן Apple Intelligence. ההסתמכות שלה על web ו-AI כדי לענות הולכת וגדלה. כשהיא קוראת תוכן מהאתר שלכם, היא כנראה משתמשת בסיגנלים דומים לאלה של Google, וגם זה כולל את Speakable.

ChatGPT וגמיני Voice

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

מה לגבי Yandex ו-Baidu

שתי מנועי החיפוש האזוריים הגדולים האלה, Yandex ברוסיה ו-Baidu בסין, פחות רלוונטיים לרוב הקהל הישראלי, אבל אם יש לכם פעילות בינלאומית, שווה לדעת. Yandex תומכת חלקית ב-schema.org כולל Speakable. Baidu פחות גלויה, אבל גם היא צורכת structured data לחיפושים שלה. שוב, התשובה הפרגמטית, אם יש לכם תוכן בעברית, ההשפעה זניחה. אם יש לכם תוכן באנגלית או ברוסית, ההשפעה קטנה אבל לא אפס.

⚖️ Speakable מול Featured Snippets, ‏ההבדל המהותי

שאלה נפוצה ששואלים אותי, "שמוליק, אם יש לי Featured Snippet טוב, אני לא צריך Speakable? גם ככה גוגל קורא את ה-snippet כתשובה הקולית". התשובה היא, נכון חלקית, אבל זאת לא הסיבה לוותר על Speakable. הנה ההבחנה.

Featured Snippets

אלה ה-position zero ב-SERP, התשובה שגוגל בוחר אוטומטית להציג מעל התוצאות הרגילות. גוגל בוחר אותם על בסיס אלגוריתם משלו, בלי הצהרה ישירה שלכם איזה חלק מתאים. כשמשתמש שואל את Google Assistant על שאלה שיש לה Featured Snippet, Assistant בדרך כלל יקריא את ה-snippet. למידע מעמיק על Featured Snippets יש לי מדריך נפרד.

Speakable

זאת הצהרה ישירה שלכם, "זה החלק הכי מתאים להקראה". גוגל יכול להסתמך עליו גם כאשר אין Featured Snippet, גם בשאילתות יותר ספציפיות, וגם בערוצים שלא מציגים SERP ויזואלי בכלל (כמו ChatGPT Voice או Gemini Live).

למה צריך את שניהם

Featured Snippets הם תלויים-גוגל, תלויים-אלגוריתם, ולא ניתן להם שליטה ישירה. Speakable הוא בשליטתכם המלאה. שניהם משחקים בעולם הקולי, אבל ה-coverage שלהם שונה. Snippet זוכה כשגוגל מחליט. Speakable זוכה כשאתם מנחים את המנוע, וגוגל מקבל את ההנחיה.

למידע על איך להגיע ל-position zero יש לי מדריך נפרד. שני המנגנונים יחד הם הטקטיקה האופטימלית לאתר שרוצה לדומיננטי גם ב-SERP וגם ב-voice search.

🤖 AI engines + Speakable, ‏הסיגנל החדש לעולם החדש

זה החלק שהכי מתסכל אותי כשמדברים על Speakable עם מקדמי SEO. רובם חושבים על voice search כעידן שעבר, ועל Google Assistant כפיצ'ר שלא תפס. הם פשוט לא רואים את התמונה החדשה. עידן ה-AI Voice הוא לא המשך של voice search הישן, הוא בלעדי, וגדל בקצב מסחרר.

ChatGPT Voice Mode

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

Gemini Live של Google

אותו עיקרון, שיחה קולית טבעית עם המודל. Gemini בעל יתרון משמעותי כי הוא מאוחד למערכת של Google שכבר מכבדת Speakable. כש-Gemini Live עונה על שאלה, יש יותר סבירות שהוא יבחר תוכן עם Speakable מסומן, על פני תוכן ללא.

AI Overviews הקוליות

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

תכנית פעולה ל-2026

לכל מאמר חדש שאתם כותבים, הוסיפו Speakable כברירת מחדל. למאמרים קיימים שמדורגים טוב, חזרו אחורה והוסיפו Speakable. אל תחכו לראות AI Voice "מתבסס", עד שזה יקרה, כל אתר ראוי כבר יהיה מסומן, ואתם תמצאו את עצמכם רצים אחורה. למידע מקיף על SEO לעידן voice יש לי מדריך מקיף נפרד, ועל GEO בכלל את המדריך השלם ל-GEO.

ההבדל בין AI Voice ל-voice search הישן

תקשיבו, אלה לא אותו דבר. voice search הישן ("היי גוגל, מה השעה") היה תשובה אחת קצרה לשאלה אחת קצרה. הסיגנל היה פשוט, אתה מקריא טקסט, נגמר. AI Voice של ChatGPT וגמיני הוא שיחה. המודל לוקח את התוכן שלכם, מבין אותו עמוק, ובונה תשובה מותאמת. הוא יכול לצטט אתכם ישירות, או לסכם אתכם, או לשלב בין כמה מקורות. בכל אחד מההקשרים האלה, Speakable הוא הסיגנל שאומר "כשתבחר תוכן ממני להקראה, קח את החלקים האלה".

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

📚 דוגמאות קוד, ‏blog, ‏news, ‏recipe, ‏business pages

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

Blog post

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "5 הטעויות הנפוצות במחקר מילות מפתח",
  "url": "https://example.co.il/blog/keyword-mistakes/",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      ".post-lead",
      ".key-takeaway"
    ]
  }
}
</script>

בבלוג, סמנו את ה-lead (פסקה פותחת) ואת ה-takeaway (שורה תחתונה). שני אלה הם החלקים שעוזר קול יוכל להקריא בלי הקשר נוסף.

News article

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "גוגל מכריזה על שינוי באלגוריתם, אפריל 2026",
  "url": "https://example.co.il/news/google-update-april-2026/",
  "datePublished": "2026-04-15",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      ".news-headline",
      ".news-summary",
      ".news-impact"
    ]
  }
}
</script>

ב-news, גוגל מעדיפה Speakable בעצם. הסכמה פותחת לכם דלת ב-Google News, ומגדילה את הסיכוי להופיע ב-Google Assistant כתשובת חדשות. סמנו את הכותרת, התקציר, וההשפעה ("מה זה אומר עליי?").

Recipe page

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Recipe",
      "name": "חביתה ספרדית קלאסית",
      "recipeIngredient": ["5 ביצים", "3 תפוחי אדמה", "בצל גדול"]
    },
    {
      "@type": "WebPage",
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [
          ".recipe-description",
          ".prep-overview"
        ]
      }
    }
  ]
}
</script>

במתכון, סמנו את התיאור הקצר ואת סקירת ההכנה. אל תסמנו את רשימת המרכיבים (זה לא ראוי להקראה רציפה, יש לזה מנגנון נפרד ב-Recipe schema).

Business page

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "LocalBusiness",
      "name": "קליניקת שיניים תל אביב",
      "address": {"@type": "PostalAddress", "streetAddress": "דיזנגוף 142"},
      "telephone": "+972-3-1234567"
    },
    {
      "@type": "WebPage",
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [
          ".business-tagline",
          ".business-hours-summary"
        ]
      }
    }
  ]
}
</script>

בעמוד עסק, סמנו את ה-tagline שמסביר מה העסק עושה, ואת סיכום שעות הפעילות. אלה החלקים שעוזר קול יקרא כשמשתמש שואל "מה השעות של קליניקת השיניים בתל אביב".

הטכניקה לבחור class names

שמתי לב בדוגמאות שהשתמשתי בשמות class מאוד spec ל-speakable, .post-lead, .key-takeaway, .news-summary, .recipe-description, .business-tagline. זאת בכוונה. שמות semantic, שמתארים את התפקיד של התוכן ולא את העיצוב שלו. אל תסמנו .red-box או .first-column, כי אלה תלויים בעיצוב ויישברו. תסמנו לפי תפקיד, .summary, .lead, .answer, .quote. שמות כאלה ישרדו refactor של עיצוב.

קונבנציה לדפוס שלי

אצלי בכל אתר אני מגדיר prefix אחיד, למשל .spk- (קיצור של speakable). אז .spk-lead, .spk-summary, .spk-key-answer. זה עוזר לי לזכור איפה הסכמה חלה, וגם עוזר למפתחי frontend לא לדרוס את ה-class בטעות. אם אתם בונים מערכת לאתר גדול, תקבעו קונבנציה מההתחלה ותחסכו לעצמכם בלגן בעתיד.

FAQ page, ‏הסוג הקלאסי

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "מה זה Speakable schema?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "סכמה שמסמנת אילו פסקאות בעמוד מתאימות להקראה על ידי עוזרי קול."
          }
        }
      ]
    },
    {
      "@type": "WebPage",
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [
          ".spk-intro",
          ".spk-top-answer"
        ]
      }
    }
  ]
}
</script>

בעמוד FAQ, השילוב של FAQPage עם Speakable הוא קומבינציה חזקה. ה-FAQPage נותן לגוגל את המבנה של שאלה ותשובה, ה-Speakable אומר לעוזרי קול בדיוק איזה אזור (intro + תשובה הראשונה) להקריא אם משתמש שואל שאלה כללית בנושא.

✅ Validation, ‏איך לבדוק ש-Speakable שלכם תקין

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

שלב 1, Schema.org Validator

נכנסים ל-validator.schema.org, מדביקים את ה-URL או את ה-HTML, ומריצים. הכלי יציג את כל ה-schemas שזוהו ויסמן שגיאות. עבור Speakable, ודאו שמופיע SpeakableSpecification עם cssSelector כ-array (לא string!). אם זה לא מופיע, יש שגיאה.

שלב 2, Rich Results Test

נכנסים ל-search.google.com/test/rich-results, מזינים URL. הכלי מציג את ה-structured data שזוהה. שימו לב, Rich Results Test לא תמיד יציג Speakable כפיצ'ר נפרד (כי גוגל לא מציגים אותו כ-rich result ויזואלי), אבל אם הוא מופיע ב-"Detected items" של ה-WebPage, זה סימן שהוא זוהה.

שלב 3, בדיקת הסלקטור בקונסול

בדפדפן, פותחים את העמוד, F12 לפתוח DevTools, ובקונסול רוצים, document.querySelectorAll('.your-selector'). אם התוצאה היא בדיוק האלמנט שאתם רוצים שיוקרא, הסלקטור תקין. אם התוצאה ריקה, הסלקטור שבור. אם התוצאה היא יותר מאלמנט אחד, יש לכם בעיה (גוגל יבחר אחד).

שלב 4, JSON Lint

בדקו שה-JSON עצמו תקין סינטקטית. השתמשו ב-jsonlint.com או דומה. שגיאה סינטקטית קטנה כמו פסיק חסר תפיל את כל הסכמה, וכלי גוגל לא תמיד יזעקו על זה (הם מנסים להיות סלחנים).

שלב 5, מעקב התנהגות בפועל

אחרי כמה שבועות, בדקו ב-Search Console את ה-Performance עם פילטר לערוצי voice (אם יש בנתונים). אם traffic ממקור voice עולה, סימן שהסיגנל עובד. אם לא, אולי הסלקטור מצביע על תוכן שלא מתאים להקראה (חזרו לפרק על מה לסמן ותחשבו מחדש).

📅 audit חודשי + checklist הטמעה מלא

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

checklist הטמעה ראשונית

• בחירת 2 עד 4 פסקאות מתאימות להקראה (lead, summary, key answer)
• הוספת class names ייעודיים ב-HTML למקטעים הללו
• כתיבת ה-cssSelector ב-array, גם אם ערך אחד
• הצמדה ל-WebPage או Article (לא standalone)
• שילוב ב-@graph עם schemas אחרים אם רלוונטי
• אימות ב-Schema.org Validator
• אימות ב-Rich Results Test
• אימות הסלקטור בקונסול (querySelectorAll)
• אימות שגיאות JSON ב-JSONLint
• שמירת רשימה של הסלקטורים שהוטמעו, לבדיקה חוזרת

audit חודשי, 10 דקות לעמוד

1. ריצה של הסלקטור בקונסול, וודאו שהוא עדיין מצביע על האלמנט הנכון. אם השם של ה-class השתנה, עדכנו את ה-JSON-LD
2. קריאת התוכן עצמו, וודאו שהוא עדיין מתאים להקראה. אם הוספתם הפניות פנימיות ("ראו בפרק הקודם"), הסירו
3. בדיקת Rich Results Test, וודאו שאין שגיאות חדשות שגוגל מדווח עליהן
4. בדיקת Performance ב-GSC, חפשו אם traffic ממקור voice משתנה. ירידה פתאומית יכולה לרמז על בעיה
5. שאלת Google Assistant, בדקו אם הוא מצטט אתכם בנושאים שבחרתם לסמן

בונוס, שילוב עם AI search analytics

בכלי ניתוח חדשים שמודדים תנועה ממנועי AI (ChatGPT referrals, Perplexity citations וכו'), שימו לב לקורלציה בין הטמעת Speakable לבין מספר ה-citations שאתם מקבלים. אצל לקוחות שעבדתי איתם, ראיתי גידול ניכר ב-citations ב-Perplexity אחרי הטמעת Speakable, גם בלי שהמנוע הכריז על תמיכה רשמית בסכמה.

❓ שאלות נפוצות