Crawling מול Indexing, ההבדל היסודי במנוע החיפוש

🧭 ההבדל הכי חשוב שאתם לא מבינים, crawling מול indexing

תקשיבו. אני אפתח עם השיחה הכי מתסכלת שיש לי כל שבוע. לקוח כותב, "שמוליק, העמוד שלי לא בגוגל". אני שואל, "בדקת ב-Search Console מה המצב?". הוא עונה, "כן, גוגל סורק אותו, ראיתי את ה-Googlebot בלוגים". ואז אני צריך להסביר לו את ההבדל היסודי שכל מקדם חייב להבין, סריקה זה לא הכללה באינדקס. גוגל יכול לסרוק עמוד 50 פעם ועדיין לא להכניס אותו לאינדקס. נקודה.

בואו נגדיר את שני המונחים בלי בלגן. Crawling זה התהליך שבו Googlebot (וגם Bingbot, ‏Yandex, ‏ובאחרונה גם ChatGPT-User ו-PerplexityBot) מגיע לעמוד שלכם, מוריד את ה-HTML, ‏ומגלה לינקים נוספים מתוכו. זה ביקור. אורח שנכנס לבית, מסתכל, ויוצא. Indexing זה התהליך שבו גוגל לוקח את מה שהוריד, ‏מנתח אותו, ‏מבין על מה העמוד, ‏ומחליט האם כדאי לאחסן אותו במאגר העצום שלו כך שכאשר מישהו יחפש משהו רלוונטי, ‏העמוד יוכל להופיע. זאת החלטה ערכית של גוגל, ‏לא תהליך טכני.

ולמה זה כל כך קריטי? כי ה-95% מהפעמים שלקוח אומר לי "גוגל לא רואה את האתר שלי", הוא בעצם מתכוון לאחד מ-3 דברים שונים לגמרי, גוגל לא מצליח להגיע (crawling), גוגל מגיע אבל לא מצליח לרנדר את ה-JS (rendering), או גוגל מגיע ורואה הכל אבל מחליט שזה לא שווה אינדוקס (indexing). הפתרון לכל אחד מהם שונה לחלוטין. במאמר הזה אני אעבור איתכם על כל שלב, איך לזהות, איך לתקן, ואיפה רוב המקדמים נופלים. אם אחרי המאמר אתם עדיין תקועים, יש לכם איך לדבר איתי ישירות.

אגב, השם שמוליק דורינבאום מאחורי המקלדת כאן, 20 שנה בעולם ה-SEO, ‏אני אישית טיפלתי במאות מקרים של "העמוד לא מופיע". בכל פעם, התחלתי באבחנה הזאת בדיוק. crawl או index? בלי האבחנה הזאת, אתם זורקים זמן.

🔄 3 השלבים, Crawl, Render, Index, וכיצד כל אחד יכול להיכשל

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

שלב 1, Crawling

Googlebot מגיע ל-URL שלכם דרך אחת מ-4 דרכי discovery (סייטמאפ, ‏לינק חיצוני, ‏לינק פנימי, ‏הגשה ידנית). הוא בודק את robots.txt, ‏רואה אם מותר לו, ‏ואז שולח בקשת HTTP GET ומוריד את ה-HTML הראשוני. אם השרת מחזיר 200 OK, ‏הסריקה הצליחה. אם הוא מחזיר 4xx, ‏5xx, ‏או timeout, ‏הסריקה נכשלת ו-Googlebot ינסה שוב מאוחר יותר.

שלב 2, Rendering

