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

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

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

מה יהיה לך בסוף הפרק הזה
מה תוכלו לעשות אחרי הפרק הזה
לפני שמתחילים
הפרויקט שלך — מפרק 5 לפרק 7

בפרק 5 בנית רשימת מילות מפתח ואסטרטגיית תוכן. בפרק הזה אנחנו מניחים את הבסיס הטכני — מוודאים שגוגל יכולה למצוא, לזחול, לאנדקס ולהבין את האתר שלך. בלי הבסיס הזה, אף מילת מפתח לא תעזור. בפרק 7 ניקח את מילות המפתח מפרק 5 ונטמיע אותן ב-On-Page SEO — Title Tags, Headers, ותוכן — כשהבסיס הטכני כבר מוצק.

בדיקת מוכנות לפני שמתחילים — קריאה חובה

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

מסלול שעה ראשונה — 60 דקות מסודרות לכל ה-8 התוצרים 60 דקות

הפרק ארוך — אבל אם תפעל לפי הסדר הזה, תסיים את 8 התוצרים תוך שעה אחת. הוצא טיימר, עקוב לפי השלבים:

  1. דקות 0-5: פתח pagespeed.web.dev בכרטיסייה אחת ו-search.google.com/search-console בכרטיסייה שנייה. הזן את ה-URL שלך ב-PSI ולחץ Analyze. בזמן שזה רץ — עבור ל-GSC.
  2. דקות 5-10: ב-PSI, צלם מסך של הציון ושל שלושת ה-CWV (LCP/INP/CLS). שמור בתיקיית "06-technical-seo/baselines/". תוצר 1 + תוצר 7.
  3. דקות 10-20: פתח yourdomain.com/robots.txt בדפדפן. אם נטען — צלם מסך, ודא שאין Disallow: /. אם 404 — זה בסדר (אין חסימה). תוצר 2.
  4. דקות 20-30: ב-GSC → Sitemaps. אם יש שורה אחת או יותר עם status "Success" — סיימת. אם לא — בדוק yourdomain.com/sitemap.xml או /sitemap_index.xml, הזן את ה-URL ולחץ Submit. תוצר 3.
  5. דקות 30-35: בדוק את שורת הכתובת בדפדפן. רואה מנעול? HTTPS פעיל. צלם מסך. תוצר 5.
  6. דקות 35-45: פתח search.google.com/test/rich-results, הזן את ה-URL שלך. אם יש Schema תקין — צלם מסך. אם אין — סמן בגיליון "צריך להוסיף". נחזור לתוצר 4 בתרגיל 2 בהמשך.
  7. דקות 45-55: הוצא את הטלפון. פתח את האתר. בדוק 4 דברים: טקסט קריא? כפתורים גדולים? גלילה אופקית? Pop-Up חוסם? צלם מסך. תוצר 6.
  8. דקות 55-60: פתח Google Sheet חדש. רשום ב-3 שורות: 3 הדברים הכי דחופים שצריך לתקן (לפי PSI Opportunities). תוצר 8 — טיוטה.

תוצר אחרי 60 דקות: 6 צילומי מסך + שורת status ב-GSC + טיוטת תוכנית תיקון. שאר התרגילים מעמיקים את כל אחד.

מילון מונחים — פרק 6
מונח (English) עברית הסבר
Core Web Vitals (CWV) מדדי חוויית הליבה שלושה מדדים שגוגל משתמשת בהם למדידת חוויית משתמש: LCP, INP, CLS — משפיעים ישירות על דירוג
LCP — Largest Contentful Paint זמן טעינת האלמנט הגדול הזמן עד שהאלמנט הוויזואלי הגדול ביותר בדף נטען. יעד: מתחת ל-2.5 שניות
INP — Interaction to Next Paint זמן תגובה לאינטראקציה הזמן מרגע שהמשתמש לוחץ/מקיש עד שהדפדפן מעדכן את התצוגה. החליף את FID במרץ 2024. יעד: מתחת ל-200ms
CLS — Cumulative Layout Shift הזזת פריסה מצטברת כמה אלמנטים "קופצים" בדף בזמן הטעינה. יעד: מתחת ל-0.1
XML Sitemap מפת אתר קובץ XML שמפרט את כל הדפים שאתם רוצים שגוגל תאנדקס — "מפה" עבור Googlebot
Robots.txt קובץ הוראות לזוחלים קובץ בשורש האתר שאומר ל-Crawlers אילו חלקים מותר/אסור לזחול
HTTPS פרוטוקול מאובטח HyperText Transfer Protocol Secure — מצפין תקשורת בין הדפדפן לשרת. גורם דירוג מאז 2014
Mobile-First Indexing אינדוקס מובייל-ראשון גוגל משתמשת אך ורק בגרסת המובייל של האתר לאינדוקס ודירוג. הושלם ביולי 2024
Canonical Tag תגית קאנוניקל תגית HTML (rel="canonical") שאומרת לגוגל איזה URL הוא הגרסה המקורית — מונעת בעיות תוכן כפול
Schema Markup / JSON-LD נתונים מובנים קוד שמוסיפים לדף ואומר לגוגל בדיוק מה המידע בדף (עסק, מוצר, FAQ) — מאפשר Rich Results בתוצאות
Structured Data נתונים מובנים מונח כללי לקוד מסודר שמתאר את תוכן הדף לגוגל. JSON-LD הוא הפורמט המומלץ
301 Redirect הפניה קבועה הפניה קבועה מ-URL ישן ל-URL חדש. גוגל אישרה רשמית מ-2016 (John Mueller, Gary Illyes) שמעבירה 100% מ-PageRank/Link Equity
Hreflang תגית שפה/מדינה תגית HTML שאומרת לגוגל באיזו שפה ולאיזו מדינה כל דף מיועד — קריטי לאתרים רב-לשוניים
Crawlability יכולת זחילה האם Googlebot יכול לגשת ולזחול את כל הדפים באתר ללא חסימות
Indexability יכולת אינדוקס האם הדפים שגוגל זוחלת באמת נכנסים לאינדקס ומוצגים בתוצאות החיפוש
Rich Results תוצאות מועשרות תוצאות חיפוש מורחבות עם כוכבים, מחירים, תמונות, FAQ — מופיעות בזכות Schema Markup תקין
מתחיל 8 דקות תיאוריה

מה זה Technical SEO ולמה זה קודם לכל

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

+32%

שיעור הנטישה במובייל עולה ב-32% כשזמן הטעינה גדל מ-1 ל-3 שניות, ו-90% כשהוא עולה ל-5 שניות (Google/Deloitte, "Milliseconds Make Millions" 2024 update; Cloudflare Radar 2025). מהירות האתר משפיעה ישירות על דירוג, חוויית משתמש, ושיעור המרה — Field Data של Core Web Vitals הוא המדד שגוגל באמת משתמשת בו לדירוג.

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

