SEO טכני ב-2026: 14 הפרמטרים שגוגל בוחנת לפני כל דירוג

אני ארתור קלנדרוב, מפיק וידאו ואיש שיווק עם 23 שנות שיווק דיגיטלי ו-12 שנות הפקת וידאו ואנימציה, וגם מתכנת שבונה את הכלים שלו בעצמו. בשמונה השנים האחרונות אני רואה את אותה תופעה חוזרת אצל לקוחות חדשים שמגיעים אליי אחרי שעבדו עם סוכנויות SEO: הם שילמו עשרות אלפי שקלים על תוכן, על בניית קישורים, על כתיבה שיווקית, ושום דבר לא קרה בדירוג. הסיבה כמעט תמיד זהה. אף אחד לא בדק את הצד הטכני של האתר. גוגל לא מצליחה לסרוק חלק גדול מהדפים, התוכן המרכזי נטען לאט מדי, ומפת האתר מציעה מאות דפים שכבר לא קיימים. כל המנגנונים האלה רצים מתחת לפני השטח, ובלעדיהם שום SEO תוכן לא יעבוד. במאמר הזה אני מפרק את 14 הפרמטרים הטכניים שגוגל בודקת לפני שהיא בכלל שוקלת לדרג את התוכן שלכם.

תוכן העניינים 13 פרקים ▾

למה SEO טכני בא לפני SEO תוכן

נתחיל בתרחיש שאני פוגש שוב ושוב באודיטים. חנות WooCommerce עם יותר מאלף מוצרים משלמת לסוכנות במשך יותר משנה על תוכן: מאמרים, דפי קטגוריה וטקסטים למוצרים. התנועה האורגנית לא זזה. באודיט טכני של כמה שעות מתברר שקובץ robots.txt חוסם את כל תיקיית /shop/, תגית ה-canonical של כל וריאציית מוצר מצביעה על דף הבית, ומפת האתר מלאה בכתובות שמחזירות שגיאת 404. במצב כזה גוגל פשוט לא יכולה לסרוק את החנות כמו שצריך.

וזה לא נדיר. מחקר של Ahrefs על כ-14 מיליארד דפים מצא ש-96.55 אחוז מהם לא מקבלים אף ביקור מגוגל. הסיבות העיקריות במחקר הן נושא שאין עליו חיפושים, מעט מדי קישורים נכנסים ותוכן שלא עונה על מה שהגולש מחפש. בעיה טכנית קודמת לכל אלה: דף שגוגל לא מצליחה לסרוק או להכניס לאינדקס לא יקבל תנועה, גם אם כל השאר מושלם. רק אחרי שמסירים את החסמים האלה, התוכן יכול להתחיל לעבוד.

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

Core Web Vitals: LCP, INP, CLS והיעדים שצריך לעבור

במרץ 2024 גוגל החליפה את מדד FID במדד INP (Interaction to Next Paint), שמודד כמה מהר הדף מגיב ללחיצה או להקשה. מאז, מדדי חוויית הדף המרכזיים הם שלושה: LCP, INP ו-CLS. היעדים עצמם לא השתנו: טעינת האלמנט הגדול ביותר (LCP) עד 2.5 שניות, תגובה לפעולה של הגולש (INP) עד 200 מילישניות, ויציבות העימוד (CLS) עד 0.1. המדידה נעשית אצל גולשים אמיתיים, לפי האחוזון ה-75, בנייד ובמחשב בנפרד. לפי Google Search Central, ציון טוב מתיישב עם מה שמערכות הדירוג מנסות לתגמל, אבל הוא לא מבטיח מקום גבוה: תוכן רלוונטי ומועיל עדיין חשוב יותר.

הבעיה: אצל הרבה אתרי וורדפרס, דווקא LCP הוא המדד שנכשל. המסמך הרשמי של web.dev מסביר ש-LCP מודד את הזמן עד שהאלמנט הגדול ביותר ב-viewport הראשון מצויר על המסך – בדרך כלל תמונת hero או כותרת H1. אם הטמפלייט שלכם טוען 18 פלאגינים, 7 פונטים מ-Google Fonts ו-3 ספריות JavaScript לפני שהתמונה בכלל מתחילה לטעון, ה-LCP יחצה את ה-4 שניות בקלות.