הנה השלב שכולם מפספסים. גוגל לוקח את ה-HTML הגולמי שהוריד, ‏ומחליט אם הוא צריך להריץ עליו JavaScript כדי לראות את התוכן הסופי. אם האתר שלכם React, ‏Vue, ‏Angular, ‏או כל SPA אחר, ‏ה-HTML הראשוני בדרך כלל ריק כמעט (רק `

שלב 3, Indexing

אחרי הרינדור, ‏גוגל מנתח את העמוד הסופי. הוא מסתכל על הכותרת, ‏ה-meta description, ‏ה-canonical, ‏ה-structured data, ‏איכות התוכן, ‏ייחודיות, ‏רלוונטיות. ואז מקבל החלטה, להכניס לאינדקס או לא. אם כן, באיזה priority. אם לא, באיזה סטטוס. זה השלב הערכי, ‏ופה רוב הבעיות שאני רואה אצל לקוחות.

איך כל אחד נכשל

1. Crawl נכשל

   robots.txt חוסם, ‏השרת מחזיר 5xx, ‏ה-URL לא נמצא בכלל (אין סייטמאפ, ‏אין לינק).

2. Render נכשל

   ה-JS זורק שגיאה, ‏טוקן ה-API פג, ‏התוכן ניטען אחרי 30 שניות (גוגל לא מחכה).

3. Index נכשל

   תוכן דק, ‏duplicate של עמוד אחר, ‏canonical מצביע על אחר, ‏noindex, ‏איכות נמוכה.

בכל אבחנה שלי, אני שואל קודם, באיזה שלב זה תקוע? בלי התשובה לזה, אתם פותרים את הבעיה הלא נכונה.

🗺 איך גוגל מגלה בכלל את העמוד שלכם, 4 דרכי discovery

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

1. XML Sitemap

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

2. קישורים חיצוניים

אם אתר אחר מקשר אליכם, ‏Googlebot שסורק את האתר ההוא יראה את הקישור, ‏ויוסיף את ה-URL שלכם לתור הסריקה. ככה גוגל גילה דברים לפני שהיו סייטמאפים בכלל. עד היום זאת אחת הסיבות שלינקים חיצוניים חשובים, ‏לא רק ל-authority, ‏גם ל-discovery.

3. קישורים פנימיים

כשגוגל סורק עמוד באתר שלכם, ‏הוא קורא את כל הלינקים שמופיעים בו ומוסיף אותם לתור. אם יש לכם עמוד שאף עמוד אחר לא מקשר אליו (מה שנקרא orphan page), ‏גוגל אולי לעולם לא יגיע אליו, ‏גם אם הוא בסייטמאפ. הסייטמאפ הוא רמז, ‏לא הוראה.

4. הגשה ידנית, Request Indexing

ב-Search Console יש כלי URL Inspection שמאפשר לכם להגיש URL ספציפי לסריקה. גוגל יסרוק אותו תוך שעות בדרך כלל. שימושי לעמודים חדשים שאתם רוצים שיופיעו מהר, אבל יש לזה גבולות (אני מסביר בפרק 9).

בסופו של דבר, ‏discovery זה לא הצעד שגוגל נכשל בו הכי הרבה. אבל כשהוא נכשל, ‏הוא נכשל בשקט מוחלט. אין דוח שיגיד לכם "גוגל לא מכיר את ה-URL הזה". הוא פשוט לא יופיע בשום מקום ב-Search Console. אם אתם מחפשים URL ב-URL Inspection וגוגל אומר "URL is unknown to Google", ‏זה discovery failure. ‏הגישו בסייטמאפ, ‏בנו לינק פנימי, ‏ולחצו Request Indexing.

📋 כל הסטטוסים ב-Coverage Report, מה כל אחד אומר באמת

דוח ה-Pages report ב-Search Console (לשעבר Coverage) הוא הכלי החשוב ביותר שלכם להבנת מצב האינדוקס. הבעיה, ‏רוב המקדמים מסתכלים עליו ורואים מספרים ירוקים ואדומים בלי להבין מה כל קטגוריה אומרת באמת. בואו נפרק את הסטטוסים העיקריים, ‏אחד אחד, עם תרגום לעברית של מה זה אומר בפועל ומה הדחיפות.

הקטגוריות המתסכלות באמת הן Crawled/Discovered currently not indexed וה-Duplicate without user-selected canonical, כי הן אומרות שמשהו שלכם כן נסרק אבל גוגל לא רוצה אותו. בפרקים הבאים אני אצלול לעומק לכל אחת.

אגב, גוגל מדגים רק חלק מה-URLs בכל קטגוריה (לרוב עד 1,000), ‏אז אם יש לכם אתר ענק עם 50,000 עמודים ב-Crawled not indexed, ‏אתם לא רואים את כולם. תורידו את הקובץ עם Export, ‏או חברו את ה-Search Console ל-BigQuery כדי לקבל את כל הנתונים. רוב המקדמים מסתפקים בדוגמאות, ולכן מפספסים את הדפוסים האמיתיים שגורמים לבעיות.

😤 Crawled, currently not indexed, הסיוט הקבוע של כל מקדם

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

1. איכות תוכן נמוכה

הסיבה הכי נפוצה. גוגל מסתכל על העמוד ומחליט שהוא לא מספיק טוב כדי להופיע בתוצאות. תוכן דק (פחות מ-300 מילים בנושא שדורש 2,000), ‏תוכן מועתק או דומה לעמודים אחרים שלכם, ‏תוכן AI גרידא בלי הוספת ערך, ‏תוכן ישן שלא עודכן שנים. כל אלו מורידים את ה-priority. במיוחד מאז עדכוני ה-Helpful Content של גוגל, הסף עלה משמעותית.

2. Duplicate או דמיון לעמוד אחר באתר שלכם

אם יש לכם 4 עמודים שכולם מכסים את אותו נושא, ‏גוגל יבחר אחד ויזרוק את השאר ל-"crawled not indexed". זאת בעצם קניבליזציה של מילות מפתח שמתבטאת באינדוקס.

3. אות חלש מהאתר עצמו

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

4. אתר חדש או בעל סמכות נמוכה

אתר טרי (פחות מ-6 חודשים) או אתר ללא backlinks, ‏גוגל יבחר להיות שמרני. הוא ייקח את העמודים הראשיים שלכם (homepage, ‏שירותים) ויזניח את ה-200 פוסטי בלוג עד שיוכיחו את עצמם. זה לא אישי, זה איך גוגל מטפלת באתרים חדשים, היא מחכה שתוכיחו את עצמכם.

5. שגיאות טכניות שלא ראיתם

הכי מתסכל. ‏העמוד מחזיר 200 OK, ‏אבל יש בו בעיה שגוגל זיהה, ‏canonical שמצביע לעמוד אחר, ‏hreflang שגוי, ‏soft 404, ‏או redirect chain. ‏בדקו ב-URL Inspection את הסטטוס המדויק.

איך פותרים

• שפרו את התוכן, ‏הוסיפו עומק, ‏מקוריות, ‏ערך אמיתי
• חזקו לינקים פנימיים שמובילים לעמוד
• בדקו canonicals שמכוונים נכון
• אם זה duplicate, ‏החליטו לאחד או למחוק (ראו פרק 13)
• סבלנות, ‏לפעמים זה עניין של זמן ושיפור הדרגתי של ה-authority של האתר
• אל תהיו אובססיביים לעמודים בודדים אם 90% מהאתר באינדקס

תקשיבו, "Crawled, currently not indexed" זאת לא בעיה טכנית שאתם יכולים לתקן בקליק. זאת אבחנה איכותית של גוגל על העמוד שלכם. הפתרון לא ב-htaccess, ‏הפתרון בתוכן.שמוליק דורינבאום

🔭 Discovered, currently not indexed, ההבדל מ-Crawled ומה עושים

זה הסטטוס שמבלבל הכי הרבה אנשים. "Discovered" נשמע דומה ל-"Crawled", אבל זה שונה לחלוטין. אם תזכרו רק דבר אחד מהפרק הזה, שיהיה זה, Discovered = גוגל יודע שה-URL קיים אבל עדיין לא סרק אותו. בזמן ש-Crawled אומר שגוגל סרק והחליט לא להכניס, Discovered אומר שגוגל עדיין לא בא לבקר.

למה זה קורה

1. חוסר crawl budget

   גוגל מקצה לכל אתר תקציב סריקה (ראו crawl budget optimization). אם האתר שלכם עצום (10,000+ עמודים) או איטי, ‏גוגל מחליט להתעדף עמודים אחרים ולדחות את ה-URL שלכם.

2. אות חלש על חשיבות העמוד

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

3. אתר חדש או בעל שיא טכני גרוע

   אם השרת איטי, ‏גוגל מצמצם את הסריקה כדי לא להעמיס. עמודים בתור יחכו.

4. גוגל פשוט עוד לא הגיע

   במיוחד בעמודים חדשים שעולים, ‏לפעמים זה לוקח שבועות פשוט בגלל סדר התור.

איך לאבחן את הסיבה האמיתית

תפתחו URL Inspection לעמוד הספציפי. אם גוגל אומר "URL is on Google" בעקבות "Discovered", פירוש הדבר שהיא נכנסה אבל לקח זמן. אם זה אומר "Crawled, not indexed", המצב השתנה. אם זה אומר "Discovered, currently not indexed", זה עדיין באותו מצב, וצריך פעולה.

השוואה מעשית

גם זה וגם זה אומרים "לא באינדקס", אבל הפתרון לכל אחד שונה לגמרי. אם תפתרו את Discovered עם תיקוני תוכן, ‏אתם תפסידו זמן. אם תפתרו את Crawled עם שיפור crawl budget, ‏גם זה לא יעבוד. תאבחנו קודם, ‏תפעלו אחר כך.

🎬 Rendering, השלב שמשפיל הכי הרבה אתרים בלי שהם יודעים

הנה השלב שתשעים אחוז מהמקדמים לא מודעים אליו. גוגל לא קורא את ה-HTML הסופי של עמודי React/Vue/Angular מיד עם הסריקה. הוא לוקח את ה-HTML הראשוני (שלרוב ריק), ‏שם את העמוד בתור רינדור, ‏ורק אחרי כמה שעות (לפעמים ימים), ‏מריץ עליו Chromium headless כדי לראות את התוצאה הסופית.

למה זה בעיה

אם האתר שלכם SPA והשרת מחזיר HTML שנראה ככה,

<!DOCTYPE html>
<html>
<head><title>My App</title></head>
<body>
<div id="root"></div>
<script src="app.js"></script>
</body>
</html>

גוגל בשלב הראשון רואה כלום. אין כותרת, ‏אין תוכן, ‏אין links. כל מה שיש זה תג ריק. רק אחרי שהרינדור יקרה, ‏גוגל יראה את התוכן האמיתי. אבל בינתיים, ‏העמוד שלכם נחשב ריק.

3 הבעיות הנפוצות של רינדור

1. תור רינדור ארוך

   אם האתר שלכם דורש הרבה משאבים (תמונות גדולות, ‏JS כבד, ‏API calls), גוגל מקצה לו פחות resources, ‏וההמתנה ארוכה יותר. עדכוני תוכן לא משפיעים על SEO לימים.

2. JS שזורק שגיאה

   אם ה-JS שלכם נשבר באמצע (חסר polyfill, ‏API לא מגיב, ‏race condition), גוגל ירנדר HTML חלקי או ריק.

3. תוכן שדורש interaction

   אם התוכן נטען רק אחרי click או scroll, ‏גוגל לא יראה אותו. הוא לא לוחץ, ‏הוא לא גולל. הוא טוען את העמוד וצופה במצב הסטטי.

איך מאבחנים

פתחו URL Inspection ב-Search Console, לחצו "Test Live URL", ולאחר מכן "View Tested Page". שני המצבים החשובים, "HTML" (מה שגוגל רואה אחרי הרינדור), "More Info > Page Resources" (אילו קבצים נטענו, אילו נכשלו). אם הסקרינשוט ריק או חלקי, יש בעיית רינדור.

🚫 robots.txt מול noindex, הטעות הקלאסית שכל מתחיל עושה

תקשיבו, זאת הטעות הכי קלאסית בספר. אתם רוצים להסיר עמוד מתוצאות החיפוש, ‏אז אתם, ‏מוסיפים ל-robots.txt חסימה והוספים noindex במטא טאג. נשמע נכון, ‏לא? זה לא עובד. נחשו למה? כי שני המנגנונים האלה עושים דברים שונים לחלוטין, ופועלים בשלבים שונים של התהליך.

מה כל אחד עושה באמת

למה השילוב לא עובד

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

הכלל הנכון

מתי להשתמש בכל אחד

1. robots.txt

   למשאבים שלא חשובים ל-SEO ושאתם רוצים לחסוך בהם crawl budget. ‏לדוגמה, /admin/, /wp-admin/, /api/internal/, /cdn-cgi/. ‏גוגל לא צריך לסרוק את זה, ‏וזה לא יופיע בתוצאות בכל מקרה.

2. meta noindex

   לעמודים שאתם רוצים שלא יופיעו בתוצאות אבל גוגל יכול לסרוק (כדי לראות את התג). ‏לדוגמה, ‏עמוד תודה אחרי טופס, ‏עמוד שכפול שמיועד לפילטר פנימי, ‏עמוד תוצאות חיפוש פנימי.

3. שילוב

   רק במקרה אחד, ‏אתם רוצים גם לחסוך crawl וגם לוודא שלא יופיע. ‏בשלב ראשון רק noindex, ‏מחכים שגוגל יראה ויסיר מהאינדקס, ‏ואז מוסיפים גם robots.txt. ‏אף פעם לא בו זמנית.

לפרטים מלאים על robots.txt, ‏ראו את המדריך המלא לrobots.txt.

🔁 Request Indexing, מתי כדאי ומתי לא

הכלי "Request Indexing" ב-URL Inspection הוא אחד מהדברים השימושיים ביותר ב-Search Console. הוא נותן לכם לבקש מגוגל לסרוק URL ספציפי מיד, מבלי לחכות לסבב הסריקה הטבעי. בעולם שבו דברים יכולים לקחת שבועות, זה משנה את כל המשחק. אבל יש לכלי הזה גבולות ברורים, ויש מצבים שהשימוש בו פשוט מבזבז זמן. בואו נסדר את זה.

מתי כן להשתמש

1. עמוד חדש קריטי

   פרסמתם עמוד חדש שאתם רוצים שיהיה בגוגל מחר. הגישו דרך URL Inspection. גוגל בדרך כלל יסרוק תוך 1-24 שעות, ולפעמים אפילו מהר יותר. אם זה עמוד מכירות חשוב או דף נחיתה לקמפיין, זה ההבדל בין לידים ביום הראשון להמתנה של שבוע.

2. עמוד שעודכן משמעותית

   שיפרתם תוכן, ‏הוספתם פרקים, ‏עדכנתם schema. הגישו כדי שגוגל יראה את הגרסה החדשה ולא ימשיך להציג snippet ישן. במיוחד חשוב כשעדכנתם meta title או description ואתם רוצים שזה ישפיע מהר על ה-CTR.

3. תיקון בעיה טכנית

   היה לכם canonical שגוי, noindex בטעות, או robots.txt שחסם. תיקנתם. הגישו כדי שגוגל יבדוק שוב, אחרת הוא יזכור את הסטטוס השגוי לחודשים.

4. אחרי 301 redirect

   העברתם עמוד מ-URL ישן ל-URL חדש. הגישו את שני ה-URLs (גם הישן וגם החדש) כדי שגוגל יבין את ההעברה מהר וירשת את ה-authority.

מתי לא להשתמש

1. כשהבעיה היא איכות תוכן

   אם העמוד תקוע ב-"Crawled, currently not indexed" בגלל תוכן חלש, ‏Request Indexing לא יעזור. גוגל כבר ראה, ‏החליט לא, ‏ויחליט שוב לא. תקנו את התוכן קודם, ורק אחר כך תגישו.

2. על batches גדולים

   גוגל מגביל את כמות ה-requests לדומיין. אם יש לכם 5,000 עמודים, ‏זה לא יעבוד. השתמשו ב-Indexing API (פרק 14) או חכו ל-discovery טבעי דרך סייטמאפ ולינקים פנימיים.

3. לעמודים שלא חשובים

   אל תבזבזו quota על עמודי טאגים, archives, או עמודי פילטרים. שמרו את ה-Request Indexing לעמודים שבאמת מניבים תנועה והכנסה.

4. אותו URL שוב ושוב

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

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

👻 Soft 404 מול 404 רגיל, הבדל קריטי

זה אחד הסטטוסים הכי לא מובנים. soft 404 לא קיים בעולם ה-HTTP. אין קוד תגובה כזה. זה תווית שגוגל ממציאה כדי לתאר עמוד שמתנהג כמו 404 למרות שהשרת מחזיר 200 OK. ובהרבה מקרים, ‏זה רעה גדולה לאינדקס שלכם. תקשיבו, רוב המקדמים אפילו לא יודעים שיש להם soft 404 באתר, עד שהם רואים את הדוח ב-Search Console ושואלים מה זה בכלל.

מה זה 404 רגיל

השרת מחזיר HTTP status 404 Not Found. ‏זאת אמירה ברורה, "העמוד לא קיים". גוגל מסיר אותו מהאינדקס, ‏וזה תקין. גוגל יחזור לבדוק מדי פעם אם אולי העמוד חזר, אבל אם הוא ימשיך לקבל 404, בסוף הוא יוותר.

מה זה soft 404

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

1. תוכן "לא נמצא" מותאם אישית עם 200

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

2. עמוד מוצר אזל מהמלאי

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

3. עמוד עם תוכן זעיר

   40 מילה, אין H1, אין תוכן ממשי. גוגל חושב "זה ניסיון לדמות עמוד".

4. JS-rendered עם רינדור כושל

   אם הרינדור נכשל וגוגל רואה רק Loading..., יסמן soft 404. זאת אחת הסיבות הכי שכיחות באתרי SPA, ורוב המקדמים לא מקשרים בין הדברים.

5. עמוד עם redirect ב-JS

   אם העמוד טוען ואז מבצע window.location ל-URL אחר, גוגל יראה את ה-HTML הראשוני שאומר "Redirecting..." ויסיק soft 404. השתמשו ב-301 בצד השרת.

למה זה גרוע

גוגל יסיר את העמוד מהאינדקס, ‏ובניגוד ל-404 רגיל, ‏גם יהיה לכם דוח שלם של "Soft 404" ב-Coverage report, ‏מה שגורם לאות איכות שלילי כללי על האתר. אם יש לכם 500 soft 404, ‏זה אומר שהאתר שלכם בעיני גוגל מלא בעמודים שמתחזים לתוכן ולא נותנים, וזה משפיע על כל האתר, לא רק על העמודים האלה.

איך פותרים

• אם זה דף שגיאה אמיתי, ‏החזירו status 404 (לא 200) או 410 Gone
• אם זה מוצר שאזל, ‏החזירו תוכן עשיר (תיאור מוצר, ‏מוצרים דומים, ‏אפשרות "הודיעו לי כשחוזר")
• אם זה עמוד דק, ‏הוסיפו תוכן אמיתי או מחקו
• אם זה JS rendering, ‏עברו ל-SSR או SSG
• בדקו ב-URL Inspection מה גוגל רואה אחרי הרינדור

לעומק, ‏ראו את המדריך לsoft 404.

📱 Mobile-First Indexing, מה זה אומר ל-crawling/indexing שלכם

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

מה זה אומר בפועל

1. תוכן שמוסתר במובייל לא קיים ב-SEO

   אם יש לכם תוכן שמוצג רק בדסקטופ (במדיה queries או JS conditionals), ‏גוגל לא יראה אותו. עמודים שמסתירים פסקאות במובייל "לקריאות" איבדו תנועה בצורה דרמטית. אם זה חשוב לקרוא בדסקטופ, זה חשוב באותה מידה במובייל.

2. structured data חייב להופיע בגרסה הניידת

   JSON-LD שיש רק בדסקטופ ולא במובייל, ‏לא יחשב לאינדוקס ולא יזכה לתצוגות עשירות ב-SERP. וודאו שאתם מזריקים את אותו schema בשני המצבים.

3. navigation במובייל קובע discovery

   אם המגה-תפריט שלכם בדסקטופ מכיל 200 לינקים אבל במובייל יש רק hamburger עם 10 פריטים, ‏גוגל יסרוק רק את ה-10. שאר הלינקים יחשבו פחות חשובים. ה-internal linking שלכם בעצם נחתך.

4. מהירות במובייל קובעת crawl rate

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

איך לאבחן

מה לבדוק

• אותו תוכן בדיוק במובייל ובדסקטופ (לא מסתירים בגרסת מובייל)
• אותו structured data בשני המצבים
• אותה navigation (לפחות אותם לינקים מרכזיים)
• אותו meta title, description, robots tags
• אותם images עם אותו alt text
• מובייל מהיר (LCP מתחת ל-2.5 שניות)
• Viewport meta tag נכון
• fonts קריאים (לא קטנים מ-12px)

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

💥 Index Bloat, כשגוגל מכניס לאינדקס דברים שלא רציתם

הצד השני של המטבע. רוב המאמרים על אינדוקס מדברים על איך להכניס עמודים לאינדקס. אבל יש בעיה ההפוכה, ‏וחמורה לא פחות, ‏index bloat. ‏זה כשגוגל מכניס לאינדקס אלפי עמודים שאתם לא רוצים שיהיו שם, ‏ומדלל את ה-authority של האתר. במקרה אחד ראיתי אתר עם 200 עמודים אמיתיים ועוד 80,000 עמודי "זבל" באינדקס. רוב המקדמים אפילו לא יודעים שזה קורה להם.

הסיבות הנפוצות

1. עמודי פילטרים בחנות

   WooCommerce/Shopify יוצרים URLs כמו /shop?color=red&size=M&sort=price לכל קומבינציה. גוגל סורק ומכניס לאינדקס מאות אלפי וריאציות, ‏רובן עם תוכן זהה.

2. עמודי טאגים אוטומטיים

   WordPress יוצר עמוד לכל tag, ‏לכל category, ‏לכל author, ‏לכל ארכיון תאריך. אם לא חסמתם, ‏גוגל מכניס. כל פעם שכותב כותב פוסט עם 5 תגיות, יש לכם 5 עמודי tag חדשים פוטנציאליים באינדקס.

3. עמודי search results פנימיים

   הסיוט. כל חיפוש פנימי של משתמש יוצר URL כמו /?s=keyword וגוגל סורק את כולם. ‏יש אתרים עם 50,000 עמודי search באינדקס, כולם עם תוצאות חיפוש שונות, כולם בעצם תוכן דק.

4. סשנים ופרמטרים

   UTM tags, ‏session IDs, ‏tracking parameters. כל אחד יוצר URL חדש מבחינת גוגל. אם אין canonical חזק, גוגל מכניס את כל הגרסאות.

5. גרסאות מודפסות, AMP, ‏או mobile

   אם לא הוגדרו canonical כמו שצריך, ‏גוגל מכניס את כולן בנפרד.

למה זה גרוע

גוגל מפזר את ה-crawl budget ואת ה-authority של האתר על אלפי עמודי "זבל". העמודים האמיתיים שאתם רוצים שידורגו, ‏מקבלים פחות תשומת לב. ‏המיקומים יורדים, ‏הסריקה איטית יותר, ‏גוגל מבולבל מה האתר שלכם בעצם. בנוסף, האותות איכותיים השליליים מהעמודים הריקים מתפזרים על האתר כולו.

איך לזהות ולפתור

1. הרצו site:yoursite.co.il ב-גוגל. אם המספר גבוה משמעותית ממה שאתם מצפים, ‏יש bloat
2. בדקו ב-Search Console > Pages > Indexed, ‏ראו דוגמאות של URLs ומצאו את הדפוסים
3. חסמו פרמטרים מיותרים ב-robots.txt, ‏לדוגמה Disallow: /*?s=
4. הוסיפו canonical חזק לעמודים הראשיים
5. השתמשו ב-noindex לעמודים שאתם לא רוצים אבל גוגל צריך לסרוק
6. קבעו פרמטרים ב-Search Console (אופציה ישנה אבל עוד עובדת)
7. הוסיפו rel="nofollow" ללינקים פנימיים שמובילים לפילטרים

🗑 איך להסיר עמוד מהאינדקס לתמיד, 3 דרכים (אחת מהן רעה)

לקוח שואל אותי "שמוליק, יש עמוד באינדקס שאני רוצה להסיר, איך אני עושה?". יש 3 דרכים, ‏ולכל אחת מצב שמתאים לה. אבל אחת מהן זה כמעט תמיד טעות.

הדרך 1, meta noindex (הכי טובה)

הוסיפו ל-head של העמוד,

<meta name="robots" content="noindex,follow">

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

הדרך 2, HTTP header (לקבצים שאינם HTML)

אם זה PDF, ‏Word, ‏או כל סוג קובץ אחר שאי אפשר להוסיף לו meta tag, ‏השתמשו ב-HTTP header,

X-Robots-Tag: noindex

בקובץ .htaccess, אפשר להגדיר לפי סוג קובץ או נתיב. גם פה גוגל צריך לסרוק כדי לראות את ההוראה.

הדרך 3, Removals Tool ב-Search Console (לזמני בלבד)

זאת הדרך שכולם פונים אליה ראשונה. ‏פתחו Search Console > Removals > New Request. ‏גוגל יסיר את העמוד מתוצאות החיפוש תוך שעות. ‏מהיר, ‏נכון? ‏אבל יש בעיה, ‏זה זמני (6 חודשים בלבד). ‏אחרי 6 חודשים, ‏אם לא הוספתם noindex או הסרתם את העמוד מהשרת, ‏הוא יחזור לאינדקס. ‏הכלי הזה מיועד לחירום, ‏לא לפתרון קבוע.

הדרך הרעה, 301 לעמוד אחר

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

410 Gone, הדרך שאתם שוכחים

אם אתם מוחקים עמוד לתמיד, ‏השרת בדרך כלל מחזיר 404 (Not Found). זה אומר לגוגל "אולי טעות, ‏נסה שוב מאוחר יותר". זה מצב לימינלי שיכול להישאר ב-Coverage report לחודשים. ‏פתרון נקי יותר, ‏החזירו 410 Gone. ‏זה אומר "נמחק לתמיד, ‏לא יחזור". גוגל יסיר מהאינדקס מהר יותר. ‏ב-htaccess זה RedirectMatch 410 ^/old-page/?$.

⚡ Indexing API, האם זה רלוונטי לאתר שלכם?

גוגל יש לה API בשם Indexing API שמאפשר להגיש URLs לאינדוקס באופן תכנותי. ‏זה ה-Holy Grail שכולם רוצים, ‏פטור מההמתנה הארוכה. ‏אבל יש את המוקש הענקי, זה מיועד רק לסוגי תוכן ספציפיים. רוב המקדמים שמדברים על Indexing API כפתרון לכל הבעיות שלהם, פשוט לא קראו את התיעוד עד הסוף.

למי זה רשמית מיועד

גוגל מצהירה במפורש שה-Indexing API מיועד אך ורק ל-2 סוגי תוכן,

1. JobPosting, ‏מודעות דרושים שיש להן נטייה להיווצר ולהיעלם במהירות
2. BroadcastEvent embedded in VideoObject, ‏שידורים חיים שצריך לסמן מתי הם מתחילים

זהו. ‏אם אתם לא בלוח דרושים או אתר שידורים חיים, ‏רשמית גוגל לא יעבד את הבקשות שלכם. הם יכולים לקבל את הקריאה ל-API ולהחזיר 200 OK, אבל זה לא אומר שהם יעשו עם זה משהו.

אבל מה שאומרים בקהילה

הרבה מקדמים השתמשו ב-Indexing API לכל סוגי התוכן, ‏וזה עבד. ‏גוגל עדיין מקבל את הבקשות, ‏ולפעמים מאנדקס. ‏אבל,

החלופה, IndexNow

IndexNow היא יוזמה של Bing ו-Yandex שמאפשרת להודיע למנועי חיפוש על URLs חדשים או מעודכנים. גוגל לא תומכת רשמית, ‏אבל Bing, ‏Yandex, ‏Naver, ‏Seznam, ‏וכל מנועי החיפוש האירופיים והאסיאתיים תומכים. ‏זה פתרון נקי לאתרים שמעניין אותם תנועה מ-Bing וחבריו. וורדפרס יש פלאגין שמיישם את זה אוטומטית.

מי באמת צריך Indexing API

מה כן עובד לרוב האתרים

השילוב המוכח, סייטמאפ מעודכן + ping ל-Google על שינויים + Request Indexing למקרים בודדים + תוכן איכותי + internal linking חזק. ‏פחות סקסי מ-API, ‏אבל זה מה שעובד באמינות. ‏אל תנסו לחפש shortcut למקום שאין לו. תאמינו לי, ראיתי הרבה אתרים שניסו את זה והגיעו לבעיות במקום לפתרונות.

✅ צ'ק ליסט של 12 נקודות לאודיט indexability חודשי

אם אחרי כל המאמר אתם רוצים רק דבר אחד, שזאת תהיה הרשימה הזאת. אני עובד לפיה ב-90% מהאתרים שאני מנהל. הריצו אותה פעם בחודש, ‏ותפסו את הבעיות לפני שהן הופכות לקטסטרופה. רוב המקדמים מסתפקים בהסתכלות ב-Search Console פעם בשבועיים. זה לא מספיק, צריך שיטה.

• 1. השוו את מספר העמודים שלכם למה שב-Google, ‏הריצו site:yoursite.co.il והשוו למספר העמודים בסייטמאפ. ‏חריגה גדולה לכל כיוון = בעיה
• 2. בדקו את Coverage Report, ‏עברו על כל הסטטוסים בעיקר Crawled/Discovered currently not indexed
• 3. הריצו URL Inspection על 5 עמודים אקראיים, ‏וודאו שגוגל רואה אותם בצורה תקינה, ‏גם בגרסת מובייל
• 4. בדקו את robots.txt, ‏וודאו שאין שורה ששוברת לכם משהו חשוב (זה קורה אחרי deployments)
• 5. בדקו canonical URLs, ‏לפחות 5 עמודי דוגמה, ‏שאין canonical loop או canonical שגוי
• 6. בדקו Soft 404, ‏אם יש שלם, ‏מצאו את הדפוס ותקנו
• 7. בדקו 404 ו-5xx, ‏עם רצוי שתהיה תכנית redirect או הסבר למה הם נמחקו
• 8. בדקו את crawl stats, ‏ב-Settings > Crawl Stats. ‏ירידה הדרגתית = בעיית server response time
• 9. בדקו את הסייטמאפ, ‏וודאו שהוא מעודכן, ‏שכל ה-URLs מחזירים 200, ‏ושאין כפילויות
• 10. בדקו mobile-first, ‏השוו 3 עמודים בתצוגת מובייל מול דסקטופ, ‏וודאו שאותו תוכן בדיוק
• 11. בדקו תוצאות בגוגל בפועל, ‏חפשו את שם המותג + 3 קווריז ראשיות, ‏וודאו שאתם מופיעים
• 12. בדקו את ה-rendering, ‏אם האתר JS-heavy, ‏פתחו URL Inspection וצפו ב-Tested Page > Screenshot

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

❓ שאלות נפוצות