Technical SEO קודם לכל — זו לא המלצה, זו עובדה

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

עשה עכשיו 2 דקות

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

מתחיל-בינוני 15 דקות פרקטי

מהירות אתר ו-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 קריטי (Critical CSS, Above the Fold) ל-Inline בתוך <style> ב-head — דורש כלי כמו critical npm package. (2) טענו את שאר ה-CSS באופן אסינכרוני: <link rel="stylesheet" href="style.css" media="print" onload="this.media='all'">. (3) הוסיפו defer לכל סקריפט JavaScript שאינו קריטי. (4) בדקו עם Lighthouse אילו Resources חוסמים. אלטרנטיבה לא-מפתחים: WP Rocket / LiteSpeed Cache עושים את זה אוטומטית.

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

קיצור דרך לא-מפתחים: התקן Caching Plugin

אם אתה לא מפתח, רוב תיקוני ה-INP יושגו על ידי תוסף Caching טוב. ב-WordPress: WP Rocket (בתשלום, ~$59/שנה — מומלץ מאוד) או LiteSpeed Cache (חינם אם השרת תומך). הם מטפלים אוטומטית ב-defer לסקריפטים, מינימיזציה, וטעינת lazy. תקבל 60-80% מהיתרון בלי לכתוב קוד. רק אחרי שהפעלת caching ועדיין INP אדום — עבור לשלבים הבאים.

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. איך לספור אלמנטים: פתח Console ב-DevTools (F12), הדבק document.querySelectorAll('*').length והקש Enter — תקבל את המספר. פתרונות: (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, ו-Video Embeds שנטענים מאוחר דוחפים תוכן למטה. פתרון: (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 שבועות.

עשה עכשיו 3 דקות

פתחו את האתר שלכם בטלפון הנייד. רשמו את התשובות לשאלות הבאות: (1) כמה זמן לקח לדף להיטען? ספרו שניות. (2) האם משהו "קפץ" בזמן הטעינה? (3) האם הכפתורים גדולים מספיק לאצבע? (4) האם אפשר לקרוא את הטקסט בלי לעשות זום? שמרו את התשובות — אלה אינדיקציות ראשונות לבעיות CWV.

מתחיל 10 דקות חינם פרקטי

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

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

Field Data vs Lab Data

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

ציון הביצועים (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).

עשה עכשיו 5 דקות

הריצו את PageSpeed Insights על דף הבית שלכם. איפה לחפש מה?

גללו ל-"Opportunities". רשמו את 3 ההמלצות הראשונות ואת החיסכון המשוער בזמן טעינה לכל אחת. אלה התיקונים הראשונים שתעשו. אם הציון מתחת ל-50 — בעיה דחופה. 50-89 — יש מקום לשיפור. 90+ — יפה, עברו הלאה.

[מקום לצילום מסך מומלץ: דוח PSI עם חיצים על Field Data, ציון מובייל, וקטגוריית Opportunities — שמור ב-/baselines/psi-mobile-report.png]

מתחיל 8 דקות פרקטי

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

תמונות הן בדרך כלל הגורם מספר 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">

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

עשה עכשיו 3 דקות

פתחו את squoosh.app בדפדפן. גררו לשם את התמונה הכי כבדה באתר שלכם. בחרו פורמט WebP בצד ימין, איכות 80%. השוו את הגודל לפני ואחרי — סביר שתראו הפחתה של 50-70%. שמרו את התמונה המותאמת והעלו אותה לאתר במקום המקורית. חזרו על זה עבור 3 התמונות הכי כבדות.

טעות נפוצה: לשים loading="lazy" על תמונת ה-Hero (LCP)

למה זה מפתה: הוספת lazy loading לכל התמונות נשמעת כמו אופטימיזציה פשוטה ויעילה — "שכולן ייטענו רק כשצריך".

מה לעשות במקום: התמונה הראשית (Hero Image) היא בדרך כלל אלמנט ה-LCP. אם תשימו עליה lazy loading, אתם אומרים לדפדפן "אל תטען אותה עכשיו" — מה שפוגע ישירות ב-LCP. הוסיפו lazy loading רק לתמונות מתחת ל-Fold. על תמונת ה-Hero, הוסיפו דווקא fetchpriority="high".

מתחיל 10 דקות פרקטי

Mobile-First Indexing

נכון ליולי 2024, גוגל השלימה באופן מלא את המעבר ל-Mobile-First Indexing. המשמעות: גוגל משתמשת אך ורק בגרסת המובייל של האתר לאינדוקס ודירוג. אם האתר שלכם נראה מעולה בדסקטופ אבל גרוע במובייל — גוגל רואה רק את הגרסה הגרועה. אין יותר "נבדוק את הדסקטופ גם" — מובייל זה הכל.

עדכון חשוב: Mobile-First Indexing הושלם ביולי 2024

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

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

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

עדכון חשוב: דוח Mobile Usability ב-GSC הוצא משימוש ב-1 בדצמבר 2023

גוגל סגרה את Mobile Usability Report ב-GSC, את Mobile-Friendly Test Tool, ואת ה-Mobile-Friendly Test API — כולם הוצאו משימוש ב-1 בדצמבר 2023. אם מדריך ישן (לפני 2024) ממליץ על "GSC → Mobile Usability" — תתעלם, הדף לא קיים. השתמש בכלים החלופיים למטה, כולם מספקים את אותו מידע ויותר.

[מקום לצילום מסך מומלץ: Lighthouse Mobile audit עם Performance score וקטגוריית Accessibility — שמרו ב-/baselines/lighthouse-mobile.png]

טיפ: Target לגודל Touch

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

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

תוכן ומבנה

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

בעיה שכיחות פתרון
כפתור 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 ובדקו אלמנטים שחורגים
עשה עכשיו 3 דקות

קחו את הטלפון הנייד שלכם — עכשיו, ממש עכשיו — ופתחו את האתר שלכם. בדקו 4 דברים: (1) האם הטקסט קריא בלי זום? (2) האם הכפתורים מספיק גדולים ללחיצה בנוחות? (3) האם יש גלילה אופקית? (4) האם Pop-Up חוסם משהו? צלמו מסך. זה ה-Mobile-Friendly Check שלכם.

מתחיל 5 דקות פרקטי

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

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

מה צריך לעשות

מה זה Mixed Content ואיך לזהות בפועל

הגדרה: "Mixed Content" קורה כשדף שנטען ב-HTTPS מכיל אלמנטים (תמונות, סקריפטים, iframes, CSS) שנטענים מ-HTTP. זה פוגע באבטחה ובאמינות — Chrome יציג אזהרה או יחסום אלמנטים אלה לחלוטין. גם אם יש לך SSL פעיל, Mixed Content "שובר" את המנעול הירוק.

איך לזהות תוך 30 שניות:

  1. פתח את הדף ב-Chrome.
  2. לחץ F12 (Windows) / Cmd+Opt+I (Mac) לפתיחת DevTools.
  3. עבור לכרטיסיית Console.
  4. רענן את הדף (F5).
  5. חפש שורות באדום עם הטקסט "Mixed Content" או "was loaded over HTTPS, but requested an insecure". כל שורה כזו = אלמנט לתקן.
  6. לחלופין: סורק חינמי whynopadlock.com או jitbit.com/sslcheck/ — הזן URL וקבל רשימה.

התיקון: שנה את ה-URL של האלמנט מ-http:// ל-https://. אם המשאב לא קיים ב-HTTPS — מצא חלופה או ארח אצלך.

[מקום לצילום מסך: Chrome DevTools Console עם אזהרת Mixed Content מודגשת — שמור ב-/baselines/mixed-content-console.png]

עשה עכשיו 1 דקה

פתחו את האתר שלכם בדפדפן. הסתכלו על שורת הכתובת. האם יש מנעול? אם כן — יופי, HTTPS פעיל. אם לא, או אם כתוב "Not Secure" — זו הבעיה הראשונה שצריך לתקן. פנו לספק האחסון שלכם והבקשו הפעלת SSL — ברוב המקרים זה חינם ולוקח 5 דקות.

בינוני 10 דקות תיאוריה + פרקטיקה

ארכיטקטורת אתר ומבנה 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 בתוצאות.

מתחיל 5 דקות פרקטי

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

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

מה לכלול ב-Sitemap

יצירה והגשה

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

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

עשה עכשיו 3 דקות

בדקו אם יש לכם Sitemap: פתחו את domain.co.il/sitemap.xml בדפדפן. אם מופיע XML — יופי. אם 404 — נסו /sitemap_index.xml. אם גם זה לא עובד, צריך ליצור אחד. כנסו ל-Google Search Console → Sitemaps ובדקו אם הוא מוגש. אם לא — הגישו עכשיו.

מתחיל 5 דקות פרקטי כלי

איפה אני שם את זה? — טבלת CMS

אחת השאלות הכי שכיחות של מתחילים: "המדריך אומר 'הוסף Schema ל-head' — אבל איפה ה-head שלי?". התשובה תלויה בפלטפורמה. הטבלה הזו אומרת לך בדיוק איפה ואיך לערוך את כל מה שתצטרך בפרק:

פעולה WordPress Shopify Wix
Schema (JSON-LD) תוסף Rank Math → "Schema" tab בעורך הדף. לחלופין: תוסף "Insert Headers and Footers" ולהדביק את הקוד Edit theme → theme.liquid → הדבק לפני </head>. למוצרים: לרוב כבר יש Schema אוטומטי SEO Tools → Custom Code → Add Custom Code → head section. הגבלה: לא לכל הדפים
Canonical Tag אוטומטי דרך Yoast/Rank Math (Self-Referencing). לעקיפה: שדה "Canonical URL" בעורך הדף אוטומטי. לעקיפה: theme.liquid עם {{ canonical_url }} אוטומטי. לעקיפה ידנית: SEO Tools → Advanced SEO → Canonical URL
robots.txt Yoast/Rank Math → Tools → File Editor. או FTP/cPanel → קובץ פיזי בשורש Edit code → templates → robots.txt.liquid (גרסה חדשה). הגבלה: גוגל ובוטים לגיטימיים תמיד מאופשרים לא ניתן לערוך ישירות. Wix מנהל אוטומטית. SEO Settings מאפשר noindex ברמת דף
Sitemap Yoast/Rank Math יוצר אוטומטית בכתובת /sitemap_index.xml אוטומטי בכתובת /sitemap.xml — לא ניתן לערוך אוטומטי בכתובת /sitemap.xml — לא ניתן לערוך
301 Redirect תוסף "Redirection" (חינם) או Rank Math → Redirections. עורך .htaccess רק אם אתה יודע מה אתה עושה Online Store → Navigation → URL Redirects → Add URL Redirect SEO Tools → URL Redirect Manager → New Redirect
החלפת תמונה (שמירת URL) תוסף Enable Media Replace (חינם) — אחרת ה-URL משתנה והקישורים נשברים Settings → Files → חפש את התמונה → Replace Media Manager → Replace File
אימייל לקריאה לתמיכה (SSL) "שלום, ברצוני להפעיל תעודת SSL (Let's Encrypt) על הדומיין שלי. אנא הפעילו תעודה ו-Force HTTPS Redirect מ-HTTP. תודה."
אזהרת WordPress: גבה לפני שאתה עורך תמה

שני כללי זהב לעריכת WordPress: (1) תמיד גבה לפני — התקן UpdraftPlus, לחץ "Backup Now", המתן לסיום. (2) לעולם אל תערוך את ה-theme המקורי ישירות. Theme update הבא ימחק את כל השינויים שלך. השתמש ב-Child Theme (תוסף "Child Theme Configurator" יוצר אחד תוך 30 שניות), או לחלופין השתמש בתוסף "Insert Headers and Footers" שמאחסן קוד בנפרד מהתמה ושורד עדכונים.

מתחיל 5 דקות פרקטי

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

אזהרה קריטית: שורה אחת של robots.txt יכולה למחוק אותך מגוגל

השורה Disallow: / חוסמת את כל האתר מ-Googlebot. אם תכתוב אותה בטעות ותשמור — תוך ימים האתר ייעלם מגוגל. לפני שאתה שומר שינוי ב-robots.txt:

  1. גבה את הקובץ הקיים — העתק את התוכן ל-Notepad/Sheet עם תאריך.
  2. בדוק עם הכלי הרשמי של גוגל: search.google.com/test/robots-txt (זמין ב-GSC, "Settings" → "robots.txt" — חזר ב-2024 כתחליף לכלי הישן). הדבק את התוכן החדש, בדוק עבור URLs ספציפיים שלא נחסמים בטעות.
  3. לאחר שמירה: רענן את yourdomain.com/robots.txt בדפדפן וודא שהקובץ הציבורי תואם לציפייה.
עשה עכשיו 2 דקות

פתחו domain.co.il/robots.txt בדפדפן. קראו את התוכן. בדקו: (1) האם יש Disallow: / שחוסם את כל האתר? (2) האם דפים חשובים (שירותים, מוצרים, בלוג) חסומים? (3) האם יש שורת Sitemap: שמפנה ל-Sitemap? אם הקובץ לא קיים, זה בסדר — זה אומר שהכל פתוח לזחילה. [מקום לצילום מסך: robots.txt תקין של עסק ישראלי — שמור ב-/baselines/robots-txt-good.png]

בינוני 5 דקות תיאוריה

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

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

מתי צריך Canonical?

Self-Referencing Canonical — חובה על כל דף

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

טעות נפוצה: לחשוב ש-Robots.txt חוסם אינדוקס

למה זה מפתה: אם אתם לא רוצים שדף יופיע בגוגל, נראה הגיוני לחסום אותו ב-robots.txt — "אל תזחלי לשם".

מה לעשות במקום: robots.txt מונע זחילה, לא אינדוקס. אם יש Backlinks לדף חסום ב-robots.txt, גוגל עדיין יכולה לאנדקס אותו — פשוט בלי לדעת מה יש בו (ותציג תוצאה עם "No information is available for this page"). כדי למנוע אינדוקס, השתמשו בתגית <meta name="robots" content="noindex"> בתוך ה-HTML של הדף. ואל תחסמו את הדף ב-robots.txt בו-זמנית — כי אז גוגל לא תוכל לזחול אליו ולראות את תגית ה-noindex.

מתקדם 5 דקות תיאוריה

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

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

מתי צריך Hreflang?

סיור מודרך: Hreflang מלא לאתר עברי-אנגלי דו-לשוני

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

דף גרסה עברית (ברירת מחדל) גרסה אנגלית
דף הבית https://example.co.il/ https://example.co.il/en/
שירותים / Services https://example.co.il/services/ https://example.co.il/en/services/
צור קשר / Contact https://example.co.il/contact/ https://example.co.il/en/contact/

שלב 1: לכל אחד מ-6 הדפים תוסיף את אותו Cluster של תגיות Hreflang ב-<head>. ה-Cluster של דף השירותים נראה כך — זהה גם בגרסה העברית וגם באנגלית:

דוגמת קוד: Hreflang Cluster לדף השירותים — להעתיק לשתי הגרסאות

<link rel="alternate" hreflang="he-IL" href="https://example.co.il/services/" />
<link rel="alternate" hreflang="en" href="https://example.co.il/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://example.co.il/services/" />

שלב 2: חזור על אותה לוגיקה לכל זוג דפים — דף הבית מקבל cluster של דפי הבית, צור קשר מקבל cluster של "צור קשר", וכו'. סה"כ 6 דפים × 3 שורות = 18 שורות. מומלץ ליצור את זה בגיליון לפני ההטמעה.

שלב 3 — ולידציה: אחרי ההטמעה, רוץ על כל דף בכלי החינמי Merkle Hreflang Tags Testing Tool (technicalseo.com/tools/hreflang/) — הזן URL, הכלי יזחל את הדף ויאמת:

כלי שני לבדיקה: Aleyda Solis Hreflang Generator/Validator (aleydasolis.com/english/international-seo-tools/hreflang-tags-generator/) — בעיקר ליצירה אוטומטית של ה-cluster.

שלב 4 — מעקב ב-GSC: אחרי 1-2 שבועות, GSC → "International Targeting" (אם זמין באתר שלך) או → "Indexing" יראה אם יש שגיאות hreflang. הכי שכיח: "No return tags" — דף A מצביע על B, אבל B לא מצביע חזרה. תיקון: ודא שה-cluster זהה בשני הדפים.

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

עשה עכשיו 3 דקות

אם יש לך אתר דו-לשוני: פתח את technicalseo.com/tools/hreflang/ והזן את דף הבית של האתר שלך. צלם מסך של התוצאה. רשום בגיליון התוכנית: כמה שגיאות נמצאו? מה הסוג? אם אין לך אתר דו-לשוני — דלג. [מקום לצילום מסך: Merkle Hreflang Validator עם Pass בכל הקטגוריות — /baselines/hreflang-merkle.png]

בינוני 15 דקות פרקטי

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

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

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

LocalBusiness

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

אם העסק שלכם ממוקד בתחום ספציפי, העדיפו את ה-Sub-type המתאים — למשל ProfessionalService לעורכי דין, רואי חשבון ויועצים, MedicalBusiness (או Physician, Dentist) למרפאות וקליניקות, ו-FoodEstablishment למסעדות. רשימה מלאה: schema.org/LocalBusiness — גללו ל-"More specific types". Sub-types מספקים לגוגל הבנה מדויקת יותר ומשפרים את הסיכוי להופיע ב-Knowledge Panel בקטגוריה הנכונה. LocalBusiness הכללי נשאר אופציה טובה כ-Fallback כשאף Sub-type לא מתאים בדיוק.

Product

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

FAQ

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

HowTo

למדריכים צעד-אחר-צעד.

עדכון חשוב: HowTo Rich Results הוצאו משימוש

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

Article

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

Review / AggregateRating

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

איך להוסיף Schema

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

דוגמה: JSON-LD עבור LocalBusiness (עם Sub-type)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",  // <-- Sub-type מדויק. החליפו ב-LocalBusiness אם אין Sub-type מתאים
  "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>

דוגמה זו משתמשת ב-ProfessionalService — ה-Sub-type המתאים לעורכי דין, יועצים ורואי חשבון. לקליניקות: Physician / Dentist. למסעדות: FoodEstablishment. כשאין Sub-type מדויק — שנו ל-LocalBusiness.

דוגמאות 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 ש\"ח בחודש, תלוי בהיקף הפרויקט ורמת התחרות."
    }
  }, {
    "@type": "Question",
    "name": "כמה זמן לוקח לראות תוצאות ב-SEO?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "בדרך כלל 3-6 חודשים לתוצאות ראשוניות ו-6-12 חודשים לתוצאות משמעותיות."
    }
  }]
}
</script>

