6 שלב 2 — SEO אורגני

Technical SEO — קידום טכני

הבסיס הטכני שבלעדיו אף תוכן לא ידורג. Core Web Vitals, מהירות אתר, Mobile-First Indexing, ארכיטקטורת אתר, Schema Markup, Sitemap, Robots.txt, קאנוניקל, Hreflang, ועוד — מדריך מקיף עם הוראות צעד-אחר-צעד.

מה זה Technical SEO ולמה זה חשוב

Technical SEO הוא המערכת הטכנית שמאפשרת לגוגל למצוא, לזחול (Crawl), לאנדקס (Index) ולהבין את האתר שלכם. חשבו על זה כמו התשתית של בניין — אתם יכולים לעצב את הדירה הכי יפה בעולם, אבל אם היסודות רעועים, הכל קורס.

53%

מהמבקרים באתר נוטשים דף שלוקח לו יותר מ-3 שניות להיטען. מהירות האתר משפיעה ישירות על דירוג, חוויית משתמש, ושיעור המרה.

Technical SEO כולל מגוון רחב של נושאים, אבל אפשר לחלק אותם לשלוש קטגוריות עיקריות:

אזהרה: Technical SEO לפני הכל

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

מהירות אתר ו-Core Web Vitals

מהירות האתר הוא אחד מגורמי הדירוג הכי חשובים ב-2026. גוגל מודדת מהירות באמצעות Core Web Vitals — שלושה מדדים ספציפיים שמשקפים את חוויית המשתמש בטעינת הדף:

שלושת ה-Core Web Vitals

1. LCP — Largest Contentful Paint

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

2. INP — Interaction to Next Paint

