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, ותוכן — כשהבסיס הטכני כבר מוצק.

מתחיל 8 דקות תיאוריה

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

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

53%

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

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 קריטי (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, ו-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+ — יפה, עברו הלאה.

מתחיל 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">

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

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

Mobile-First Indexing

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

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

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

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

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

טיפ: 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 — זו בעיה דחופה.

מה צריך לעשות

עשה עכשיו 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 דקות פרקטי

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

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

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

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

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

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

מתי צריך Canonical?

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

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

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

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

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

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

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

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

LocalBusiness

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

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

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

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

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

גשו ל-search.google.com/test/rich-results והזינו את כתובת האתר שלכם. בדקו אם יש Schema תקין. אם כן — מעולה, ודאו שאין שגיאות. אם לא — השתמשו באחת מדוגמאות הקוד שנתנו כאן (LocalBusiness או FAQ) והוסיפו לאתר. ב-WordPress, השתמשו בתוסף Rank Math שמאפשר הוספת Schema ללא קוד.

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

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

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

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

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 כדי לבדוק דף ספציפי ולבקש אינדוקס מחדש.

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

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

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

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

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

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

1

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

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

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, Mobile Usability חינמי כל יום/שבוע — מקור מידע ראשי
PageSpeed Insights מהירות, CWV, המלצות תיקון חינמי בכל שינוי באתר + בדיקה חודשית
Screaming Frog סריקת אתר מלאה — שגיאות, מטא, קישורים חינמי (עד 500 URLs) / GBP 199/שנה (~$279) ביקורת חודשית או רבעונית
Ahrefs Site Audit ביקורת אוטומטית עם תיעדוף בעיות $29+/חודש (תוכנית Starter, 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 מומחה

Framework 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 ומייעלים, אבל האתר יכול לדרג גם בלעדיהם.

כלל האצבע: "אם גוגל לא יכולה לראות את הדף — שום דבר אחר לא משנה"

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

Framework 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 ש"ח) היא כלום לעומת הנזק של אתר שנעלם מגוגל לחודש.

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

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

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

תדירות מה לעשות זמן משוער כלי
כל שבוע בדקו 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 — רק מתיקון מהירות.

בינוני 60-90 דקות פרקטי

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

תרגיל 1: ביקורת Technical SEO מלאה עם גיליון אלקטרוני

צרו Google Sheet עם הטאבים הבאים ומלאו אותם עבור האתר שלכם:

  1. טאב "Core Web Vitals": הריצו PSI על 5 דפים חשובים (דף בית, 2 דפי שירות/מוצר, דף בלוג, דף צור קשר). רשמו לכל דף: LCP, INP, CLS, ציון כללי, ירוק/כתום/אדום
  2. טאב "Crawl Errors": כנסו ל-GSC → Pages. רשמו כל דף Not Indexed עם הסיבה ותוכנית טיפול (301, noindex, תיקון)
  3. טאב "Schema": הריצו Rich Results Test על כל סוג דף. רשמו: אילו סוגי Schema קיימים, שגיאות, מה חסר
  4. טאב "Mobile": בדקו 5 דפים מהטלפון. רשמו: טקסט קריא? כפתורים לחיצים? גלילה אופקית? Pop-ups?
  5. טאב "Security": HTTPS פעיל? Mixed Content? SSL בתוקף?
  6. טאב "תוכנית תיקון": העתיקו את כל הבעיות, תעדפו לפי ה-Framework (Crawl → Index → Security → Speed → Enhancements), הגדירו תאריך יעד לכל תיקון

זמן משוער: 45-60 דקות. תוצאה: גיליון ביקורת שלם שאפשר לחזור אליו כל רבעון.

תרגיל 2: הטמעת Schema Markup

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

  1. בחרו סוג: אם עסק מקומי — LocalBusiness. אם חנות אונליין — Product. אם יש דף FAQ — FAQPage
  2. צרו את הקוד: השתמשו בדוגמאות מהפרק הזה, או בקשו מ-Claude ליצור JSON-LD מותאם לעסק שלכם
  3. הוסיפו לאתר: ב-WordPress — עם Rank Math או ידנית ב-header. באתר מותאם — הוסיפו ל-<head>
  4. בדקו: הריצו Rich Results Test → ודאו שאין שגיאות → צלמו מסך של "Eligible for rich results"
  5. המתינו 1-2 שבועות: בדקו ב-GSC → Enhancements אם גוגל זיהתה את ה-Schema

זמן משוער: 20-30 דקות.

תרגיל 3: השוואה טכנית מול מתחרה

בחרו מתחרה ישיר והשוו את הביצועים הטכניים:

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

זמן משוער: 20-30 דקות.

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

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

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

בדוק את עצמך — 5 שאלות

ענו על 5 השאלות האלה. אם אתם יכולים לענות על 4 מתוך 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 = זמני, לא מעביר)

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

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

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

מה בנית בפרק הזה
הצעד הבא: פרק 7

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