SEO טכני לאתרים בעברית: 12 דברים שרוב האתרים מפספסים
אתרים בעברית סובלים מקבוצת תקלות SEO משלהם שכלי הבדיקה הסטנדרטיים כמעט אף פעם לא מסמנים. הנה שתים-עשרה מהן.
SEO טכני לאתר בעברית מתחיל בחמישה דברים: lang="he" ו-dir="rtl" נכונים,
כתובת קנונית אחת לכל עמוד, מבנה כותרות אמיתי, נתונים מובנים שתואמים לתוכן, ועמודים שגוגל יכולה לסרוק
ולאנדקס. רוב הבעיות באתרים עבריים אינן בהבנת השפה אלא בהגדרות שנשברו בתבנית או בתוספים - ואותם
יסודות קובעים גם אם עמוד יכול להופיע כמקור ב-AI Overviews.
אתרים בעברית סובלים מקבוצת תקלות טכניות משלהם. חלק מהן נובעות מכיווניות RTL, חלק מהתמודדות עם קידוד תווים, וחלק פשוט מכך שרוב המדריכים והתוספים נכתבו לאנגלית. שתים־עשרה הבעיות הבאות חוזרות אצל כמעט כל אתר עברי שאנחנו בודקים. אחריהן תמצאו מה משתנה בעידן תשובות ה-AI, טבלת בדיקה, דוגמה של ביקורת וסדר עדיפויות לתיקון.
1. הגדרת שפה שגויה
הבעיה הנפוצה ביותר, והכי קלה לתיקון. תבנית שנקנתה מחו"ל מגיעה לעיתים קרובות עם
lang="ar" או lang="en", והמתקין החליף רק את הטקסטים.
התוצאה: קוראי מסך מבטאים עברית בהגייה ערבית או אנגלית, וגוגל מקבלת אות סותר לגבי שפת העמוד. הבדיקה לוקחת שנייה - פתחו את קוד המקור וודאו שהשורה הראשונה היא:
<html lang="he" dir="rtl">
שימו לב ששני המאפיינים נדרשים. dir="rtl" קובע כיווניות,
lang="he" קובע שפה. אחד לא מחליף את השני. ואם יש בעמוד קטע ארוך באנגלית, אפשר לסמן
אותו בנפרד עם lang="en", כדי שקורא המסך יעבור להגייה הנכונה רק בו.
2. כתובות מקודדות בעברית
כתובת כמו /שירותים/בניית-אתרים/ נראית טוב בדפדפן, אבל ברגע שמעתיקים אותה
היא הופכת למחרוזת של עשרות תווי %D7%. בוואטספ ובפייסבוק זה נראה כמו קישור זבל,
ואנשים לוחצים פחות.
זה לא פוגע ישירות בדירוג, אבל הוא פוגע בשיתופים ובקישורים נכנסים - שכן משפיעים.
העדיפו תעתיק לועזי קצר, כמו /services/web-development/. בוורדפרס כדאי לשים לב לזה
במיוחד, כי ברירת המחדל יוצרת כתובת מהכותרת העברית של כל פוסט, מוצר וקטגוריה.
ואם האתר כבר קיים עם כתובות בעברית, אל תשנו אותן בבת אחת בלי תוכנית. כל כתובת שמשתנה צריכה הפניית 301 מהכתובת הישנה, אחרת קישורים נכנסים ודירוגים הולכים לאיבוד.
3. כפילות תוכן בין גרסאות
אותו עמוד נגיש לרוב בארבע כתובות שונות: עם www ובלי, עם https
ובלי, עם סלאש בסוף ובלי, ועם index.php ובלי. לגוגל אלה עשויים להיראות
כארבעה עמודים עם אותו תוכן. פרמטרים של קמפיינים, כמו UTM או מזהי קליק של פייסבוק וגוגל, מוסיפים
עוד וריאציות.
הפתרון הוא כפול, וצריך את שניהם:
- הפניות 301 בשרת מכל הווריאציות לגרסה אחת נבחרת.
- תגית
canonicalבכל עמוד שמצביעה על אותה גרסה, כולל עמודים שמצביעים על עצמם.
ומפת האתר צריכה לכלול רק את הכתובות הקנוניות. מפת אתר שמפרסמת גרסה אחת וקנוני שמצביע על אחרת היא אות סותר שגוגל תפתור בעצמה, לא תמיד לטובתכם.
4. כותרות שנחתכות בתוצאות
גוגל חותכת כותרות לפי רוחב בפיקסלים, לא לפי מספר תווים. אותיות עבריות רחבות מהממוצע הלטיני, כך שכותרת עברית נחתכת מוקדם יותר ממה שכלי בדיקה מבוססי־תווים מראים.
ככלל אצבע מעשי: שאפו לעד 55-60 תווים בעברית, ושימו את המילה החשובה ביותר בהתחלה ואת שם המותג בסוף. אותו כלל תקף לתיאור המטא - עד כ-150 תווים. זכרו שגוגל יכולה לשכתב כותרת ותיאור כשהיא חושבת שהם לא מתארים את העמוד; כותרת שמתארת בדיוק את מה שבעמוד היא הדרך הטובה ביותר להשאיר את הנוסח שלכם.
5. מבנה כותרות דקורטיבי
זו התקלה שהכי הרבה אתרים בעברית נכשלים בה, כי בונים לפי איך שזה נראה ולא לפי מה שזה אומר.
טקסט קטן מעל הכותרת מסומן כ-<h3> כי הוא קטן, והכותרת הראשית כ-<h1>.
התוצאה היא מבנה שקופץ ולא מתאר את היררכיית התוכן.
הכללים פשוטים: h1 אחד בלבד לעמוד, ואין דילוג מ-h2 ל-h4.
כותרות משנה קטנות שהן קישוט צריכות להיות <span> או <p>, לא כותרת.
יש לזה גם צד של תשובות AI. כותרת שמנוסחת כשאלה אמיתית - "כמה עולה...", "מה ההבדל בין..." - ומשפט ראשון מתחתיה שעונה עליה ישירות, הם המבנה שהכי קל למנוע חיפוש לחלץ ממנו תשובה.
6. נתונים מובנים חסרים או מיושנים
נתונים מובנים הם איך שאתם מסבירים למנועי חיפוש מה העמוד הוא, לא רק מה כתוב בו - ובאתרים עבריים הם לרוב חסרים, או שנשארו מתוסף ישן עם סוגים שכבר לא מקבלים תצוגה מיוחדת. לעסק ישראלי, אלה הסוגים שמשנים הכי הרבה:
- Organization או LocalBusiness (וסוג ספציפי יותר כשיש, כמו LegalService) - שם, כתובת, טלפון ושעות פעילות. קריטי לחיפושים מקומיים.
- BreadcrumbList - מסלול ניווט שעוזר לגוגל להבין את מבנה האתר.
- Article - למאמרים, עם תאריך פרסום ועדכון ושם הכותב.
- FAQPage - לשאלות ותשובות שמופיעות בעמוד.
חשוב לעדכן ציפיות לגבי FAQ. מאז אוגוסט 2023 גוגל מציגה תוצאות FAQ מורחבות רק לאתרים סמכותיים של ממשלה ובריאות, ותוצאות HowTo הוסרו לגמרי. כלומר, סימון FAQ באתר עסקי כבר לא ייתן שאלות נפתחות בתוצאה. הוא עדיין תקין ועדיין עוזר למכונות להבין את העמוד, ולכן אין סיבה להסיר אותו - רק לא לצפות ממנו לתצוגה.
והכלל שלא השתנה: הנתונים המובנים חייבים לשקף תוכן שקיים בפועל בעמוד. סימון FAQ לשאלות שלא מופיעות לגולש נחשב הפרה של ההנחיות. באתר של ZAVUROV & CO., למשל, כל סוג סימון - LegalService, Person, Article, FAQPage ו-BreadcrumbList - מתאים לתוכן שהגולש רואה באותו עמוד.
7. תמונות בלי alt בעברית
ברוב האתרים העבריים שאנחנו בודקים, ה-alt ריק או מכיל את שם הקובץ.
זה פוגע בשלושה מקומות בבת אחת: נגישות, חיפוש תמונות, והבנת ההקשר של גוגל.
כתבו תיאור ענייני בעברית של מה שרואים בתמונה. אם התמונה דקורטיבית בלבד,
השאירו alt="" ריק במפורש - כך קורא המסך ידלג עליה במקום להקריא שם קובץ. ובדרך, תנו
לקובץ עצמו שם תיאורי בתעתיק לועזי ולא IMG_4521.jpg.
טעות נפוצה הפוכה היא לדחוס מילות מפתח לתוך ה-alt. "בניית אתרים בניית אתרים זולה" לא עוזר לאף אחד. תיאור שהיה עוזר לאדם שלא רואה את התמונה הוא בדיוק התיאור שעוזר גם למנוע החיפוש.
8. תקלות RTL שפוגעות בשימושיות
תבניות שהומרו ל-RTL בעבודת יד כמעט תמיד מפספסות מקומות. הסימנים הנפוצים: אייקונים בצד הלא נכון של הטקסט, חצים שמצביעים לכיוון ההפוך, פסי גלילה אופקיים לא רצויים, וטפסים שבהם התווית לא מיושרת לשדה.
הפתרון המודרני הוא להשתמש בתכונות לוגיות ב-CSS - margin-inline-start
במקום margin-left, text-align: start במקום right.
כך הכיווניות נגזרת מ-dir ולא מקודדת קשיח. ובתוך הטקסט, מספרי טלפון, מחירים וטווחים
כמו 10-20 נוטים להתהפך; עטיפה ב-<bdi> שומרת עליהם בסדר הנכון.
9. גופנים עבריים שחוסמים רינדור
אתר עברי טיפוסי טוען שלוש משפחות גופנים מ-Google Fonts, כל אחת בחמישה משקלים. זה חמישה־עשר קבצים מדומיין חיצוני, לפני שהטקסט מוצג בכלל.
שלושה תיקונים שמשפיעים מיד:
- הסתפקו במשפחה אחת. שתיים לכל היותר.
- אחסנו את הגופן אצלכם והשתמשו ב-
preloadעל הקובץ הקריטי. - השתמשו ב-
font-display: swapכדי שהטקסט יוצג מיד בגופן חלופי.
קובץ גופן עברי בפורמט woff2, בתת־קבוצה שמכילה רק את התווים הנחוצים, שוקל בדרך כלל עשרות קילובייטים בודדים ולפעמים פחות מ-15KB. הרחבנו על ההשפעה על הביצועים, כולל LCP, INP ו-CLS, במדריך Core Web Vitals.
10. עמודים דקים שמבזבזים תקציב סריקה
עמודי תגיות ריקים, ארכיוני תאריכים, עמודי חיפוש פנימי ועמודי נחיתה ישנים - כולם נסרקים, וכולם מדללים את איכות האתר בעיני גוגל.
עברו על דוח האינדוקס ב-Search Console וסמנו noindex על כל מה שאין לו
ערך למי שמגיע מחיפוש.
noindex ולא Disallow. כדי להוציא עמוד מהאינדקס משתמשים ב-noindex, לא
בחסימה ב-robots.txt. חסימה ב-robots מונעת מגוגל לסרוק, ולכן היא גם מונעת ממנה לראות את הוראת
ה-noindex - והעמוד עלול להישאר באינדקס, רק בלי תיאור.
ובאותה הזדמנות, הבדיקה שהכי חשוב לעשות אחרי כל השקה: שהאתר לא נשאר חסום. אתרים שנבנו בסביבת בדיקות
עולים לא פעם לאוויר עם noindex על כל העמודים, עם האפשרות של וורדפרס שמבקשת ממנועי חיפוש
לא לאנדקס את האתר, או עם robots.txt שחוסם הכול. זה הסבר נפוץ לאתר חדש ש"לא מופיע בגוגל" אחרי חודש.
הערה הוגנת: "תקציב סריקה" במובן הצר רלוונטי בעיקר לאתרים גדולים מאוד. באתר של כמה עשרות עמודים גוגל תסרוק הכול בכל מקרה. הבעיה באתר קטן היא אחרת - עשרות עמודים ריקים שמתחרים בעמודי השירות ומשדרים שהאתר דל. זה סיבה מספיקה לנקות.
11. קישור פנימי אקראי
קישור פנימי הוא הכלי החזק ביותר שיש לכם שליטה מלאה עליו, ורוב האתרים משתמשים בו רק בתפריט. עמוד שאין אליו קישורים פנימיים משדר לגוגל שהוא לא חשוב.
בנו מבנה מכוון: כל מאמר מקשר לעמוד השירות הרלוונטי, כל עמוד שירות מקשר לשירותים קרובים ולשני מאמרים מעמיקים. השתמשו בטקסט עוגן תיאורי - "בניית אתרים ואתרי תדמית" ולא "לחצו כאן".
שתי בדיקות מהירות: האם יש עמודים שאין אליהם אף קישור פנימי (עמודים "יתומים" שגוגל מגיעה אליהם רק דרך מפת האתר), והאם העמודים הכי חשובים לעסק - עמודי השירות - מקבלים את רוב הקישורים, או שהם נבלעים מתחת למאמרים ולעמודי תגיות. דוח הקישורים ב-Search Console מראה את שני הדברים.
12. חסימת זום בנייד
הרבה תבניות מגיעות עם user-scalable=no או maximum-scale=1
בתגית ה-viewport. זה מונע ממשתמשים להגדיל את המסך - כשל נגישות מובהק לפי WCAG 1.4.4,
ובעיה אמיתית באתר בעברית שבו הטקסט לרוב קטן יותר. ובישראל נגישות היא גם דרישת חוק, לפי תקן ישראלי
5568 שמבוסס על WCAG.
התגית הנכונה היא פשוט:
<meta name="viewport" content="width=device-width, initial-scale=1">
מה משתנה בעידן AI Overviews?
מבחינה טכנית, פחות ממה שנדמה: לפי גוגל, כדי להופיע כמקור ב-AI Overviews עמוד צריך להיות מאונדקס ומותר להצגה עם קטע תצוגה בתוצאות, ואין דרישות טכניות נוספות. AI Overviews הגיעו לישראל ב-2025, וההנחיות של גוגל לבעלי אתרים מופיעות בעמוד תכונות AI והאתר שלכם.
מה שכן משתנה הוא המשקל של כמה דברים שהיו "נחמד שיש":
- תוכן חשוב בטקסט. מחירים, שעות ותשובות שמופיעים רק בתמונה או נטענים רק אחרי לחיצה קשים יותר לחילוץ.
- תשובה ישירה בראש כל חלק. כותרת בצורת שאלה, ומשפט ראשון שאפשר לצטט לבד.
- נתונים מובנים שתואמים לתוכן. לא כדי לקבל תצוגה מיוחדת, אלא כדי שמכונות יבינו מי אתם ומה בעמוד.
- הגדרות תצוגה.
nosnippetו-max-snippetמגבילים מה מוצג מהעמוד, גם בתכונות ה-AI. בדקו שלא הוגדרו בטעות על כל האתר.
ומה עם זחלנים של מערכות AI אחרות? כל אחת מזדהה בשם משלה ב-robots.txt - למשל GPTBot ו-OAI-SearchBot של
OpenAI או PerplexityBot. החליטו במודע את מי לאפשר. שימו לב שהכלל Google-Extended שולט
בשימוש של מערכות AI אחרות של גוגל, לא בחיפוש: חסימה שלו לא מוציאה אתכם מ-AI Overviews, וחסימה של
Googlebot תוציא אתכם מכל החיפוש. קובץ llms.txt אינו דרישה של גוגל; אפשר להוסיף, אבל הוא לא תחליף לאתר
שסריק ומובן.
איך יודעים אם האתר מופיע בתשובות ה-AI?
לפי גוגל, חשיפות וקליקים מ-AI Overviews ומ-AI Mode נכללים בדוח הביצועים של Search Console, תחת סוג החיפוש "אינטרנט", יחד עם שאר התנועה מהחיפוש. אין להם כרגע דוח נפרד, ולכן הדרך המעשית היא לעקוב אחרי החשיפות והקליקים של העמודים שעונים על שאלות, ולבדוק ידנית את החיפושים החשובים לכם. אצל עוזרי AI אחרים, הסימן הכי ברור הוא תנועה מפנה מהדומיינים שלהם בכלי המדידה.
טבלת סיכום: איך בודקים כל סעיף
את רוב שתים־עשרה הבדיקות אפשר לעשות בעצמכם בתוך שעה, עם Search Console, קוד המקור של העמוד וטלפון נייד. הטבלה מרכזת איך בודקים כל סעיף וכמה עבודה התיקון דורש בדרך כלל:
| סעיף | איך בודקים | מאמץ תיקון נפוץ |
|---|---|---|
| 1. שפה | קוד המקור, השורה של תגית html | דקות |
| 2. כתובות | להעתיק כתובת עמוד ולהדביק בוואטספ | שעות, כולל הפניות |
| 3. כפילות | לנסות את ארבע הווריאציות של הדומיין בדפדפן | שעה עד כמה שעות |
| 4. כותרות | חיפוש site: של האתר בגוגל, בנייד | שעות, לפי מספר העמודים |
| 5. מבנה כותרות | תוסף דפדפן שמציג את מבנה ה-h | שעות, לרוב בתבנית |
| 6. נתונים מובנים | בדיקת התוצאות המתקדמות של גוגל ו-Schema Markup Validator | שעות |
| 7. alt | כלי בדיקה אוטומטי או קורא מסך | תלוי בכמות התמונות |
| 8. RTL | מעבר על האתר בטלפון, כולל טפסים | שעות עד ימים |
| 9. גופנים | PageSpeed Insights, לשונית Network | שעות |
| 10. עמודים דקים | דוח הדפים ב-Search Console | שעות |
| 11. קישור פנימי | דוח הקישורים ב-Search Console | מתמשך |
| 12. זום | קוד המקור, תגית viewport | דקות |
שימו לב שרוב הסעיפים מתוקנים פעם אחת בתבנית, ומשם הם נכונים לכל העמודים. לכן ביקורת טכנית היא בדרך כלל השקעה חד-פעמית קטנה, ולא פרויקט מתמשך - חוץ מקישור פנימי, שמתעדכן עם כל עמוד חדש.
דוגמה: ביקורת לאתר תדמית של 40 עמודים
בביקורת טיפוסית, אתר של 40 עמודים אמיתיים מתגלה כאתר עם יותר מ-100 כתובות בעיני גוגל, ורוב התיקון לוקח פחות מיום. הדוגמה הבאה היא תרחיש להמחשה, לא מקרה של לקוח מסוים, אבל כל ממצא בה חוזר שוב ושוב באתרים עבריים.
נניח אתר וורדפרס של משרד עם 40 עמודים: עמוד בית, שמונה עמודי שירות ו-31 מאמרים. ב-Search Console
מופיעות 112 כתובות מאונדקסות. הבדיקה מגלה: האתר נגיש גם עם www וגם בלעדיו, ו-18 עמודים
מאונדקסים פעמיים; 26 עמודי תגיות עם פוסט אחד או שניים; 28 כתובות עם פרמטרים של קמפיינים; תגית
lang="en" מהתבנית; ו-19 כתובות מאמרים בעברית מקודדת.
התיקון: הפניית 301 לגרסה אחת וקנוני בכל עמוד, noindex על עמודי התגיות, קנוני שמנטרל
פרמטרים, תיקון השפה בתבנית, ותעתיק לועזי למאמרים עם הפניה מכל כתובת ישנה. בתוך כמה שבועות, כשגוגל
סורקת מחדש, מספר הכתובות המאונדקסות אמור להתקרב ל-40 - כל עמוד פעם אחת, בכתובת אחת. זה לא מבטיח עלייה
בדירוג, אבל זה מסיר את הרעש שמסתיר את העמודים החשובים.
כך בדיוק עבדנו באתר של מולא מנעולים ומפתחות, שהחליף אתר קודם: הגדרנו הפניות 301 מכתובות האתר הקודם, כדי שקישורים ודירוגים שנצברו לא ילכו לאיבוד, והוספנו נתונים מובנים מסוג Locksmith, OfferCatalog ו-FAQPage שתואמים לתוכן העמוד.
מאיפה להתחיל
אם אתם מתקנים לבד, התחילו מהגדרת השפה, מהכפילות, ממבנה הכותרות ומהנתונים המובנים. ארבעת אלה מכסים את רוב הנזק ולוקחים פחות מיום עבודה. זה סדר העדיפויות המלא שאנחנו ממליצים עליו:
- הגדרת השפה והכיווניות בתגית html (סעיף 1).
- גרסה אחת לכל עמוד: הפניות 301 וקנוני (סעיף 3).
- מבנה כותרות אמיתי, עם h1 אחד לעמוד (סעיף 5).
- נתונים מובנים שתואמים לתוכן (סעיף 6).
- noindex על עמודים דקים, ומפת אתר עם כתובות קנוניות בלבד (סעיף 10).
- תגית viewport שמאפשרת זום (סעיף 12).
- גופנים, ואחריהם שאר ביצועי העמוד (סעיף 9).
- כותרות ותיאורי מטא לעמודים החשובים (סעיף 4).
- alt לתמונות ותיקוני RTL (סעיפים 7 ו-8).
- תוכנית קישור פנימי, ובדיקה שאין חסימה לא מכוונת של זחלנים (סעיף 11).
לכל זה מספיקים כלים חינמיים: Search Console לאינדוקס, לכיסוי ולביצועים, PageSpeed Insights למהירות, בדיקת התוצאות המתקדמות של גוגל לנתונים מובנים, ו"הצגת מקור" בדפדפן לכל השאר. באתר של יותר מכמה עשרות עמודים, כלי סריקה שעובר על כל הכתובות חוסך שעות של בדיקה ידנית.
שורה תחתונה
SEO טכני באתר עברי הוא בעיקר היגיינה: שפה מוצהרת נכון, כתובת אחת לכל עמוד, מבנה שמתאר את התוכן, נתונים מובנים אמיתיים ואתר מהיר ונגיש. זה לא מחליף תוכן טוב, אבל זה מה שמאפשר לגוגל - וגם ל-AI Overviews ולעוזרי AI - למצוא אותו, להבין אותו ולצטט אותו. רוב התיקונים זולים, והנזק מהזנחה שלהם מצטבר בשקט.
אם אתם רוצים ביקורת מלאה של האתר שלכם, זה בדיוק מה שאנחנו עושים בשלב הראשון של עבודת הקידום האורגני. שלחו לנו את כתובת האתר, ונגיד לכם מה הכי דחוף לתקן.
שאלות נפוצות
מה זה SEO טכני?
SEO טכני הוא כל מה שמאפשר למנועי חיפוש למצוא, לסרוק, להבין ולהציג את העמודים שלכם: הגדרות שפה, כתובות קנוניות, מבנה כותרות, נתונים מובנים, מפת אתר, מהירות ונגישות. הוא לא מחליף תוכן טוב, אבל בלעדיו גם תוכן מצוין עלול לא להופיע. באתרים בעברית יש לו כמה בעיות ייחודיות, בעיקר סביב RTL, קידוד כתובות וגופנים.
האם גוגל מבינה עברית טוב?
כן, גוגל מעבדת עברית היטב ומזהה נטיות, כתיב מלא וחסר וסמיכויות. הבעיות שאנחנו רואים כמעט אף פעם אינן בהבנת השפה אלא בהגדרות טכניות שגויות - שפה מוצהרת לא נכונה, כפילות תוכן וכתובות בעייתיות. את אלה אפשר לבדוק ולתקן, בדרך כלל בלי לגעת בתוכן עצמו.
כתובת בעברית או באנגלית - מה עדיף?
מבחינת דירוג טהור אין הבדל משמעותי, וגוגל מפענחת שתיהן. הבעיה עם כתובות בעברית היא מעשית: הן הופכות למחרוזת מקודדת ארוכה כשמעתיקים אותן, ונראות שבורות כשמשתפים בוואטספ או במייל. אנחנו ממליצים על תעתיק לועזי קצר וקריא, שנקבע כבר בהקמת העמוד ולא משתנה אחר כך.
האם FAQ schema עדיין שווה משהו?
כתוצאה מוצגת בגוגל - כמעט לא. מאז אוגוסט 2023 גוגל מציגה תוצאות FAQ מורחבות רק לאתרים סמכותיים של ממשלה ובריאות, ותוצאות HowTo הוסרו. אבל הסימון עצמו עדיין תקין, והוא עוזר למנועי חיפוש ולמערכות AI להבין שבעמוד יש שאלות ותשובות. התנאי הוא שהשאלות והתשובות מופיעות בפועל לגולש בעמוד.
איך מופיעים ב-AI Overviews של גוגל?
לפי גוגל, אין דרישה טכנית מיוחדת: העמוד צריך להיות מאונדקס ומותר להצגה עם קטע תצוגה בתוצאות. מעבר לזה עובדים אותם יסודות של SEO - סריקה פתוחה, תוכן חשוב בטקסט, קישור פנימי, חוויית עמוד טובה ונתונים מובנים שתואמים לתוכן. אף אחד לא יכול להבטיח הופעה, אבל עמודים שעונים ישירות על שאלה ברורה הם מועמדים טבעיים.
צריך קובץ llms.txt?
זה לא נדרש. llms.txt הוא הצעה לא רשמית לקובץ שמסכם את האתר עבור מודלי שפה, וגוגל כותבת במפורש שאין צורך בקבצי טקסט מיוחדים ל-AI כדי להופיע בתכונות ה-AI שלה. אפשר להוסיף אותו כי הוא זול ולא מזיק, אבל הוא לא תחליף לאתר שסריק, מהיר ועם תוכן ברור.
צריך תגית hreflang באתר בעברית בלבד?
לא. hreflang נועד לקשר בין גרסאות שפה שונות של אותו תוכן. באתר חד־לשוני היא מיותרת, ותגית שמצביעה על עצמה בלבד לא מוסיפה דבר. השקיעו במקום זה בהגדרת lang="he" ו-dir="rtl" תקינה בתגית html, ובכתובת קנונית אחת לכל עמוד. אם בעתיד תוסיפו גרסה באנגלית או ברוסית, זה הזמן להוסיף hreflang.
כמה זמן לוקח לתיקונים טכניים להשפיע?
תיקוני אינדוקס וסריקה נקלטים תוך ימים עד שבועות אחרי שגוגל סורקת מחדש, ואפשר לזרז עמודים חשובים דרך בדיקת כתובת ב-Search Console. שיפורי מהירות נכנסים לנתוני השדה בהדרגה על פני כ-28 יום, כי המדידה מבוססת על חלון נע. שינויים במבנה תוכן ובקישור פנימי לוקחים לרוב יותר.
שירות קשור
קידום אורגני (SEO) ונראות בגוגל ובמנועי AI
קידום אורגני הוא הערוץ היחיד שבו ההשקעה מצטברת. פרסום ממומן נעצר ברגע שמפסיקים לשלם; עמוד שדורג טוב ממשיך להביא פניות שנים.
מהשטח
פרויקטים קשורים מתיק העבודות

מולא מנעולים ומפתחות
מנעולן וחנות סלולר בחולון

ZAVUROV & CO.
משרד עורכי דין בפתח תקווה