מדד שהחליף את FID (First Input Delay) במרץ 2024. INP מודד את הזמן מהרגע שהמשתמש עושה אינטראקציה עם הדף (קליק, הקשה, הקלדה) עד שהדפדפן מצליח לעדכן את התצוגה. המטרה: מתחת ל-200 מילישניות. גורמים שפוגעים: JavaScript כבד שחוסם את ה-Main Thread, Third-party scripts (צ'אט, אנליטיקס, פיקסלים), DOM גדול מדי עם אלפי אלמנטים.

3. CLS — Cumulative Layout Shift

מודד כמה אלמנטים "קופצים" בדף בזמן הטעינה. כשתמונה נטענת ודוחפת טקסט למטה, או כשפרסומת מופיעה ומזיזה תוכן — זה CLS. המטרה: מתחת ל-0.1. גורמים שפוגעים: תמונות ללא width/height מוגדרים, פונטים שנטענים ומשנים את הגודל, פרסומות שנטענות מאוחר, תוכן שנוסף דינמית ללא מקום שמור.

מדד טוב (ירוק) צריך שיפור (כתום) גרוע (אדום)
LCP ≤ 2.5 שניות 2.5-4 שניות > 4 שניות
INP ≤ 200ms 200-500ms > 500ms
CLS ≤ 0.1 0.1-0.25 > 0.25
טיפ: איפה בודקים Core Web Vitals?

שלושה מקורות עיקריים: (1) Google Search Console → Core Web Vitals report — מראה נתונים אמיתיים מביקורי משתמשים. (2) PageSpeed Insights (pagespeed.web.dev) — בדיקה של דף בודד עם נתוני שדה (Field Data) ונתוני מעבדה (Lab Data). (3) Chrome DevTools → Lighthouse — בדיקת מעבדה מפורטת.

מתכוני תיקון — Fix Recipes לכל מדד

הנה מדריך מעשי ומפורט לתיקון כל מדד Core Web Vitals. בצעו את השלבים לפי הסדר — כל שלב מסודר מהפעולה עם ההשפעה הגדולה ביותר לקטנה ביותר.

מתכון תיקון LCP — Largest Contentful Paint

1

שפרו את זמן התגובה של השרת (TTFB)

TTFB (Time to First Byte) הוא הזמן עד שהשרת מתחיל להחזיר נתונים. מטרה: מתחת ל-800ms. פתרונות: (1) הפעילו CDN כמו Cloudflare — זה לבד יכול לחסוך 50%+ מהזמן. (2) הפעילו Server-Side Caching. (3) שדרגו את תוכנית האחסון — שרת משותף (Shared Hosting) הוא לעתים קרובות צוואר הבקבוק. (4) בדקו ב-Chrome DevTools → Network Tab את ה-TTFB של הדף הראשי.

2

אופטימיזציה של תמונת ה-LCP

זהו את אלמנט ה-LCP (בדרך כלל התמונה הראשית / Hero Image) דרך PageSpeed Insights או Chrome DevTools → Performance Tab. אז: (1) המירו ל-WebP/AVIF. (2) דחסו לגודל מינימלי ללא פגיעה באיכות (Squoosh). (3) הגדירו width ו-height מפורשים. (4) הוסיפו fetchpriority="high" לתגית img. (5) אל תשימו loading="lazy" על אלמנט ה-LCP. (6) שקלו Preload: <link rel="preload" as="image" href="hero.webp">.

3

הסירו Render-Blocking Resources

(1) העבירו CSS קריטי (Above the Fold) ל-Inline בתוך <style> ב-head. (2) טענו את שאר ה-CSS באופן אסינכרוני: <link rel="stylesheet" href="style.css" media="print" onload="this.media='all'">. (3) הוסיפו defer לכל סקריפט JavaScript שאינו קריטי. (4) בדקו עם Lighthouse אילו Resources חוסמים.

4

Preconnect ל-Third-Party Origins

אם ה-LCP תלוי בפונטים מגוגל או בתמונות מ-CDN חיצוני, הוסיפו: <link rel="preconnect" href="https://fonts.googleapis.com">. זה חוסך את זמן ה-DNS lookup וה-TLS handshake — יכול לחסוך 100-300ms.

מתכון תיקון INP — Interaction to Next Paint

1

זהו סקריפטים שחוסמים את Main Thread

פתחו Chrome DevTools → Performance Tab → הקליטו 5 שניות של שימוש. חפשו "Long Tasks" (משימות מעל 50ms שצבועות באדום). הם הגורם מספר 1 ל-INP גרוע. פתרונות: (1) פצלו Long Tasks לחלקים קטנים עם requestIdleCallback או scheduler.yield(). (2) הסירו JavaScript שאינו בשימוש (בדקו ב-DevTools → Coverage). (3) העבירו סקריפטים כבדים ל-Web Worker.

2

אופטימיזציה של Third-Party Scripts

סקריפטים חיצוניים (צ'אט, אנליטיקס, פיקסלים, פרסומות) הם הרוצח השקט של INP. פתרונות: (1) טענו דרך Google Tag Manager עם Trigger של "Window Loaded" — לא "Page View". (2) השתמשו ב-Partytown (ספריית JS) שמעבירה Third-Party Scripts ל-Web Worker. (3) הגבילו את מספר הסקריפטים ל-5 מקסימום — כל אחד נוסף מאט את האתר.

3

הקטינו את ה-DOM

DOM עם יותר מ-1,500 אלמנטים מתחיל לפגוע ב-INP. פתרונות: (1) הסירו HTML מיותר (Divs ריקים, Wrappers מיותרים). (2) השתמשו ב-content-visibility: auto ב-CSS כדי לדחות רנדור של סקשנים שלא נראים. (3) ב-Infinite Scroll — הסירו אלמנטים ישנים מה-DOM כשנטענים חדשים.

מתכון תיקון CLS — Cumulative Layout Shift

1

הגדירו מימדים לכל מדיה

הגורם מספר 1 ל-CLS: תמונות וסרטונים ללא width/height מוגדרים. פתרונות: (1) הוסיפו width ו-height לכל <img> ו-<video>. (2) השתמשו ב-CSS aspect-ratio לשמירה על יחס. (3) עבור תמונות רספונסיביות עם srcset — עדיין הגדירו מימדים בסיסיים.

2

שמרו מקום לפרסומות ו-Embeds

פרסומות, Iframes, וVideoEmbeds שנטענים מאוחר דוחפים תוכן למטה. פתרון: (1) הגדירו min-height לקונטיינר של הפרסומת לפני שהיא נטענת. (2) עבור Google AdSense, השתמשו ב-data-ad-format="auto" עם min-height: 250px. (3) עבור YouTube embeds — עטפו ב-Container עם aspect-ratio: 16/9.

3

טפלו בפונטים

Web Fonts שנטענים מאוחר גורמים ל-FOUT (Flash of Unstyled Text) שמשנה את ה-Layout. פתרונות: (1) הוסיפו font-display: swap ב-@font-face. (2) Preload את הפונטים הקריטיים: <link rel="preload" as="font" href="font.woff2" crossorigin>. (3) שקלו להשתמש בפונטים של מערכת ההפעלה (system-ui) לטקסט body — הם נטענים מיד.

טיפ: Debug CLS בפועל

כדי לראות בדיוק מה גורם ל-CLS, פתחו Chrome DevTools → Rendering Tab → סמנו "Layout Shift Regions". עכשיו גללו את הדף — כל אלמנט שקפץ ייצבע בכחול. זו הדרך הכי מהירה לזהות את הבעיות.

מקרה בוחן: תיקון CWV לאתר מסחרי ישראלי

האתר: חנות אונליין לביגוד, 2,500 דפי מוצר, WordPress + WooCommerce
לפני: LCP: 4.8s, INP: 380ms, CLS: 0.32 — הכל אדום
שלב 1: הפעלת Cloudflare CDN + Browser Caching → LCP ירד ל-3.2s
שלב 2: המרת כל התמונות ל-WebP + דחיסה → LCP ירד ל-2.1s
שלב 3: הסרת 4 תוספי WordPress מיותרים + דחיית JS → INP ירד ל-180ms
שלב 4: הוספת width/height לכל תמונות המוצרים + שמירת מקום לפרסומות → CLS ירד ל-0.06
תוצאה: כל המדדים ירוקים. ציון PSI עלה מ-28 ל-89. תנועה אורגנית עלתה ב-22% תוך 8 שבועות.

PageSpeed Insights — הדרכה מלאה

PageSpeed Insights (PSI) הוא הכלי החינמי של גוגל לבדיקת מהירות אתר. הכנסו ל-pagespeed.web.dev, הזינו כתובת URL, ותקבלו ניתוח מלא. ככה קוראים את הדוח:

Field Data vs Lab Data

Field Data (נתוני שדה) מגיע ממשתמשים אמיתיים שביקרו באתר ב-28 הימים האחרונים (מ-Chrome UX Report). זה המדד שגוגל משתמשת בו לדירוג. Lab Data (נתוני מעבדה) נמדד על ידי Lighthouse בסביבה מבוקרת — הוא שימושי לדיבוג אבל לא משפיע ישירות על דירוג.

ציון הביצועים (0-100)

המלצות נפוצות וכיצד לטפל בהן

Eliminate render-blocking resources

CSS ו-JavaScript שחוסמים את הרנדור של הדף. הפתרון: העבירו CSS קריטי ל-Inline, טענו את שאר ה-CSS באופן אסינכרוני (media="print" onload), והוסיפו defer או async ל-JavaScript שאינו קריטי.

Properly size images

תמונות שנטענות בגודל גדול יותר מהנדרש. הפתרון: השתמשו בתמונות בגודל מדויק, והוסיפו srcset לתמונות Responsive.

Serve images in next-gen formats

השתמשו ב-WebP או AVIF במקום JPEG/PNG. פורמטים מודרניים קטנים ב-30-50% ללא ירידה באיכות.

Reduce unused JavaScript / CSS

קוד שנטען אבל לא בשימוש. הפתרון: בצעו Code Splitting, הסירו ספריות שאינן בשימוש, ובדקו ב-Chrome DevTools → Coverage מה באמת נמצא בשימוש.

Enable text compression

הפעילו דחיסת Gzip או Brotli בשרת. Brotli דוחס טוב יותר ב-15-20% מ-Gzip. רוב ספקי אחסון והפלטפורמות התומכות מפעילים את זה אוטומטית (Cloudflare, Vercel, Netlify).

דוגמה מעשית: שיפור מהירות מ-35 ל-92

אתר של חנות אופנה עם ציון PSI של 35 (אדום):
בעיה 1: תמונות JPEG בגודל 3MB — פתרון: המרה ל-WebP + דחיסה → 200KB
בעיה 2: 15 סקריפטים של Third-party (פייסבוק, גוגל אנליטיקס, צ'אט, פיקסלים) — פתרון: טעינה דחויה עם GTM
בעיה 3: שרת איטי (TTFB 2.3 שניות) — פתרון: מעבר ל-CDN (Cloudflare)
בעיה 4: CSS ו-JS בלתי מנוצלים (400KB) — פתרון: ניקוי + Code Splitting
תוצאה: ציון PSI קפץ ל-92, LCP ירד מ-5.2 ל-1.8 שניות, CLS ירד מ-0.35 ל-0.05.

אופטימיזציה של תמונות

תמונות הן בדרך כלל הגורם מספר 1 לאיטיות אתר. דף ממוצע מכיל 50-60% של משקל בתמונות. אופטימיזציה נכונה של תמונות יכולה להוריד את זמן הטעינה בצורה דרמטית.

פורמטים מומלצים ב-2026

פורמט שימוש מומלץ תמיכה בדפדפנים הערות
WebP תמונות כלליות, צילומים 97%+ מהדפדפנים ברירת המחדל המומלצת
AVIF תמונות באיכות גבוהה 92%+ מהדפדפנים דחיסה טובה מ-WebP ב-20%
SVG לוגואים, אייקונים, גרפיקה 100% וקטורי — לא מאבד איכות בהגדלה
JPEG Fallback לדפדפנים ישנים 100% משתמשים רק כגיבוי

Lazy Loading — טעינה עצלה

Lazy Loading אומר שתמונות שלא נראות על המסך (below the fold) נטענות רק כשהמשתמש גולל אליהן. זה חוסך זמן טעינה ראשונית משמעותי. ב-HTML5 מודרני, הוספת loading="lazy" לתגית img מספיקה. חשוב: אל תשימו Lazy Loading על התמונה הראשית (LCP element) — היא צריכה להיטען מיד.

Responsive Images עם srcset

אל תטענו תמונה ברוחב 2000px למשתמש מובייל עם מסך של 375px. השתמשו ב-srcset כדי לספק תמונות בגדלים שונים:

דוגמת קוד: srcset

<img src="product-800.webp" srcset="product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w" sizes="(max-width: 768px) 100vw, 50vw" alt="תיאור המוצר" width="800" height="600" loading="lazy">

כלי אופטימיזציה

Mobile-First Indexing

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

מה Mobile-First Indexing אומר בפועל

בדיקת תאימות למובייל

טיפ: Target לגודל Touch

וודאו שכל אלמנט לחיץ (כפתור, לינק, אינפוט) הוא לפחות 48x48 פיקסלים עם מרווח של 8px מאלמנטים לחיצים אחרים. אצבע אנושית היא גדולה מ-Mouse pointer — אם הכפתורים קטנים מדי או צפופים מדי, המשתמשים ינטשו.

צ'קליסט Mobile-First לאתרים ישראליים

מעבר לבדיקות הבסיסיות, הנה צ'קליסט מקיף שמכסה את כל ההיבטים של Mobile-First Indexing, כולל שיקולים ייחודיים לאתרים בעברית:

תוכן ומבנה

ביצועים במובייל

בעיות נפוצות באתרים ישראליים במובייל

בעיה שכיחות פתרון
כפתור WhatsApp צף חוסם תוכן גבוהה מאוד מקמו בפינה תחתונה-שמאלית, גודל 56px, עם מרווח מתוכן
Pop-Up שחוסם את כל המסך במובייל גבוהה גוגל מענישה Intrusive Interstitials. השתמשו בבאנר קטן או Bottom Sheet
תמונות Hero שלא מתכווצות בינונית השתמשו ב-object-fit: cover + max-width: 100%
טקסט קטן מדי בינונית מינימום 16px לטקסט body. בעברית, 17-18px עדיף בגלל צפיפות התווים
Horizontal Scroll (גלילה אופקית) בינונית הוסיפו overflow-x: hidden ל-body ובדקו אלמנטים שחורגים
אזהרה: Intrusive Interstitials — פופ-אפים פולשניים

גוגל מענישה אתרים שמציגים פופ-אפים שחוסמים את כל המסך במובייל ברגע שהמשתמש נכנס לדף (Intrusive Interstitials). זה כולל: פופ-אפ מייל ליסט שמכסה את כל הדף, מודעות ביניים (Interstitial Ads), ו-"הירשמו לניוזלטר" שמופיע מיד. מותר: באנרים קטנים בתחתית המסך, הודעות Consent (חוקיות כמו עוגיות), Login walls לתוכן פרימיום.

HTTPS — אבטחה כחובה

HTTPS (HyperText Transfer Protocol Secure) מצפין את התקשורת בין הדפדפן של המשתמש לשרת שלכם. מאז 2014 גוגל הכריזה על HTTPS כגורם דירוג, ומאז 2018 Chrome מסמן אתרי HTTP כ-"Not Secure" — מה שמרתיע מבקרים.

מה צריך לעשות

ארכיטקטורת אתר ומבנה URL

ארכיטקטורת האתר קובעת איך דפים מאורגנים וכיצד Googlebot (וגם משתמשים) מנווטים ביניהם. ארכיטקטורה טובה מאפשרת לגוגל לזחול את כל הדפים ביעילות ומעבירה "סמכות" (Link Equity) מדף הבית לכל חלקי האתר.

Flat vs Deep Architecture

ארכיטקטורה שטוחה (Flat) מאפשרת להגיע לכל דף ב-3 קליקים או פחות מדף הבית. ארכיטקטורה עמוקה (Deep) דורשת 5+ קליקים. ב-SEO, שטוח עדיף — גוגל נותנת משקל רב יותר לדפים שקרובים לדף הבית.

מבנה מומלץ לאתר עסקי

רמה 1: דף הבית (domain.co.il/)
רמה 2: קטגוריות ראשיות (domain.co.il/services/, domain.co.il/blog/, domain.co.il/about/)
רמה 3: דפים ספציפיים (domain.co.il/services/seo/, domain.co.il/blog/keyword-research-guide/)
רמה 4 (מקסימום): תתי-דפים (domain.co.il/services/seo/local-seo/)

Best Practices למבנה URL

Breadcrumbs — נתיב ניווט

Breadcrumbs ("פירורי לחם") הם נתיב הניווט שמופיע בראש הדף, לדוגמה: דף הבית > שירותים > קידום אתרים. הם חשובים ל-SEO מכמה סיבות: מספקים קישורים פנימיים, עוזרים לגוגל להבין את מבנה האתר, משפרים את חוויית המשתמש, ומופיעים ב-SERP (תוצאות החיפוש). השתמשו ב-Schema Markup מסוג BreadcrumbList כדי שגוגל תציג את ה-Breadcrumbs בתוצאות.

XML Sitemap — יצירה והגשה

XML Sitemap הוא קובץ שמפרט את כל הדפים באתר שאתם רוצים שגוגל תאנדקס. הוא כמו "מפה" שאתם נותנים ל-Googlebot כדי שתדע אילו דפים קיימים.

מה לכלול ב-Sitemap

יצירה והגשה

טיפ: הפנו ל-Sitemap מ-Robots.txt

הוסיפו שורה בקובץ robots.txt שמפנה ל-Sitemap: Sitemap: https://domain.co.il/sitemap.xml. גוגל תמצא את ה-Sitemap גם בלי הגשה ידנית ב-Search Console.

Robots.txt — הגדרות זחילה

קובץ robots.txt נמצא בשורש האתר (domain.co.il/robots.txt) ואומר ל-Crawlers אילו חלקים של האתר הם רשאים לזחול ואילו לא. זה לא חוסם אינדוקס (לשם כך צריך noindex), אבל הוא מונע מגוגל לבקר בדפים מסוימים.

מבנה בסיסי

דוגמה: robots.txt סטנדרטי

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /search?
Disallow: /thank-you/

Sitemap: https://domain.co.il/sitemap.xml

טעויות נפוצות ב-Robots.txt

תגיות Canonical — מניעת תוכן כפול

תגית Canonical (rel="canonical") אומרת לגוגל: "הדף הזה הוא גרסה כפולה או דומה לדף אחר — בבקשה התייחסי לדף המקורי הזה לצורכי דירוג." זה קריטי כי תוכן כפול (Duplicate Content) מבלבל את גוגל ומפצל את ה-Ranking Signals.

מתי צריך Canonical?

אזהרה: Self-Referencing Canonical

כל דף באתר צריך תגית Canonical שמצביעה על עצמו — זה נקרא Self-Referencing Canonical. גם אם אין לכם בעיית תוכן כפול, זה Best Practice שמונע בעיות עתידיות. ודאו שכל CMS שלכם מייצר את זה אוטומטית (Yoast, Rank Math, ועוד עושים זאת).

Hreflang — אתרים רב-לשוניים

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

מתי צריך Hreflang?

איך להטמיע

דוגמה: Hreflang לעמוד דו-לשוני

בתוך ה-<head> של הדף העברי:
<link rel="alternate" hreflang="he" href="https://domain.co.il/services/" />
<link rel="alternate" hreflang="en" href="https://domain.co.il/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://domain.co.il/en/services/" />

x-default מציין את ברירת המחדל למשתמשים שאינם מתאימים לאף שפה.

טעויות נפוצות ב-Hreflang

Schema Markup — נתונים מובנים (JSON-LD)

Schema Markup הוא קוד שמוסיפים לדף ואומר לגוגל בדיוק מה המידע בדף: האם זה עסק מקומי? מוצר עם מחיר? מתכון? שאלות נפוצות? כשגוגל מבינה את המידע, היא יכולה להציג Rich Results — תוצאות מועשרות עם כוכבים, מחירים, תמונות ועוד, שמגדילות את ה-CTR בצורה משמעותית.

סוגי Schema חשובים לעסקים

LocalBusiness

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

Product

לחנויות אונליין. כולל: שם מוצר, מחיר, זמינות, ביקורות, דירוג. מאפשר הצגת מחיר וכוכבים בתוצאות החיפוש ושימוש ב-Google Shopping.

FAQ

לדפים עם שאלות נפוצות. גוגל יכולה להציג את השאלות והתשובות ישירות בתוצאות — מקבלים מקום רב יותר ב-SERP.

HowTo

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

Article

למאמרי בלוג וחדשות. כולל: כותרת, תאריך פרסום, מחבר, תמונה ראשית.

Review / AggregateRating

לביקורות ודירוגים. מאפשר הצגת כוכבים בתוצאות — מגדיל CTR בצורה משמעותית (לפי מחקרים, כוכבים מגדילים CTR ב-35% בממוצע).

איך להוסיף Schema

הדרך המומלצת היא JSON-LD — סקריפט שמוסיפים ל-<head> של הדף. דוגמה ל-LocalBusiness:

דוגמה: JSON-LD עבור LocalBusiness

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "שם העסק",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "רחוב הרצל 15",
    "addressLocality": "תל אביב",
    "postalCode": "6120101",
    "addressCountry": "IL"
  },
  "telephone": "+972-3-1234567",
  "openingHours": "Mo-Fr 09:00-18:00",
  "url": "https://www.example.co.il"
}
</script>

דוגמאות Schema נוספות לעסקים ישראליים

FAQ Schema — שאלות נפוצות

דוגמה: JSON-LD עבור FAQ

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "כמה עולה קידום אתרים בישראל?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "עלות קידום אתרים בישראל נעה בין 2,000 ל-15,000 ש\"ח בחודש, תלוי בהיקף הפרויקט ורמת התחרות. עסק קטן מקומי ישלם בממוצע 3,000-5,000 ש\"ח."
    }
  }, {
    "@type": "Question",
    "name": "כמה זמן לוקח לראות תוצאות ב-SEO?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "בדרך כלל 3-6 חודשים לתוצאות ראשוניות ו-6-12 חודשים לתוצאות משמעותיות. ביטויים עם תחרות נמוכה יכולים לדרג תוך שבועות."
    }
  }]
}
</script>