FAQPage מוכן להדבקה — ערכו את השאלות לעסק שלכם

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "// שאלה 1 — למשל: 'מה שעות הפעילות שלכם?'",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "// תשובה 1 — למשל: 'אנחנו פתוחים ראשון עד שישי 09:00-18:00, ושבת עד 14:00'"
      }
    },
    {
      "@type": "Question",
      "name": "// שאלה 2 — למשל: 'כמה עולה הטיפול הראשון?' / 'מה כולל המחיר?'",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "// תשובה 2 — כתבו תשובה מלאה, כולל מחיר בש\"ח אם רלוונטי"
      }
    },
    {
      "@type": "Question",
      "name": "// שאלה 3 — למשל: 'באילו אזורים אתם עובדים?' / 'האם מקבלים ביטוח לאומי?'",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "// תשובה 3"
      }
    }
  ]
}
</script>

איך להשתמש: הדביקו את הקוד ב-<head> של כל דף שיש בו שאלות נפוצות. החליפו את כל ה-// בשאלות ותשובות אמיתיות מהאתר שלכם — שאלות שלקוחות שואלים בפועל. לאחר העריכה, הריצו Rich Results Test ואשרו שאין שגיאות לפני שמפרסמים.

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"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "89"
  }
}
</script>

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

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