איך לתקן ב-2026? קודם כל, מצמצמים את ה-render-blocking resources. CSS critical inline, JavaScript עם defer או async, פונטים עם font-display: swap. שנית, שמים fetchpriority="high" על תמונת ה-hero. שלישית, מעבירים את האתר ל-CDN שמקרב את התוכן למשתמש. רביעית, עוברים על כל תוסף ובוחנים אם הוא באמת חיוני.

אם אתם לא יודעים מאיפה להתחיל, מדריך תיקון Core Web Vitals אצלי מפרט את כל השלבים. בקיצור: עבור LCP, האשם הנפוץ הוא תמונה ראשית כבדה שלא עברה אופטימיזציה, או תמונה ראשית שנטענת מאוחר מדי. טעינה עצלה (lazy loading) מתאימה לתמונות שבהמשך הדף, לא לתמונה הראשית. עבור INP, האשם הוא JavaScript ארוך שחוסם את ה-main thread. עבור CLS, האשם הוא תמונות בלי width ו-height מפורשים, או באנרים שנטענים מאוחר ודוחפים את התוכן למטה.

Schema.org: אילו סימונים עדיין שווים משהו

Schema.org זה הדרך לתת לגוגל מטה-דאטה מובנית על התוכן שלכם. בלי schema, גוגל מנחשת מה הדף הזה. עם schema, היא יודעת בוודאות שזה מאמר, מוצר, שירות, אירוע או FAQ. וכשהיא יודעת, היא יכולה להציג את הדף בתוצאה עשירה (Rich Result): כוכבי דירוג, מחיר, תמונה או נתיב ניווט. תוצאה עשירה בולטת יותר בעמוד ולכן יכולה למשוך יותר הקלקות, אבל גוגל לא מתחייבת להציג אותה גם כשהסימון תקין.

הסוגים שכדאי להכיר, ומה גוגל עושה עם כל אחד היום:

• Article – לכל פוסט בבלוג. כולל headline, author, datePublished, image, publisher.
• FAQPage – לשאלות ותשובות. מ-2023 גוגל הציגה אותן רק לאתרי ממשל ובריאות, ומ-7 במאי 2026 התצוגה הזאת הופסקה לגמרי. אפשר להשאיר את הסימון, אבל לא לצפות ממנו לתצוגה מיוחדת.
• HowTo – למדריכים שלב אחר שלב. גוגל הפסיקה להציג תוצאה עשירה מהסוג הזה ב-2023, כך שאין סיבה להשקיע בו היום.
• Product – לכל מוצר באיקומרס. כולל offer, price, availability, aggregateRating.
• Service – לדפי שירות. כולל provider, areaServed, serviceType. אין לו תוצאה עשירה בגוגל, אבל הוא מתאר את השירות בצורה מובנית.
• LocalBusiness – לעסקים פיזיים: כתובת, טלפון ושעות פתיחה. את המפה ואת תיבת המידע בצד מזין בעיקר פרופיל העסק בגוגל.
• BreadcrumbList – לכל דף שיש מעליו קטגוריות. בתוצאות במחשב מוצג נתיב קריא במקום הכתובת. מינואר 2025 גוגל לא מציגה אותו בנייד.

הטעות הנפוצה: כותבים schema של HowTo על דף שאיננו מדריך, או של Product על דף שאיננו מוצר. גוגל יודעת לזהות את זה, ועלולה לשלול מהאתר תוצאות עשירות או להטיל עליו פעולה ידנית. התיעוד הרשמי של Google Search Central ברור: schema חייבת לתאר את התוכן שמופיע על הדף. אם בסימון יש 8 שאלות אבל בדף מוצגות רק 3, זו הפרה של ההנחיות.

בודקים את ה-schema ב-Rich Results Test של גוגל. אם הכלי מציג שגיאות, מתקנים אותן לפני שמפרסמים. אם הוא מזהה את התוצאה העשירה, מצוין, אבל עדיין צריך לחכות שגוגל תסרוק את הדף מחדש, ואין התחייבות שהתוצאה תוצג.