FAQ Schema מאפשר הצגת שאלות ותשובות ישירות בתוצאות החיפוש — הדף שלכם מקבל "נדל"ן" נוסף ב-SERP שמגדיל CTR משמעותית. שימו לב: גוגל צמצמה את הצגת FAQ Rich Results ב-2023 — כעת הם מוצגים בעיקר לאתרים ממשלתיים ובריאותיים סמכותיים, אבל עדיין כדאי להטמיע כי זה עוזר ל-AI Overviews לצטט אתכם.

Product Schema — מוצר עם מחיר ודירוג

דוגמה: JSON-LD עבור Product

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "ספה פינתית נפתחת למיטה עם אחסון",
  "image": "https://example.co.il/images/sofa-pinatit.webp",
  "description": "ספה פינתית מעוצבת, נפתחת למיטה זוגית, עם תא אחסון גדול. ריפוד בד איכותי.",
  "brand": {"@type": "Brand", "name": "רהיטי הבית"},
  "offers": {
    "@type": "Offer",
    "price": "3490",
    "priceCurrency": "ILS",
    "availability": "https://schema.org/InStock",
    "url": "https://example.co.il/sofas/pinatit-niftatat"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "89"
  }
}
</script>

Product Schema מאפשר הצגת מחיר, זמינות, וכוכבי דירוג בתוצאות — קריטי לחנויות אונליין. מחקרים מראים שתוצאות עם כוכבים מקבלות CTR גבוה ב-35% בממוצע מתוצאות ללא כוכבים.