בדיקת Schema

בדיקה זריזה: האם כבר יש לי Schema באתר?

לפני שאתה בונה Schema מאפס — בדוק אם התמה שלך כבר מספקת. פתח את הדף שלך, לחץ קליק ימני → "View Page Source" (Ctrl+U). הקש Ctrl+F וחפש ld+json — אם יש תוצאות, יש כבר Schema. בדוק את התוכן ב-Rich Results Test כדי לוודא שהוא תקין ומדויק.

אזהרה חוקית: אל תשקר ב-Schema

אסור להוסיף ביקורות, דירוגים, מחירים, או נתונים שאינם אמיתיים ב-JSON-LD — גם אם זה מגדיל CTR. גוגל בודקת ויכולה להטיל Manual Action שמסירה את כל ה-Rich Results מהאתר שלך, לפעמים מסירה את האתר כולו. ביקורות חייבות להיות אמיתיות ומקושרות לעמוד עם הביקורות. מחירים חייבים להתאים למה שמוצג למשתמש. אם אין לך ביקורות — אל תוסיף aggregateRating בכלל.

עשה עכשיו 5 דקות

גשו ל-search.google.com/test/rich-results והזינו את כתובת האתר שלכם. מה לחפש בתוצאה:

אם יש Schema תקין — מעולה, ודאו שאין שגיאות וצלמו מסך. אם לא — השתמשו באחת מדוגמאות הקוד שנתנו כאן (LocalBusiness או FAQ) והוסיפו לאתר. ב-WordPress, השתמשו בתוסף Rank Math שמאפשר הוספת Schema ללא קוד.