sitemap.xml – דינמי, מסונן, מחולק

sitemap.xml זה הקובץ שאתם נותנים לגוגל ובו רשימת כל הדפים שאתם רוצים שיאנדקסו. נשמע פשוט, ובוורדפרס זה אכן פשוט – תוסף Yoast או Rank Math יוצר את הקובץ אוטומטית. הבעיה: שני התוספים האלה ברירת המחדל כוללים בקובץ דברים שלא צריכים להיות שם. דפי קטגוריה ריקים, דפי תגיות אוטומטיים, attachment pages, דפי ארכיון של מחברים.

איך נראה sitemap נקי ב-2026? קודם כל, רק דפים שאתם רוצים שיופיעו בתוצאות. דפי שירות, פוסטים בבלוג, מוצרים, דף הבית. בלי דפי תודה, בלי דפי checkout, בלי דפי /author/, בלי /tag/ עם פחות מ-5 פוסטים. שנית, חלוקה לקבצים נפרדים. sitemap-pages.xml, sitemap-posts.xml, sitemap-products.xml, sitemap-services.xml. ככה בדוח מפות האתר ב-Search Console רואים בנפרד כמה דפים מכל סוג נכנסו לאינדקס.

שלישית, lastmod תאריך עדכון אמיתי לכל URL. לא תאריך יצירת הקובץ, אלא תאריך השינוי המשמעותי האחרון של אותו דף. לפי התיעוד של גוגל, היא משתמשת ב-lastmod רק כשהוא מדויק באופן עקבי וניתן לאימות, ומתעלמת לגמרי מהשדות priority ו-changefreq. אם כל הכתובות מציגות את אותו תאריך, קל להבין שהתאריך לא אמין, והוא פשוט לא ישמש.

אצל לקוחות שמשתמשים בוורדפרס אני ממליץ על Rank Math שמטפל ב-sitemap בצורה הטובה ביותר. אצל לקוחות שעברנו ל-Astro, ה-sitemap נוצר אוטומטית מקובץ data ב-build time וכולל רק URLs קיימים בפועל. הסבר מפורט על איך להגיש את הקובץ ולנטר אותו תמצאו ב-הגשת sitemap.

robots.txt ואותות לבוטים של AI

robots.txt זה הקובץ שאומר לגוגל איזה חלקים באתר היא יכולה לסרוק ואיזה לא. בוורדפרס ברירת המחדל סבירה אבל לא מושלמת. בדרך כלל היא חוסמת /wp-admin/ ופותחת את כל השאר. הבעיה: בלי הגדרות מותאמות, גוגל מבזבזת את "תקציב הסריקה" (crawl budget) על דפים חסרי ערך – דפי checkout, דפי תוצאות חיפוש פנימי, parameters של פילטרים.

robots.txt טוב ב-2026 חוסם:

• /wp-admin/ – לוח הניהול
• /?s= – דפי תוצאות חיפוש פנימי
• /cart/, /checkout/ – באתרי איקומרס
• Parameters של filter ו-sort עם Disallow: /*?orderby=

הסבר מלא ושימוש מתקדם ב-ניהול robots.txt. חשוב לזכור: robots.txt מונע סריקה, לא אינדוקס. לפי גוגל, דף חסום עדיין יכול להופיע בתוצאות אם אתרים אחרים מקשרים אליו, ולכן כדי להוציא דף מגוגל משתמשים בתגית noindex. את הקובץ עצמו בודקים היום בדוח robots.txt ב-Search Console, שהחליף בסוף 2023 את הכלי הישן robots.txt Tester.

בשנתיים האחרונות נוסף רובד חדש: איך מסמנים לבוטים של כלי AI מה מותר לעשות עם התוכן. גוגל מציעה את האסימון Google-Extended בקובץ robots.txt, שקובע אם תוכן מהאתר ישמש לאימון מודלי Gemini ולעיגון התשובות שלהם. לפי גוגל, חסימה שלו לא משפיעה על ההופעה בחיפוש ולא על הדירוג. Cloudflare הציעה ב-2025 שורות Content-Signal בתוך robots.txt, שמצהירות על העדפות לגבי חיפוש, אימון מודלים ושימוש בתשובות AI, אבל זו הצהרה ולא חסימה טכנית, ולא כל חברה מכבדת אותה. ערכים כמו noai ו-noimageai לא נתמכים בגוגל בכלל. מה שכן עובד ברמת השרת הוא הכותרת X-Robots-Tag: noindex, שמוציאה מהאינדקס גם קבצים כמו PDF.

canonical tags – מתי, איך, ומה לא לעשות

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

השימושים הקריטיים:

• בעמודי איקומרס עם וריאציות מוצר (צבע, גודל) – canonical על המוצר הראשי
• בעמודי קטגוריה עם עימוד (pagination) – כל עמוד מקבל canonical לעצמו. גוגל ממליצה במפורש לא להפנות את כולם לעמוד 1
• בעמודי PDF זהים לדף HTML – canonical על ה-HTML
• בעמודי tag/category זהים – canonical על הראשי
• בגרסאות www מול בלי www – הפניית 301 לגרסה המועדפת, ו-canonical שתואם לה
• בגרסאות http מול https – הפניית 301 ל-https, ו-canonical על https

הטעויות הנפוצות: canonical מכל דף באתר לדף הבית (גוגל עלולה להתעלם מכל שאר הדפים), canonical שמצביע על כתובת שמחזירה 404 או עוברת שרשרת הפניות, ו-canonical ב-HTML הראשוני שסותר את זה שנוצר אחרי JavaScript. בודקים עם Screaming Frog או Sitebulb. שני הכלים סורקים את האתר ומציגים את כל ה-canonical, וכל סטייה מתגלה תוך דקות.

hreflang לאתרים דו-לשוניים

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

סינטקס נכון:

<link rel="alternate" hreflang="he" href="https://example.com/he/page" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />

שלושה כללים חשובים. ראשון, כל הדפים בקבוצה חייבים להפנות אחד לשני (reciprocal). אם הדף בעברית מציע גרסה אנגלית, הדף האנגלי חייב להציע גרסה עברית. שני, x-default מומלץ מאוד – הוא אומר לגוגל איזה דף להציג אם השפה של המשתמש לא תואמת לאף אחת מהאפשרויות. שלישי, hreflang לא מחליף canonical. אתם צריכים את שניהם.

איך מאמתים? דוח International Targeting הוסר מ-Search Console ב-2022, ולכן היום בודקים עם כלי סריקה כמו Screaming Frog, שמציג תגיות hreflang חסרות, הפניות שאינן הדדיות וקודי שפה שגויים. אם אתם משתמשים בוורדפרס ובתוסף WPML או Polylang, ההגדרה אוטומטית. אם אתם בנויים על Astro או Next.js, צריך להגדיר ידנית במטה-תגים.

JavaScript rendering – Astro מול WordPress

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

זאת אחת הסיבות המרכזיות שאני ממליץ לרוב לקוחותיי לעבור מ-WordPress ל-Astro. Astro פותר חלק גדול מבעיות ה-SEO הטכני בארכיטקטורה עצמה – HTML סטטי שנוצר ב-build time, JavaScript רק במקומות שצריך אינטראקטיביות (Islands Architecture), CSS critical inline. גוגל סורקת את ה-HTML פעם אחת ומקבלת את כל התוכן.

בוורדפרס המצב מורכב יותר. אם חלק מהתוכן נטען רק אחרי שהדף עולה, למשל רכיבים שמושכים נתונים ב-AJAX, הוא לא נמצא ב-HTML הראשוני. אצל גוגל זו בדרך כלל לא בעיה, כי היא מריצה JavaScript. אצל הסורקים של כלי AI זו כן בעיה: בדיקה של Vercel מצאה שהסורקים של OpenAI, Anthropic ו-Perplexity לא מריצים JavaScript, ולכן הם רואים רק את מה שנמצא ב-HTML.

אם אתם רוצים להבין את ההבדלים, המדריך לאסטרו מפרט מה Astro עושה אחרת ולמה זה משנה ל-SEO ב-2026. בקיצור: אם האתר שלכם איטי או לא מתאנדקס היטב, JavaScript rendering הוא בדרך כלל החשוד הראשון.

אינדוקס: למה גוגל לא מציגה דפים שאתם מפרסמים

זה מצב שאני פוגש כמעט בכל אודיט. הלקוח אומר "פרסמתי עשרות מאמרים בשנה האחרונה, ורק חלק קטן מהם מופיע בתוצאות". פותחים ב-Search Console את הדוח Page indexing (שנקרא בעבר Coverage), ורואים שבאמת רק חלק מהדפים באינדקס. השאר מופיעים תחת Not indexed, עם סיבות שונות: Discovered – currently not indexed, Crawled – currently not indexed, Duplicate without user-selected canonical, Soft 404.

למה זה קורה?

• Discovered – currently not indexed – גוגל יודעת על הדף אבל לא הקצתה לו זמן לסרוק. בדרך כלל אתר חדש או דף עם מעט סמכות.
• Crawled – currently not indexed – גוגל סרקה אבל החליטה שלא לאנדקס. תוכן דק, ספאם, או דמיון יתר לדף אחר.
• Duplicate without user-selected canonical – גוגל זיהתה כפילות והחליטה לבחור גרסה אחרת בעצמה.
• Soft 404 – הדף מחזיר 200 אבל גוגל זיהתה שהוא ריק או חסר ערך.
• Excluded by 'noindex' tag – יש לכם תג noindex בדף, בדרך כלל מהתוסף Yoast או מטעות בקוד.

הפתרון לכל אחד מהמקרים שונה. לדף שהתגלה ועוד לא נסרק, מוסיפים קישורים פנימיים ומחכים. לדף שנסרק ולא נכנס לאינדקס, מרחיבים את התוכן ומשפרים את האיכות. לכפילות, מגדירים canonical ברור. עבור Soft 404, מתקנים את התוכן או מוחקים את הדף. ניטור Search Console מסביר איך להגדיר התראות שמודיעות כשדף נופל מהאינדקס.

מובייל-פירסט indexing ב-2026

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

הבעיות הנפוצות:

• תוכן מוסתר במובייל בתוך accordion שלא נטען עד הקלקה
• תמונות עם רזולוציה נמוכה במובייל (גוגל סורקת אותן ולא את הגדולות)
• טקסט קטן מדי, שקשה לקרוא בטלפון בלי להגדיל
• כפתורים וקישורים צפופים מדי (Lighthouse ממליץ על אזור לחיצה של 48 על 48 פיקסלים לפחות)
• תוכן שגלוי רק עם hover (hover לא קיים במובייל)

דוח Mobile Usability הוסר מ-Search Console בסוף 2023, ולכן בודקים היום עם PageSpeed Insights במצב Mobile ועם Lighthouse בכרום. ציון הביצועים של Lighthouse הוא כלי אבחון ולא מדד דירוג: 90 ומעלה נחשב טוב, ומתחת ל-50 יש בעיות מבניות שכדאי לתקן לפני כל השקעה בתוכן.

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

structured data לאיקומרס: Product + Offer + AggregateRating

אם אתם מנהלים חנות איקומרס, ה-structured data של המוצרים זה ההבדל בין מוצר שמופיע בגוגל עם כוכבים, מחיר ותמונה (Rich Result) לבין מוצר שמופיע כשורה משעממת. תוצאה עשירה בולטת יותר בעמוד התוצאות, ולכן יש לה סיכוי טוב יותר למשוך את העין.

המבנה המומלץ:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "שם המוצר",
  "image": ["url1", "url2"],
  "description": "תיאור המוצר",
  "sku": "SKU-123",
  "brand": {"@type": "Brand", "name": "שם המותג"},
  "offers": {
    "@type": "Offer",
    "price": "199.00",
    "priceCurrency": "ILS",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/product"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "127"
  }
}

הטעות הנפוצה: כותבים aggregateRating בלי ביקורות אמיתיות. ההנחיות של גוגל לקטעי ביקורות דורשות שהדירוג ישקף ביקורות אמיתיות שמוצגות לגולשים בדף, ובקיץ 2026 נוספה להן הנחיה מפורשת נגד ביקורות מזויפות וביקורות שניתן עליהן תמריץ בלי גילוי. אם אין לכם מערכת ביקורות של קונים על דף המוצר, אל תכתבו aggregateRating בכלל. עדיף בלי תוצאה עשירה מאשר פעולה ידנית.

מעבר לזה, כדאי לכלול ב-Offer את השדה availability עם ערך של schema.org (InStock, OutOfStock, PreOrder). אם המוצר חסר במלאי, הצהירו על זה. מידע מדויק על זמינות עדיף על קונה שמגלה בדף שהמוצר בכלל לא זמין.

ניטור עם Search Console URL Inspection

Search Console URL Inspection זה הכלי החזק ביותר שגוגל מספקת בחינם. מזינים URL ספציפי וגוגל מציגה בדיוק מה היא רואה: האם הדף מאונדקס, מה גרסת ה-HTML שהיא קראה, מה ה-canonical שהיא בחרה, אילו תוצאות עשירות היא מזהה, אילו שגיאות יש.

שלוש דרכים שבהן אני משתמש בו כל שבוע אצל לקוחות:

1. אחרי פרסום דף חדש – מזינים את ה-URL, לוחצים "Request Indexing", והדף נכנס לתור הסריקה. לפי גוגל, הסריקה יכולה לקחת בין כמה ימים לכמה שבועות, והבקשה לא מבטיחה שהדף ייכנס לאינדקס.
2. בדיקת ה-canonical שגוגל בחרה – לפעמים גוגל בוחרת canonical שונה ממה שהצהרתם. הכלי מציג איזה URL היא רואה כראשי.
3. בדיקת רינדור – לוחצים "View Crawled Page" ורואים בדיוק את ה-HTML שגוגל קיבלה. אם חסר תוכן שאתם רואים בדפדפן, יש בעיית JavaScript rendering.

מעבר לזה, יש Live Test – גוגל מורידה את הדף בזמן אמת ומציגה את ה-HTML הנוכחי. שימושי כשתיקנתם משהו ורוצים לוודא שהתיקון תופס לפני ש"מבזבזים" Request Indexing.

אצל הלקוחות שלי, ניטור Search Console רץ באופן קבוע, ואני מקבל התראה כשדף נופל מהאינדקס, כשמופיעה בעיה במדדי חוויית הדף, או כשהתנועה צונחת בחדות. בלי ניטור כזה, צריך להיכנס לדוחות ידנית.

סיכום: מאיפה מתחילים

14 הפרמטרים שעברנו עליהם – Core Web Vitals, schema, sitemap, robots.txt, canonical, hreflang, JavaScript rendering, אינדוקס, מובייל-פירסט, structured data, ניטור – הם המכנה המשותף של כל אתר שמצליח אורגנית ב-2026. בלעדיהם, חלק גדול מההשקעה בתוכן ובקישורים פשוט הולך לאיבוד. עם כולם, התוכן שלכם מקבל את ההזדמנות שמגיעה לו.

הסיבה שהרבה סוכנויות לא נוגעות ב-SEO טכני היא פשוטה: זה דורש ידע בקוד, בפרוטוקולים ובארכיטקטורה. הרבה סוכנויות בישראל הן צוותי שיווק, לא צוותי פיתוח. אצלי השילוב הזה הוא הליבה – 23 שנות שיווק דיגיטלי, 12 שנות הפקת וידאו ואנימציה, ועוד שנים של תכנות שבזכותו אני בונה את הכלים שאני משתמש בהם. אני רואה את האתר גם כצינור שיווק וגם כתוכנה.

אם אתם רוצים לדעת איפה האתר שלכם עומד מהבחינה הטכנית, שירות SEO טכני שוטף מתחיל ב-₪400 לחודש, לפני מע״מ וללא דמי הקמה, וכולל אודיט ראשוני, תיקונים שוטפים ודוח חודשי. אם תרצו לטפל בהכול יחד, חבילות הקידום האורגני מתחילות ב-₪750 לחודש ומשלבות את הצד הטכני עם תוכן וקישורים.

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