BreadcrumbList Schema

דוגמה: JSON-LD עבור Breadcrumbs

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "דף הבית",
    "item": "https://example.co.il/"
  }, {
    "@type": "ListItem",
    "position": 2,
    "name": "שירותים",
    "item": "https://example.co.il/services/"
  }, {
    "@type": "ListItem",
    "position": 3,
    "name": "קידום אתרים",
    "item": "https://example.co.il/services/seo/"
  }]
}
</script>

Service Schema — לספקי שירותים

דוגמה: JSON-LD עבור Service

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "קידום אתרים",
  "provider": {
    "@type": "LocalBusiness",
    "name": "שם הסוכנות",
    "address": {"@type": "PostalAddress", "addressLocality": "תל אביב", "addressCountry": "IL"}
  },
  "areaServed": {"@type": "Country", "name": "Israel"},
  "description": "שירותי קידום אתרים מקצועי לעסקים בישראל. מחקר מילות מפתח, אופטימיזציה טכנית, בניית קישורים, ויצירת תוכן.",
  "offers": {
    "@type": "Offer",
    "price": "3000",
    "priceCurrency": "ILS"
  }
}
</script>

טיפ: סדר עדיפויות להטמעת Schema

לא צריך להטמיע הכל ביום אחד. סדר מומלץ: (1) LocalBusiness — חובה לכל עסק מקומי. (2) BreadcrumbList — קל להטמעה, שיפור מיידי ב-SERP. (3) FAQ — לדפים עם שאלות נפוצות. (4) Product — לחנויות אונליין. (5) Article — למאמרי בלוג. (6) Service — לדפי שירות. (7) HowTo — למדריכים. כל אחד עם כלי הבדיקה של Google.