[מקום לצילום מסך: Rich Results Test עם תוצאת "Eligible for rich results" ירוקה — שמור ב-/baselines/rich-results-pass.png]

בינוני 5 דקות תיאוריה

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

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

סוגי Redirects

סוג קוד HTTP שימוש העברת SEO
301 Redirect 301 הפניה קבועה — הדף עבר לצמיתות מעביר 100% מ-PageRank/Link Equity (גוגל מ-2016)
302 Redirect 302 הפניה זמנית — הדף יחזור 302 לטווח קצר: גוגל לא מעדכנת את הדף הקנוני. 302 לטווח ארוך (יותר מכמה חודשים): גוגל מתייחסת אליו כמו 301 ומעבירה Link Equity מלא
Meta Refresh — הפניה ברמת HTML לא מומלץ ל-SEO
JavaScript Redirect — הפניה ברמת JS בעייתי — גוגל עשויה לא לזהות

Best Practices ל-Redirects

טעות נפוצה: להפנות את כל הדפים הישנים לדף הבית

למה זה מפתה: במיגרציית אתר או שינוי URL-ים, נראה קל פשוט להפנות הכל ל-Homepage — "בסוף הם ימצאו מה שהם מחפשים".

מה לעשות במקום: גוגל מתייחסת ל-301 Redirect מדף ספציפי לדף הבית כמעט כמו ל-Soft 404 — כי זו לא הפניה רלוונטית. כל דף ישן צריך להפנות לדף הרלוונטי ביותר באתר החדש. אם אין דף מקביל — רק אז הפנו לקטגוריה הקרובה ביותר. מיפוי 1:1 של URLs שומר על Link Equity ועל חוויית המשתמש.

טעות נפוצה: להתעלם מ-Core Web Vitals כי "הציון הוא רק המלצה"

למה זה מפתה: הרבה בעלי אתרים רואים ציון כתום או אדום ב-PageSpeed Insights, מתעלמים ואומרים "גם אתרים גדולים לא מושלמים, זה רק כלי".

מה לעשות במקום: Core Web Vitals הם גורם דירוג רשמי מאז 2021 (ועודכנו ב-2024). הם לא "המלצה" — הם חלק מהאלגוריתם. Field Data ב-PageSpeed Insights מגיע ממשתמשים אמיתיים ומשקף בדיוק את מה שגוגל רואה. תתמקדו ב-Field Data (לא ב-Lab Data), ותעדפו את המדד שהכי אדום — שם ההשפעה תהיה הגדולה ביותר.

מתחיל 5 דקות פרקטי

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

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

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

404 — Page Not Found

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

Soft 404

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

Server Error (5xx)

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

Redirect Error

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

הבחנה קריטית: Crawled vs Discovered — currently not indexed

שתי הקטגוריות הכי שכיחות ב-GSC Pages report נשמעות דומות אבל מצריכות פעולה שונה:

בדיקה שוטפת

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

עשה עכשיו 3 דקות

היכנסו ל-Google Search Console → Pages (באגף Indexing). בדקו: כמה דפים "Not indexed"? מה הסיבות? אם יש שגיאות 404 או 5xx — רשמו אותן. אלה התיקונים הראשונים שצריך לעשות. אם אין לכם GSC — עצרו, חזרו לפרק 4, וחברו אותו. בלי GSC אתם עיוורים.

[מקום לצילום מסך: GSC Pages report עם פילוח "Why pages aren't indexed" — שמור ב-/baselines/gsc-pages-report.png]

בינוני 10 דקות פרקטי

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

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

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

1

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

Screaming Frog SEO Spider הוא כלי שזוחל את האתר שלכם כמו Googlebot ומחזיר דוח מפורט: דפים שבורים, תגיות חסרות, תוכן כפול, שרשראות הפניה, ועוד. הגרסה החינמית סורקת עד 500 דפים. הגרסה המלאה עולה £259 לשנה (כ-$330, מחיר 2026) — שווה כל שקל עבור אתרים עם מאות דפים ומעלה.

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, תמונות).

פרומפטים מומלצים לביקורת 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."

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

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

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

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

מתחיל-בינוני 8 דקות פרקטי

Frameworks להחלטות — סדר עדיפויות ו-DIY vs מומחה

מסגרת החלטה 1: סדר עדיפויות לתיקוני Technical SEO