סוג Schema מתאים ל... Rich Result שמתקבל השפעה על CTR
LocalBusiness כל עסק מקומי Knowledge Panel, Local Pack גבוהה מאוד
Product + AggregateRating חנויות אונליין כוכבים, מחיר, זמינות +35% CTR
FAQ דפי שאלות נפוצות שאלות מורחבות ב-SERP +15-25% CTR
HowTo מדריכים צעד-אחר-צעד שלבים עם תמונות +10-20% CTR
BreadcrumbList כל אתר נתיב ניווט ב-SERP +5-10% CTR
Article אתרי תוכן ובלוגים תאריך, כותב, תמונה +5-15% CTR
Service נותני שירותים פרטי שירות ומחיר בינונית

בדיקת Schema

301 Redirects וטיפול בשינויי URL

כשאתם משנים URL של דף, מוחקים דף, או מעבירים אתר לדומיין חדש — חייבים להגדיר 301 Redirect. בלי הפניה, כל ה-Ranking Signals שהדף הישן צבר (Backlinks, סמכות) הולכים לאיבוד, והמשתמשים שמגיעים ל-URL הישן רואים שגיאת 404.

סוגי Redirects

סוג קוד HTTP שימוש העברת SEO
301 Redirect 301 הפניה קבועה — הדף עבר לצמיתות מעביר ~90-99% מה-Link Equity
302 Redirect 302 הפניה זמנית — הדף יחזור לא מעביר Link Equity (בתיאוריה)
Meta Refresh — הפניה ברמת HTML לא מומלץ ל-SEO
JavaScript Redirect — הפניה ברמת JS בעייתי — גוגל עשויה לא לזהות

Best Practices ל-Redirects

שגיאות זחילה ואיך לתקן

Google Search Console מדווח על שגיאות שגוגל נתקלת בהן בזמן זחילת האתר. טיפול שוטף בשגיאות אלה מבטיח שגוגל יכולה לגשת לכל הדפים החשובים.

שגיאות נפוצות

404 — Page Not Found

גוגל מנסה לגשת לדף שלא קיים. הסיבות: הדף נמחק, ה-URL השתנה ללא הפניה, או שיש קישורים שבורים באתר. הפתרון: הגדירו 301 Redirect לדף הרלוונטי ביותר, או צרו דף 404 מותאם אישית שעוזר למשתמשים למצוא מה שהם מחפשים.

Soft 404

הדף מחזיר קוד 200 (תקין) אבל בפועל מציג תוכן של שגיאה (כמו "הדף לא נמצא"). גוגל מזהה את זה ומדווחת. הפתרון: ודאו שדפים שלא קיימים מחזירים קוד 404 אמיתי.

Server Error (5xx)

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

Redirect Error

שרשרת הפניות ארוכה מדי, הפניה מעגלית (A → B → A), או הפניה לדף שלא קיים.

בדיקה שוטפת

היכנסו ל-Google Search Console → Pages (Indexing) לפחות פעם בשבוע. בדקו את הדפים שסומנו כ-"Not indexed" וטפלו בסיבות. השתמשו ב-URL Inspection Tool כדי לבדוק דף ספציפי ולבקש אינדוקס מחדש.