כשיש לכם רשימה של 20 בעיות טכניות, קל ללכת לאיבוד. הנה הסדר הנכון — תמיד תתקנו מלמעלה למטה. אין טעם לעבוד על Schema אם גוגל לא יכולה לזחול את האתר.

1

Crawlability — יכולת זחילה (תקנו תוך 24 שעות)

האם גוגל בכלל יכולה לגשת לאתר? בדקו: robots.txt לא חוסם דפים חשובים, אין שגיאות שרת (5xx), אין Redirect Loops, Sitemap מוגש. בלי זה, כל השאר לא רלוונטי.

2

Indexability — יכולת אינדוקס (תקנו תוך שבוע)

האם הדפים שגוגל זוחלת נכנסים לאינדקס? בדקו: אין noindex בטעות, Canonical תקין, אין Duplicate Content בעייתי, דפים חשובים מופיעים ב-GSC כ-indexed.

3

Security — אבטחה (תקנו תוך שבוע)

HTTPS פעיל, אין Mixed Content, תעודת SSL בתוקף. Chrome מסמן אתרי HTTP כ-"Not Secure" — זה מרתיע מבקרים ופוגע בדירוג.

4

Speed — מהירות (תקנו תוך חודש)

Core Web Vitals בירוק, ציון PSI מעל 80, תמונות מאופטימזות, Render-Blocking Resources מטופלים. זה חשוב אבל לא דחוף כמו Crawlability/Indexability.

5

Enhancements — שיפורים (תקנו ברבעון)

Schema Markup, Breadcrumbs, Hreflang, URL Structure, מבנה אתר. אלה "נחמדים" שמשפרים CTR ומייעלים, אבל האתר יכול לדרג גם בלעדיהם.

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

מסגרת החלטה 2: DIY לעומת לגייס מומחה

לא כל בעיה טכנית דורשת מומחה. הנה ה-Framework שיעזור לכם להחליט:

סוג הבעיה DIY (תעשו לבד) גייסו מומחה
בדיקות ומעקב הרצת PSI, בדיקת GSC, בדיקת robots.txt, בדיקת Schema —
תמונות המרה ל-WebP (Squoosh), הוספת Lazy Loading, הוספת width/height —
Schema Markup הטמעה עם Rank Math / Yoast, הוספת JSON-LD ידנית Schema מורכב (Product עם Variants, Event)
מהירות הפעלת CDN (Cloudflare), הסרת תוספים מיותרים, Caching Plugin Code Splitting, Critical CSS, Server optimization
מיגרציה — מעבר דומיין, שינוי פלטפורמה, מעבר HTTP → HTTPS
בעיות שרת — 5xx Errors חוזרים, TTFB גבוה, SSL issues

כלל הזהב: אם טעות יכולה למחוק את האתר מגוגל — אל תעשו את זה לבד. שינויים ב-robots.txt, מיגרציות אתר, ו-Redirect Mappings של מאות דפים — אלה דברים שטעות קטנה בהם יכולה לגרום לנזק גדול. אם אתם לא בטוחים ב-100% — שלמו למומחה. העלות של שעת ייעוץ (300-500 ש"ח) היא כלום לעומת הנזק של אתר שנעלם מגוגל לחודש.

מסגרת החלטה 3: איזה מדד CWV לתקן ראשון?

כשכל שלושת ה-Core Web Vitals באדום או כתום, קל לתקוע. הנה הסדר:

מצב תתחיל מ... למה?
LCP אדום (מעל 4s) LCP ראשון LCP הוא המדד שהכי משפיע על חוויית המשתמש וקל יחסית לתקן (CDN + תמונות). גם ה-ROI הגבוה ביותר
CLS אדום (מעל 0.25) CLS ראשון CLS לרוב הכי קל לתקן (הוספת width/height, שמירת מקום לפרסומות) ומשפר חוויה מיד
INP אדום (מעל 500ms) INP אחרון INP הכי מורכב לתיקון (דורש אופטימיזציית JavaScript). התחילו מ-LCP/CLS ואז התמקדו ב-INP
הכל כתום LCP → CLS → INP בסדר הזה — כל שיפור ב-LCP משפיע גם על INP (פחות עומס על Main Thread)
מתחיל 5 דקות פרקטי

שגרת עבודה — Technical SEO שוטף

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

שגרת עבודה — פרק 6 (בנוסף לשגרה מפרקים 1-5)
תדירות מה לעשות זמן משוער כלי
כל שבוע בדקו GSC: דפים Not Indexed, שגיאות חדשות, Core Web Vitals, Crawl Errors 15 דקות Google Search Console
כל חודש בדקו Schema — עדיין תקין? סרקו Sitemap — מעודכן? בדקו 404 Errors — חדשים? הריצו PSI על 3-5 דפים חשובים 30-45 דקות Rich Results Test, PSI, GSC
כל רבעון ביקורת טכנית מלאה עם Screaming Frog או Ahrefs. השוו CWV ל-Baseline. בדקו Redirect Chains. בדקו Mobile-Friendly. עדכנו תוכנית תיקון 2-3 שעות Screaming Frog, Ahrefs, PSI
בכל שינוי באתר לפני ואחרי: הריצו PSI, בדקו CWV, ודאו Schema תקין. אם שיניתם URL — הגדירו 301 10 דקות PSI, GSC
ירוק = ROI

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

כשמשהו משתבש — Recovery Playbook

שגרת העבודה שלמעלה מיועדת לתחזוקה שוטפת. אבל מה עושים כשהטלפון מצלצל, הלקוח בהיסטריה, וה-GSC מראה שמשהו שבר? שלושת התרחישים הנפוצים ביותר לעסקים ישראליים שעובדים עם WordPress, Wix, או Shopify:

Recovery A: ציון PageSpeed ירד פתאום אחרי עדכון
  1. בדקו תחילה ב-GSC → Core Web Vitals → האם הירידה מופיעה ב-"Field Data" (מדד משתמשים אמיתיים) או רק ב-"Lab Data" (סימולציית PSI)? ירידה ב-Lab בלבד עשויה להיות רעש מדידה — המתינו 48 שעות ובצעו בדיקה חוזרת לפני שאתם פועלים.
  2. זהו מתי הירידה התחילה. השוו לציר הזמן של שינויים באתר: האם עדכנתם תוסף, שיניתם ערכת נושא, או העלאתם תמונות גדולות? רוב הרגרסיות קשורות לשינוי ספציפי שאפשר לבודד.
  3. אם תוסף הוא הגורם: בטלו את ההפעלה שלו ב-Dashboard, הריצו PSI מחדש, ואשרו שהציון חזר. אחר כך החליטו: להסיר את התוסף לצמיתות, או לחפש חלופה קלת-משקל.
  4. אם תמונות הן הגורם: הריצו PSI וחפשו ב-"Opportunities" את השורה "Properly size images" — PSI מפרט את כל קבצי התמונה הבעייתיים בשם. המירו אותם ל-WebP עם Squoosh (איכות 80%) ועדכנו את הקבצים.
  5. אם הירידה נמשכת ולא ניתן לאתר את הגורם תוך 30 דקות: פתחו Chrome DevTools → לשונית Performance, תעדו טעינת דף, וחפשו את ה-"Longest Task" ב-Main Thread — זה ה-JavaScript שעוצר את הרינדור.
  6. גבול ה-DIY: אם מדד TTFB (Time to First Byte) הוא מעל 800ms — זה בעיית שרת, לא Front-End. כאן מביאים מפתח או פונים לחברת האחסון. אל תנסו לפתור TTVB גבוה עם עוד תוסף.
Recovery B: דפים נעלמו מגוגל אחרי עריכת robots.txt
  1. נווטו מיד אל yourdomain.co.il/robots.txt ובדקו את הקובץ. שורה בודדת של Disallow: / חוסמת את כל האתר. מחקו אותה, שמרו, ובדקו שוב.
  2. ב-GSC → Settings → robots.txt Tester (שוחזר ב-2024): הדביקו כתובת של דף חשוב ואשרו שמוצג "Allowed". בדקו לפחות 5 דפים שונים — דף בית, דף שירות, דף בלוג.
  3. שלחו בקשת סריקה ב-GSC: URL Inspection → הזינו את כתובת דף הבית → Request Indexing. חזרו על הפעולה ל-3-5 דפים חשובים.
  4. בדקו שוב בעוד 24-48 שעות ב-GSC → Pages. דפים שהיו "Blocked by robots.txt" אמורים להתחיל לזוז חזרה לקטגוריה "Indexed".
  5. מניעה לעתיד: לעולם אל תעשו שינויים ב-robots.txt ישירות בסביבת Production. ב-WordPress: השתמשו ב-Yoast SEO robots.txt editor — הוא מאמת לפני שמירה. בכל פלטפורמה אחרת: ערכו בסביבת בדיקה והעתיקו לאחר אישור.
  6. ציר זמן לציפיות: גוגל בדרך כלל חוזרת לסרוק דפים בעדיפות גבוהה תוך 1-7 ימים לאחר הסרת החסימה. תנועה אורגנית עשויה לקחת 1-2 שבועות לחזור לרמתה הקודמת — זה תהליך רגיל ולא מעיד על בעיה נוספת.
Recovery C: GSC מדווח על שגיאות Schema ב-Enhancements
  1. פתחו GSC → Enhancements. לחצו על סוג ה-Schema שמראה שגיאות (למשל "FAQ" או "LocalBusiness"). GSC מפרט את כל כתובות ה-URL המושפעות ואת שמות השדות החסרים/שגויים.
  2. לכל סוג שגיאה: פתחו Rich Results Test על אחת מה-URLs המושפעות. הכלי מציג בדיוק איזה שדה חסר ומה הפורמט הצפוי — לא צריך לנחש.
  3. שגיאה נפוצה #1 — "priceCurrency" חסר ב-Product Schema: הוסיפו "priceCurrency": "ILS" לתוך אובייקט offers. ללא שדה זה, גוגל לא תציג מחיר בתוצאות.
  4. שגיאה נפוצה #2 — "telephone" חסר ב-LocalBusiness: הוסיפו "telephone": "+972-XX-XXXXXXX" בפורמט E.164. מספרים ישראליים: +972-3-XXXXXXX לקווי, +972-5X-XXXXXXX לנייד.
  5. שגיאה נפוצה #3 — aggregateRating ללא reviewCount: גוגל דורשת מספר ביקורות מדויק. הוסיפו "reviewCount": "X" עם המספר האמיתי — אל תמציאו מספרים, זה עלול להוביל לפנאלטי. אם אין לכם מספיק ביקורות — הסירו את aggregateRating כולו עד שיהיו.
  6. לאחר התיקון: הריצו Rich Results Test → אשרו אפס שגיאות → ב-GSC לחצו "Validate Fix" על ה-Enhancement הרלוונטי. גוגל תסרוק מחדש תוך 1-2 שבועות וספירת השגיאות תרד לאפס.
בינוני תרגיל 1: 20-30 דק' / תרגיל 2: 20-60 דק' / תרגיל 3: 45-60 דק' / תרגיל 4: 90-120 דק' (3 שלבים) פרקטי

תרגילים מעשיים

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

תרגיל 1: השוואה טכנית מול מתחרה (התחלה רכה) 20-30 דקות

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

  1. הריצו PSI על דף הבית של שניכם. מי מהיר יותר? מה ההפרש ב-LCP?
  2. בדקו Schema של המתחרה: הריצו Rich Results Test על האתר שלהם. אילו סוגי Schema יש להם שאין לכם?
  3. בדקו Mobile של המתחרה מהטלפון. יותר טוב או פחות טוב מכם? מה הם עושים שאתם לא?
  4. בדקו HTTPS: שניכם ב-HTTPS? יש למישהו Mixed Content (DevTools Console)?
  5. בדקו את robots.txt של המתחרה: domain.com/robots.txt — מה הם חוסמים? מה אתם יכולים ללמוד?
  6. סכמו: איפה אתם עדיפים? איפה הם? מה התיקון הראשון שיסגור את הפער?

תוצר: מסמך השוואה של 1 עמוד עם 5 שורות תיקונים מסודרים לפי עדיפות.

תרגיל 2: הטמעת Schema Markup ראשון 20-30 דקות (WordPress) / 45-60 דקות (קוד מותאם)

הטמיעו לפחות Schema אחד באתר שלכם:

  1. בחרו סוג: אם עסק מקומי — LocalBusiness. אם חנות אונליין — Product. אם יש דף FAQ — FAQPage.
  2. צרו את הקוד: השתמשו בדוגמאות מהפרק הזה, או בקשו מ-Claude ליצור JSON-LD מותאם לעסק שלכם.
  3. הוסיפו לאתר לפי הפלטפורמה (ראו טבלת CMS למעלה): WordPress → Rank Math UI או תוסף "Insert Headers and Footers". Shopify → theme.liquid לפני </head>. Wix → SEO Tools → Custom Code.
  4. בדקו: הריצו Rich Results Test → ודאו שאין שגיאות → צלמו מסך של "Eligible for rich results".
  5. המתינו 1-2 שבועות: בדקו ב-GSC → Enhancements אם גוגל זיהתה את ה-Schema.

תוצר: דף אחד באתר עם Schema תקין + צילום מסך של "Eligible for rich results".

תרגיל 3: אופטימיזציית מהירות — תמונות ו-Render-Blocking 45-60 דקות

שפרו את ציון PageSpeed Insights בלפחות 10 נקודות:

  1. הריצו PSI על דף הבית ורשמו את הציון הנוכחי — זה ה-Baseline שלכם.
  2. קיצור דרך לא-מפתחים (10 דקות): אם אתם ב-WordPress, התקינו WP Rocket או LiteSpeed Cache. הפעילו את האופציות "Defer JavaScript", "Optimize CSS Delivery" ו-"Lazy Load Images". הריצו PSI שוב — לרוב תקבלו 10-20 נקודות בלי לעבוד.
  3. טפלו בתמונות: זהו את 5 התמונות הכי כבדות (PSI מראה אותן ב-"Properly size images"). המירו כל אחת ל-WebP עם Squoosh (איכות 80%). ב-WordPress: השתמשו ב-Enable Media Replace כדי לא לשבור URLs.
  4. הוסיפו Lazy Loading: לכל תמונה מתחת ל-Fold הוסיפו loading="lazy". לתמונת ה-Hero הוסיפו fetchpriority="high" (לא lazy!).
  5. הוסיפו width/height: לכל תגית <img> שחסרים לה מימדים מפורשים.
  6. הריצו PSI שוב: רשמו את הציון החדש. כמה נקודות עליתם? מה עוד אפשר לשפר?

תוצר: שני צילומי מסך — לפני ואחרי. דלתא של ציון בכתב.

תרגיל 4: ביקורת Technical SEO מלאה — בחלוקה ל-3 שלבים 90-120 דקות (3 שלבים)

זה התרגיל הגדול. בצעו אותו ב-3 ישיבות נפרדות, לא בישיבה אחת — אחרת אתה תוותר באמצע. הקדימו: צרו Google Sheet עם 6 טאבים בשמות למטה.

שלב A — בדיקות חיצוניות בלבד (30 דקות, אפשר ביום הראשון):

  1. טאב "Core Web Vitals": הריצו PSI על 5 דפים חשובים (דף בית, 2 דפי שירות/מוצר, דף בלוג, דף צור קשר). רשמו לכל דף: LCP, INP, CLS, ציון כללי, ירוק/כתום/אדום.
  2. טאב "Mobile": בדקו 5 דפים מהטלפון. רשמו: טקסט קריא? כפתורים לחיצים? גלילה אופקית? Pop-ups?
  3. טאב "Security": HTTPS פעיל? בדקו Mixed Content בכל דף עם DevTools Console? SSL בתוקף?

שלב B — בדיקות GSC + Schema (30 דקות, ביום השני):

  1. טאב "Crawl Errors": כנסו ל-GSC → Pages. רשמו כל דף Not Indexed עם הסיבה ותוכנית טיפול (301, noindex, תיקון תוכן).
  2. טאב "Schema": הריצו Rich Results Test על כל סוג דף. רשמו: אילו סוגי Schema קיימים, שגיאות, מה חסר.

שלב C — תוכנית תיקון מתועדפת (30 דקות, ביום השלישי):

  1. טאב "תוכנית תיקון": העתיקו את כל הבעיות מ-A ו-B, תעדפו לפי ה-Framework (Crawl → Index → Security → Speed → Enhancements), הגדירו תאריך יעד לכל תיקון.
  2. סמנו לכל בעיה: DIY או מומחה? באיזו עלות משוערת?

תוצר: Google Sheet ביקורת שלם שאפשר לחזור אליו כל רבעון. נקודת התחלה לכל ה-Technical SEO לשנה הקרובה.

אם אתה עושה רק דבר אחד מהפרק הזה 5 דקות

גשו ל-pagespeed.web.dev, הזינו את כתובת האתר שלכם, וחכו לתוצאות. צלמו מסך של הציון ושל שלושת ה-Core Web Vitals (LCP, INP, CLS). שמרו את צילום המסך בתיקיית הפרויקט שלכם. זה ה-Baseline שלכם. בעוד חודש, אחרי שתטפלו בתיקונים, תריצו שוב ותשוו — ותראו שיפור.

בדוק את עצמך — האם עברת את פרק 6?

בדוק את עצמך — 5 שאלות
  1. מה שלושת ה-Core Web Vitals ומה הערכים הירוקים של כל אחד? (רמז: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1)
  2. מה ההבדל בין robots.txt ל-Sitemap — ולמה צריך את שניהם? (רמז: אחד אומר מה לא לזחול, השני אומר מה כן לאנדקס)
  3. למה HTTPS חשוב ל-SEO? (רמז: גורם דירוג ישיר מאז 2014, Chrome מסמן HTTP כ-Not Secure, ביטחון משתמשים)
  4. מה זה Schema Markup ואיזה סוג חובה לעסק מקומי? (רמז: קוד JSON-LD שאומר לגוגל מה יש בדף, LocalBusiness הוא חובה)
  5. מה ההבדל בין 301 ל-302 Redirect ומתי משתמשים בכל אחד? (רמז: 301 = קבוע, מעביר Link Equity. 302 = זמני, לא מעביר)

עברתם 4 מתוך 5? מצוין — הבסיס הטכני שלכם מוצק, אפשר לעבור ל-On-Page SEO.

צ'קליסט — סיכום פרק 6

מה בנית בפרק הזה

סיכום הפרק

בפרק הזה הנחתם את הבסיס הטכני — התשתית שבלעדיה אף תוכן לא ידורג בגוגל. למדתם לבדוק ולתקן את Core Web Vitals (LCP, INP, CLS), לוודא ש-Googlebot יכול לזחול ולאנדקס את כל הדפים החשובים (robots.txt, Sitemap, Canonical), לאבטח את האתר עם HTTPS, לבדוק תאימות למובייל (Mobile-First Indexing), ולהוסיף Schema Markup שנותן לגוגל הבנה מעמיקה של התוכן שלכם. הגדרתם גם שגרת עבודה שוטפת שתשמור על הביצועים הטכניים לאורך זמן.

בפרק הבא — On-Page SEO — ניקח את מילות המפתח מפרק 5 ונטמיע אותן בתוכן: Title Tags, Meta Descriptions, Headers, מבנה תוכן, Internal Linking, ועוד. כאן הקסם קורה — כאן גוגל מתחילה להבין מה הדף שלכם ולמי הוא מיועד. הבסיס הטכני שבניתם כאן מבטיח שכל מה שתעשו בפרק 7 באמת ייראה על ידי גוגל.

צ'קליסט סופי — האם השלמת את כל ה-8 התוצרים?