שימוש ב-AI לביקורת טכנית

ב-2026, AI יכול לעזור משמעותית בביצוע ביקורת Technical SEO — במיוחד בניתוח תוצאות מכלים כמו Screaming Frog ו-Google Search Console.

תהליך עבודה מומלץ

1

הריצו סריקה עם Screaming Frog

Screaming Frog SEO Spider הוא כלי שזוחל את האתר שלכם כמו Googlebot ומחזיר דוח מפורט: דפים שבורים, תגיות חסרות, תוכן כפול, שרשראות הפניה, ועוד. הגרסה החינמית סורקת עד 500 דפים.

2

ייצאו את הדוח ל-CSV/Excel

ייצאו את כל הממצאים: Response Codes, Meta Titles, Meta Descriptions, H1 tags, Canonical, Hreflang, Page Speed, Images.

3

העלו ל-Claude לניתוח

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

4

בצעו ועקבו

תקנו לפי סדר עדיפויות. התחילו מבעיות קריטיות (5xx errors, noindex בטעות, אתר לא באינדקס) ועברו לאופטימיזציות (מהירות, Schema, תמונות).

טיפ: Claude Code לסריקה אוטומטית

עם Claude Code תוכלו ליצור סקריפט Python שבודק אוטומטית: כל ה-URLs מה-Sitemap זמינים, כל הדפים יש להם Canonical, כל התמונות יש להן Alt text, אין שרשראות Redirect, וכל ה-Core Web Vitals תקינים. הריצו את הסקריפט פעם בשבוע וקבלו דוח אוטומטי.

פרומפטים מומלצים לביקורת Technical SEO עם AI

פרומפט 1: ניתוח דוח Screaming Frog

"הנה ייצוא CSV מ-Screaming Frog של האתר שלי. [הדביקו את הנתונים]

נתח את הדוח ותן לי:
1. 5 הבעיות הקריטיות ביותר שצריך לתקן מיד
2. לכל בעיה: הסבר מה ההשפעה על SEO + הוראות תיקון מפורטות
3. זמן משוער לתיקון כל בעיה
4. סדר עדיפויות מ-1 (דחוף) ל-5 (אפשר לחכות)
5. בעיות שאפשר להתעלם מהן ולמה"

פרומפט 2: יצירת Schema Markup

"צור JSON-LD Schema Markup עבור [סוג העסק] בישראל. פרטי העסק:
שם: [שם]
כתובת: [רחוב, עיר]
טלפון: [מספר]
שעות פתיחה: [שעות]
שירותים: [רשימה]

כלול: LocalBusiness, BreadcrumbList, ו-FAQ (5 שאלות נפוצות על השירותים). ודא שה-Schema תקין לפי schema.org. השתמש בקודי מדינה IL ומטבע ILS."

פרומפט 3: יצירת Robots.txt ו-Sitemap Strategy

"האתר שלי בנוי ב-[פלטפורמה, למשל WordPress/Shopify/Custom]. יש לי [מספר] דפי מוצר, [מספר] מאמרי בלוג, ודפי קטגוריה.
1. כתוב robots.txt אופטימלי שחוסם דפים לא רלוונטיים אבל מאפשר גישה לכל התוכן החשוב
2. תכנן אסטרטגיית Sitemap: האם צריך מספר Sitemaps? מה לכלול/לא לכלול?
3. ציין טעויות נפוצות שצריך להימנע מהן"

כלים חיוניים לביקורת Technical SEO

כלי שימוש חינמי/בתשלום מתי להשתמש
Google Search Console שגיאות אינדוקס, Core Web Vitals, Mobile Usability חינמי כל יום/שבוע — מקור מידע ראשי
PageSpeed Insights מהירות, CWV, המלצות תיקון חינמי בכל שינוי באתר + בדיקה חודשית
Screaming Frog סריקת אתר מלאה — שגיאות, מטא, קישורים חינמי (עד 500 URLs) / $259/שנה ביקורת חודשית או רבעונית
Ahrefs Site Audit ביקורת אוטומטית עם תיעדוף בעיות $99+/חודש ביקורת שבועית אוטומטית
Chrome DevTools Debug מהירות, Network, Performance, Lighthouse חינמי Debug בעיות ספציפיות
Rich Results Test בדיקת Schema Markup חינמי אחרי הוספת/שינוי Schema
אזהרה: ביקורת בלי פעולה = בזבוז זמן

הטעות הנפוצה ביותר ב-Technical SEO היא לבצע ביקורת מקיפה, לייצר דוח יפה, ואז... לא לעשות כלום. ביקורת היא רק הצעד הראשון. הערך נמצא בתיקון. תעדפו: (1) בעיות שמונעות אינדוקס — תקנו היום. (2) בעיות מהירות קריטיות — תקנו השבוע. (3) אופטימיזציות — תקנו החודש. אל תנסו לתקן הכל בבת אחת — זה מוביל לשיתוק.

International SEO — שיקולים לעסקים ישראליים

עסקים ישראליים שרוצים להגיע גם לקהל בינלאומי צריכים לשקול:

ניטור שוטף של Core Web Vitals

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

ירוק = ROI

מחקר של Google מראה שאתרים שעוברים מ-CWV "צריך שיפור" ל-"טוב" רואים ירידה ממוצעת של 24% ב-Abandonment Rate. זה אומר יותר Conversions, יותר מכירות, יותר Leads — רק מתיקון מהירות.

סיכום הפרק — צ'קליסט Technical SEO

בפרק הבא נעבור ל-On-Page SEO — איך לכתוב Title Tags, Meta Descriptions, Headers ותוכן שגם גוגל וגם המשתמשים אוהבים.