Index Bloat, אינדקס מנופח וכיצד לפתור

💥 מה זה Index Bloat, ‏וכיצד תזהו אם יש לכם

תקשיבו. אני אפתח עם הסיפור שאני שומע פעם בשבוע. לקוח מגיע, ‏אומר "שמוליק, יש לי אתר עם 250 עמודים אמיתיים, ‏אני לא מבין למה הדירוגים שלי לא עולים". אני שואל, "בדקת כמה עמודים יש לך בגוגל?". הוא לא יודע. אני מריץ site:yoursite.co.il וגוגל אומר "About 47,000 results". 47,000 ‏עמודים, ‏מתוכם 250 ‏שהוא יודע עליהם. השאר? ‏פילטרים, ‏טאגים, ‏ארכיון, ‏עמודי חיפוש פנימי, ‏שילובים אינסופיים של פרמטרים. זה Index Bloat. נקודה.

בואו נגדיר את זה בלי בלגן. Index Bloat זה מצב שבו גוגל מאנדקסת מהאתר שלכם הרבה יותר עמודים ממה שאתם רוצים, ‏רובם בעלי ערך נמוך עד אפסי. עמודי פילטרים מסחר, ‏עמודי tag/category של WordPress, ‏עמודי author/date archive, ‏עמודי תוצאות חיפוש פנימי, ‏עמודים אוטומטיים של תוספים, ‏ושילובי URL פרמטרים. כל אחד מהם בנפרד נראה תמים, ‏ביחד הם מנפחים את האינדקס שלכם פי 100 ופוגעים בכל העמודים האמיתיים.

הבדיקה המהירה של 30 שניות

פתחו את גוגל וחפשו site:yoursite.co.il. הסתכלו על המספר שמופיע. עכשיו פתחו את ה-sitemap.xml שלכם ובדקו כמה URLs יש בו. אם המספר ב-גוגל גדול ב-30% או יותר מהסייטמאפ, יש לכם Index Bloat. אם המספר גדול פי 10 או יותר, יש לכם בעיה חמורה שדורשת טיפול שיטתי.

למה זה קורה גם לכם בלי שאתם יודעים

הסיבה הגדולה ביותר שמקדמים לא יודעים שיש להם Index Bloat, ‏גוגל לא מתריעה. ‏אין דוח ב-Search Console שכותב "היי, ‏יש לך 80,000 עמודי זבל". ‏אתם רואים את עצמכם כ-"Indexed" ירוק וחושבים שהכל בסדר. ‏רק כשבודקים site: ב-גוגל ומשווים, ‏רואים את ההפרש. ‏רוב מנהלי האתרים שאני פוגש מגלים את ה-bloat שלהם בפעם הראשונה רק כשאני מצביע עליהם, ‏גם אחרי שנים של ניהול האתר.

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

📉 למה זה הורס SEO, ‏4 הנזקים האמיתיים

הרבה מקדמים אומרים "מה זה משנה אם יש לי 50,000 עמודי פילטרים באינדקס? ‏גוגל לא מציג אותם בתוצאות בכל מקרה". זה לא נכון. ‏יש 4 נזקים אמיתיים, ‏מדידים, ‏ש-Index Bloat גורם לאתר.

1. בזבוז Crawl Budget

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

2. דילול אותות איכות

   גוגל מסתכל על האתר שלכם כיחידה אחת. אם יש לכם 200 עמודי תוכן איכותי + 50,000 עמודים דקים, ‏הממוצע נמשך מטה. ה-Quality Raters Guidelines של גוגל מדברים על "site-wide quality assessment". אתר שמרבית עמודיו דקים מסומן כ-"low quality" גם אם יש בו פנינים.

3. קניבליזציה רחבת היקף

   עמודי פילטרים ו-tag pages רבים מכסים את אותם נושאים. הם מתחרים אחד בשני וגם בעמודים הראשיים שלכם. גוגל מתבלבל איזה עמוד הוא ה-canonical האמיתי. ‏ראו מדריך קניבליזציה לפירוט.

4. סיכון לעונש Helpful Content רחב-אתר

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

Index Bloat זה לא בעיה אסתטית. זה גורם פעיל לירידה במיקומים של עמודים שלא קשורים בכלל לבעיה. אתר עם 80,000 עמודי זבל יכול לראות את עמוד הבית שלו יורד 5 מקומות בלי סיבה נראית לעין. הסיבה היא ש-Quality Score של האתר כולו ירד.שמוליק דורינבאום

למה הנזק לרוב לא מורגש מיד

הנזק של Index Bloat מצטבר באיטיות. ‏אתר חדש עם 100 ‏עמודים שמוסיף 50 ‏עמודי tag בכל חודש, ‏לא ירגיש שום דבר ב-12 ‏החודשים הראשונים. ‏אבל אחרי 3 ‏שנים, ‏יש לו 1,800 ‏עמודי tag דקים, ‏ופתאום עדכון אלגוריתם של גוגל מוריד אותו ב-30%. ‏רוב הלקוחות שאני רואה הגיעו בדיוק במצב הזה, ‏בעדכון אלגוריתם ראשון שתפס אותם לא מוכנים, ‏בלי להבין למה כל המאמרים שלהם פתאום ירדו.

🌱 גורמים נפוצים, ‏10 מקורות bloat שכל אתר חוטא בהם

Index Bloat לא נופל מהשמיים. הוא תוצאה של 10 דפוסים שחוזרים בכל אתר שאני אבדק. אם תזהו את אלה, ‏כבר עברתם 80% מהדרך לפתרון.

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

   הגדול מכולם. ‏כל פילטר (צבע, ‏מידה, ‏מותג, ‏טווח מחיר) ‏יוצר URL חדש. שילובים של 5 פילטרים = ‏אלפי URLs מאותו 50 ‏מוצרים. ‏ראו מדריך faceted navigation.

2. עמודי tag ב-WordPress

   כל פוסט עם 5 ‏תגיות יוצר 5 ‏עמודי tag פוטנציאליים. אתר עם 200 ‏פוסטים יכול להגיע ל-800 ‏עמודי tag, ‏רובם עם 1-2 ‏פוסטים בכל אחד.

3. עמודי category לא מנוצלים

   אתרי WordPress יוצרים אוטומטית עמוד לכל קטגוריה. אם יש לכם 30 קטגוריות אבל אתם משתמשים בפועל ב-5, ‏יש לכם 25 ‏עמודי קטגוריה ריקים או דקים באינדקס.

4. ארכיון לפי תאריך

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

5. עמודי /author/

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

6. עמודי תוצאות חיפוש פנימי

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

7. עמודי pagination

   עמוד הראשי של בלוג עם /page/2/, ‏/page/3/, ‏וכן הלאה. כל אחד מהם מציג חלק שונה של אותם פוסטים. אם לא הוגדרו canonical או noindex, ‏כולם באינדקס.

8. עמודים אוטומטיים של תוספים

   תוספי SEO, ‏גלריות תמונה, ‏פורומים, ‏כל אחד מהם יוצר URLs משלו. WP-Forum יוצר עמוד לכל user profile, ‏תוסף גלריה יוצר עמוד לכל תמונה. ‏רובם דקים.

9. סשנים ופרמטרי tracking

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

10. גרסאות PDF/print/AMP

    אם יש לכם גרסת הדפסה של עמוד, ‏גרסת PDF, ‏או גרסת AMP, ‏וכל אחת ב-URL נפרד בלי canonical חזק, ‏יש לכם 3 ‏עמודים שונים באינדקס לכל עמוד.

איך לקבוע מהר אילו מקורות הכי דחופים לכם

לא כל מקור bloat שווה את אותו זמן טיפול. ‏הסדר לפי השפעה הוא, ‏(1) ‏עמודי פילטרים בחנות, ‏האפקט הכי גדול כי הם יוצרים מיליוני URLs, ‏(2) ‏עמודי tag/category ב-WordPress, ‏האפקט הגדול ביותר באתרי תוכן, ‏(3) ‏עמודי author/date archives, ‏אפקט בינוני אבל קל לתקן, ‏(4) ‏פרמטרי tracking, ‏אפקט בינוני, ‏פתרון פשוט עם canonical. ‏תתחילו מ-1 ו-2. ‏רוב האתרים מקבלים 80% מההחזר על השקעת זמן רק מהטיפול בשני הראשונים.

🇼 WordPress, ‏הבלגן שמגיע בברירת מחדל

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

4 מקורות ה-bloat המרכזיים ב-WordPress

1. Tag pages

   כל פוסט מתחיל עם הצעה לתגיות. ‏כותבים שמשתמשים ב-5-10 ‏תגיות לפוסט יוצרים מאות עמודי tag. ‏רובם דקים (1-3 ‏פוסטים בלבד). ‏עמודי tag דקים = ‏Index Bloat קלאסי.

2. Category pages

   שונה מ-tags, ‏אבל יוצר אותה בעיה. ‏אם יש לכם 20 ‏קטגוריות אבל בפועל פוסטים מתפזרים על 5, ‏יש לכם 15 ‏עמודי קטגוריה ריקים או דקים.

3. Author archives

   WordPress יוצר עמוד אוטומטי לכל משתמש שיש לו רמת contributor או יותר. גם אם המשתמש לא פרסם כלום. ‏רוב אתרי WordPress הקטנים יש להם 3-10 ‏עמודי author ריקים.

4. Date archives

   עמוד אוטומטי לכל חודש (yoursite.com/2024/05/), ‏לכל שנה (yoursite.com/2024/), ‏ולפעמים לכל יום. אתר עם 5 ‏שנות פעילות יש לו 60+ ‏עמודי archive.

הפתרונות לכל אחד

תוספים אחרים שגורמים bloat נסתר ב-WordPress

מעבר ל-4 ‏המקורות הקלאסיים, ‏יש תוספים שיוצרים bloat בלי שתדעו. ‏WooCommerce יוצר עמודי attribute לכל וריאציה, ‏BuddyPress יוצר עמוד לכל user/group/forum, ‏bbPress יוצר עמוד לכל topic/reply, ‏NextGEN Gallery יוצר עמוד לכל תמונה. ‏לכל אחד מהם, ‏בדקו את הגדרות ה-SEO הפנימיות שלו או הוסיפו noindex דרך פילטר ב-functions.php. ‏אם אתם מפעילים תוסף חדש, ‏תמיד בדקו אחרי שבוע site: ב-גוגל לראות אם נוצרו עמודים חדשים שאתם לא מתכננים שיהיו באינדקס.

🛒 Shopify ו-Magento, ‏ה-faceted nav nightmare

אתרי מסחר אלקטרוני סובלים מ-Index Bloat ברמה אחרת לגמרי מאשר WordPress. ‏הסיבה אחת, ‏faceted navigation. ‏כל פילטר שמשתמש לוחץ עליו יוצר URL חדש, ‏וגוגל סורק את כולם. ‏אם יש לכם חנות עם 5 ‏פילטרים ו-50 ‏ערכים אפשריים בכל אחד, ‏יש לכם פוטנציאל ל-מיליוני URLs.

Shopify, ‏הדפוס הקלאסי

Shopify יוצר אוטומטית עמודי collection. ‏עד כאן בסדר. ‏אבל לכל collection יש פילטרים (size, ‏color, ‏price). ‏וכל שילוב פילטרים = ‏URL חדש. ‏לדוגמה, ‏/collections/shirts?color=red+blue&size=M+L&sort=price-asc. ‏גוגל סורק את זה ומאנדקסת כעמוד נפרד. ‏עכשיו חשבו על השילובים האפשריים, ‏אתם מבינים את הבעיה.

Magento, ‏layered navigation infinite combinations

Magento גרוע יותר. ‏ה-layered navigation שלו מאפשרת combinations מורכבים יותר, ‏עם פרמטרים מקוננים. ‏אתר Magento טיפוסי בלי טיפול נכון יכול להגיע ל-500,000+ ‏עמודי פילטרים באינדקס. ‏ראיתי אתרים עם מיליון.

5 הפתרונות הספציפיים למסחר

1. canonical חזק לעמוד ה-collection הראשי, ‏כל וריאציה של פילטרים מצביעה ב-canonical על העמוד הבסיסי. ‏גוגל מאנדקסת רק את הראשי.
2. robots.txt חוסם פרמטרי פילטרים, ‏לדוגמה Disallow: /*?color=, Disallow: /*?size=. ‏גוגל לא סורק בכלל.
3. noindex על וריאציות פילטרים, ‏פתרון ביניים. גוגל סורק אבל לא מאנדקסת.
4. JS-rendered filters, ‏הפילטרים פועלים רק בצד הלקוח עם hashtag (#color=red). ‏גוגל לא רואה אותם בכלל.
5. POST instead of GET, ‏שולחים את הפילטרים ב-POST request, ‏לא משנים URL. ‏פתרון מעולה אבל דורש פיתוח.

השוואה מעשית

הסיפור של אתר Shopify שראיתי השבוע

לקוח הגיע אלי עם חנות Shopify של 80 ‏מוצרים. ‏הריץ site: ב-גוגל, ‏המספר היה 47,000. ‏פי 580 ‏מהמוצרים האמיתיים. ‏בדיקה גילתה, ‏פילטרים של color (12 ‏ערכים), ‏size (8 ‏ערכים), ‏brand (15 ‏ערכים), ‏וגם sort (4 ‏אפשרויות). ‏12 × 8 × 15 × 4 = ‏5,760 ‏שילובים, ‏כפול 8 ‏עמודי collection = ‏46,000+ ‏עמודים. ‏פתרון, ‏canonical חזק לעמוד ה-collection הראשי בכל וריאציה. ‏תוך 3 ‏חודשים, ‏האינדקס ירד ל-200, ‏ותנועה אורגנית עלתה ב-45%. ‏זה לא קסם, ‏זה רק תיקון של בעיית ארכיטקטורה.

📋 בדיקה ב-Search Console, ‏Pages report המורחב

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

השלבים המעשיים

שלב 1, פתחו את Pages report

היכנסו ל-GSC, ‏לחצו על Indexing > Pages. ‏שם יש לכם 2 ‏בלוקים, ‏"Why pages aren't indexed" (אדום) ו-"Indexed" (ירוק). ‏שניהם מקור מידע חשוב.

שלב 2, הקטגוריות הקריטיות לזיהוי bloat

• Crawled, currently not indexed, ‏גוגל סרק והחליט לא להכניס. ‏אם יש אלפי עמודים כאן ורובם פילטרים/tags, ‏זה bloat שגוגל כבר מסנן בעצמו (אבל עדיין מבזבז crawl budget)
• Discovered, currently not indexed, ‏גוגל יודע שקיימים אבל לא סרק. ‏לעיתים אלה עמודי bloat עתידיים
• Indexed, not submitted in sitemap, ‏הדגל האדום הגדול. ‏אם יש אלפי עמודים שלא בסייטמאפ אבל באינדקס, ‏אלה כמעט תמיד עמודי bloat שגוגל מצא לבד
• Duplicate without user-selected canonical, ‏עמודים שגוגל זיהה ככפילים. ‏אם הם פילטרים/tags, ‏זה אישור ל-bloat

שלב 3, חפירה לדפוסים

לחצו על כל קטגוריה ותראו עד 1,000 ‏דוגמאות URLs. ‏עברו עליהם וחפשו דפוסים, ‏האם רובם /tag/? ‏/?s=? ‏/?color=? ‏רשמו את הדפוסים. ‏אלה ה-bloat sources שלכם.

שלב 4, ייצוא לניתוח רחב

הקליקו Export > CSV או Google Sheets. ‏גוגל מציג רק 1,000 ‏דוגמאות, ‏אבל הייצוא נותן יותר רחב. ‏בקובץ, ‏סננו לפי דפוס URL וספרו כמה עמודים יש בכל דפוס. ‏יש לכם עכשיו את ה-bloat inventory שלכם.

השוואה לסייטמאפ שלכם

בגוגל Search Console, ‏לכו ל-Indexing > Sitemaps. ‏אם הגשתם sitemap.xml, ‏גוגל יציג, ‏(א) ‏כמה URLs בסייטמאפ, ‏(ב) ‏כמה מהם indexed. ‏אם המספר השני קטן בהרבה מהראשון, ‏יש לכם בעיה. ‏אם המספר הכללי של indexed (בכל המקורות) גדול בהרבה מהסייטמאפ, ‏גוגל מאנדקסת לכם עמודים שאתם בעצם לא יודעים שקיימים. ‏זה bloat.

🐸 בדיקה עם Screaming Frog, ‏workflow מעמיק

Search Console מספרת לכם מה גוגל רואה. ‏Screaming Frog מספר לכם מה קיים באתר שלכם. ‏ההפרש בין השניים = ‏Index Bloat שגוגל עוד לא תפסה, ‏או עמודים שאתם לא יודעים שיש לכם.

שלב 1, הגדרת הסריקה

פתחו Screaming Frog, ‏הכניסו את כתובת האתר. ‏לפני שתלחצו Start, ‏לכו ל-Configuration > Spider. ‏וודאו ש-"Crawl All Subdomains" כבוי (אלא אם אתם רוצים), ‏וש-"Crawl Outside of Start Folder" כבוי. ‏עכשיו לכו ל-Configuration > User-Agent ובחרו Googlebot Smartphone (כי mobile-first).

שלב 2, הרצת הסריקה

לחצו Start. ‏לאתר בינוני (1,000-10,000 ‏עמודים) ‏זה לוקח 10-30 ‏דקות. ‏לאתר גדול (100,000+) ‏שעות. ‏עדיף לרוץ overnight.

שלב 3, ניתוח התוצאות

אחרי שהסריקה הסתיימה, ‏הסתכלו על Internal > HTML. ‏זה כל ה-HTML pages שגילתה הצפרדע. ‏השוו את המספר ל-"Indexed" ב-Search Console.

• אם Screaming Frog מצא יותר עמודים מ-GSC = ‏יש עמודים שגוגל לא מצא עדיין (חיובי אם הם תוכן, ‏שלילי אם bloat שעתיד להגיע)
• אם GSC מציג יותר מ-Screaming Frog = ‏גוגל מצא עמודים שאתם לא מקשרים אליהם פנימית (orphan pages, ‏לרוב bloat)
• אם המספרים שווים אבל גבוהים מ-sitemap = ‏יש לכם bloat שמקושר פנימית

שלב 4, חיתוך לפי דפוסים

בצפרדע, ‏לכו ל-URL > URL Structure. ‏שם תראו עץ של כל ה-URLs לפי תיקיות. ‏זה ה-bloat finder הטוב ביותר. ‏פתחו /tag/ ותראו 800 ‏עמודי tag. ‏פתחו /?s= ותראו 500 ‏עמודי search. ‏פתחו ?color= ‏ותראו 30,000 ‏עמודי פילטרים.

שלב 5, בדיקת thin content

בצפרדע, ‏Filter > Internal > HTML > Status: 200 OK. ‏הוסיפו עמודה Word Count. ‏סדרו מהנמוך לגבוה. ‏כל עמוד עם פחות מ-200 ‏מילים = ‏מועמד ל-bloat. ‏ראו מדריך thin content להבחנה.

השוואה בין סריקת Screaming Frog ל-Search Console

זאת הטכניקה המתקדמת. ‏הריצו צפרדע ותקבלו רשימה של כל ה-URLs ש-Screaming Frog מצא. ‏ייצאו ל-CSV. ‏ייצאו גם רשימת ה-indexed URLs מ-GSC (Pages > Indexed > Export). ‏פתחו את שניהם ב-spreadsheet ועשו VLOOKUP. ‏(1) ‏URLs ב-GSC שלא ב-Screaming Frog = ‏orphan pages שגוגל מצא לבד, ‏לרוב bloat. ‏(2) ‏URLs ב-Screaming Frog שלא ב-GSC = ‏עמודים שגוגל עוד לא הגיע אליהם. ‏(3) ‏החפיפה = ‏המצב הנוכחי. ‏זה הניתוח הכי מדויק לזיהוי bloat שיש.

🚫 שיטה 1, ‏noindex meta tag (מתי וכיצד)

השיטה הראשונה והנפוצה ביותר לפתרון Index Bloat. ‏פשוטה, ‏אלגנטית, ‏ועובדת ב-95% מהמקרים. ‏אבל יש לה מצבים שמתאימים לה ומצבים שלא.

איך מטמיעים

בעמודים שאתם רוצים להסיר מהאינדקס, ‏הוסיפו ל-head:

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

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

מתי noindex זה הפתרון הנכון

טיפול ב-WordPress עם תוסף SEO

אם אתם משתמשים ב-Yoast או RankMath, ‏אל תיגעו ב-meta tags ידנית. ‏לכו ל-Search Appearance > Taxonomies (או דומה), ‏ולכל סוג של עמוד (tags, ‏categories, ‏authors) ‏יש toggle "Show in search results". ‏שנו ל-No, ‏זה מוסיף noindex אוטומטית לכל העמודים בקטגוריה.

HTTP header alternative

אם העמוד הוא לא HTML (PDF, ‏תמונה, ‏וידאו, ‏JSON), ‏אין לכם head ולא יכולים לשים meta noindex. ‏הפתרון, ‏HTTP header בשם X-Robots-Tag: noindex. ‏ב-htaccess מגדירים את זה לפי סוג קובץ:

<FilesMatch "\.pdf$">
Header set X-Robots-Tag "noindex"
</FilesMatch>

שימושי במיוחד לאתרים עם הרבה PDFs (חוברות, ‏מדריכים) ‏שלא רוצים שיופיעו בתוצאות. ‏אותו עיקרון לתמונות מקוריות שאתם רוצים שיהיו זמינות באתר אבל לא בחיפוש תמונות. ‏Apache עם mod_headers דרוש. ‏ב-Nginx, ‏מגדירים ב-server block.

איך מאיצים את ההסרה

אם הוספתם noindex לעמודים חשובים שצריכים להיעלם מהר, ‏יש לכם 2 ‏טריקים. ‏(1) ‏הוסיפו את ה-URLs ל-sitemap זמני (לא ה-main sitemap). ‏זה גורם לגוגל לסרוק אותם מהר יותר, ‏הוא רואה את ה-noindex ומסיר. ‏(2) ‏השתמשו ב-Removals Tool ב-Search Console להסרה זמנית של 6 ‏חודשים בזמן שה-noindex הקבוע מתחיל לעבוד. ‏השילוב נותן הסרה מיידית בלי לאבד את האפקט הקבוע. ‏לעמודים שלא דחופים, ‏סתם תחכו, ‏גוגל יסרוק בקצב שלו.

🔗 שיטה 2, ‏canonical לעמוד הראשי

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

איך מטמיעים

בכל וריאציה של העמוד, ‏הוסיפו ל-head:

<link rel="canonical" href="https://example.co.il/main-category/" />

גוגל יראה את התג, ‏יבין שעמוד A הוא הראשי, ‏ויאחדה את ה-link equity אליו. ‏הוריאציות יישארו ב-Coverage report כ-"Alternate page with proper canonical tag" (תקין).

מתי canonical עדיף על noindex

• פילטרים שאתם רוצים שגוגל ידע שקיימים אבל לא להציג ב-SERP
• גרסאות AMP/mobile של עמוד
• גרסאות הדפסה
• פרמטרי tracking (utm, ‏fbclid)
• session IDs שלא ניתן להסיר
• תוכן זהה תחת URLs שונים

הזרימה הנכונה לפילטרים בחנות

נניח יש לכם עמוד /shop/shirts/ ופילטרים יוצרים /shop/shirts?color=red&size=M. ‏בעמוד המסונן, ‏ה-canonical צריך להצביע על העמוד הראשי:

<link rel="canonical" href="https://example.co.il/shop/shirts/" />

גוגל מבינה, ‏מאחדת ה-signals, ‏מאנדקסת רק את /shop/shirts/. ‏הפילטרים נשארים זמינים למשתמשים אבל לא מתחרים על מקום ב-SERP.

canonical loop, ‏הסיוט שיש להימנע

אם עמוד A מצביע ב-canonical על עמוד B, ‏ועמוד B מצביע ב-canonical על עמוד A, ‏יצרתם loop. ‏גוגל מתעלם משניהם. ‏זה קורה כשמטמיעים canonical אוטומטית בלי לבדוק. ‏תמיד וודאו ידנית שה-canonical מצביע על העמוד הראשי, ‏ושהעמוד הראשי מצביע על עצמו (self-canonical).

chain של canonicals

בעיה נוספת, ‏עמוד A מצביע ב-canonical על B, ‏ו-B מצביע על C. ‏גוגל לא תמיד עוקבת אחרי שרשרת. ‏לעיתים היא מאנדקסת את B במקום C, ‏או מתעלמת לחלוטין. ‏כלל הברזל, ‏canonical חייב להצביע ישירות על העמוד הסופי הראשי, ‏בלי שלבי ביניים. ‏אם יש לכם chain, ‏תקנו את A להצביע ישירות על C.

הבדיקה הידנית המהירה

בכל אתר שאני מאבדק, ‏אני בודק 10 ‏עמודים אקראיים ב-View Source ומאתר את ה-canonical. ‏צריך להיות, ‏(1) ‏קיים בכל עמוד, ‏(2) ‏בעמוד הראשי מצביע על עצמו (self-canonical), ‏(3) ‏בעמודים משניים מצביע על העמוד הראשי, ‏(4) ‏HTTPS תקין, ‏עם trailing slash אחיד, ‏עם או בלי www באופן עקבי. ‏אם רואים אי-עקביות, ‏זה דגל אדום. ‏גוגל יתבלבל ויבחר את הגרסה הלא נכונה.

📄 שיטה 3, ‏robots.txt חסימה

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

איך מטמיעים

בקובץ robots.txt בשורש האתר (yoursite.co.il/robots.txt), ‏הוסיפו:

User-agent: *
Disallow: /tag/
Disallow: /author/
Disallow: /?s=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*?sort=

כל גוגלבוט יראה את ההוראה, ‏לא יסרוק את הנתיבים האלה.

מתי robots.txt זה הפתרון

• פילטרים שאתם בטוחים שאף פעם לא יהיו רלוונטיים ל-SEO
• נתיבי אדמין (/wp-admin/, /admin/)
• API endpoints (/api/, /wp-json/)
• קבצי שירות (/cgi-bin/, /tmp/)
• חיפושים פנימיים אחרי שגוגל כבר הסירה אותם מהאינדקס

הגוצ'ה הקריטית, ‏ה-order matters

robots.txt מול noindex, ‏ההבדל המהותי

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

לעמודי bloat שלא יהיו רלוונטיים לעולם, ‏הזרימה הנכונה היא, ‏(1) ‏noindex תחילה למשך 4-8 שבועות, ‏(2) ‏אחרי שגוגל הסירה אותם מהאינדקס, ‏מוסיפים robots.txt לחסוך סריקה עתידית. ‏זאת השיטה שאני מיישם ב-90% מהמקרים של ניקוי bloat קיצוני.

טעויות נפוצות עם robots.txt

(1) ‏שכחתם slash בסוף, ‏Disallow: /tag שונה מ-Disallow: /tag/. ‏הראשון חוסם גם /tagteam/ ו-/tagged-posts/. ‏(2) ‏Case sensitivity, ‏Disallow: /Tag/ לא יחסום /tag/. ‏(3) ‏טעות סדר, ‏אם יש לכם Allow ו-Disallow סותרים, ‏גוגל מעדיף את ה-Allow. ‏תמיד בדקו עם robots.txt Tester ב-Search Console לפני deployment.

איך לראות מה גוגל באמת חוסם

ב-Search Console > Settings > Crawl Stats > Host status, ‏יש דוח של איך גוגל רואה את robots.txt שלכם, ‏כולל matches על URLs ספציפיים. ‏שימושי מאוד לאחר עדכון לוודא שאתם חוסמים את מה שאתם מתכוונים, ‏וכלום מעבר לכך.

🛠 שיטה 4, ‏URL Parameters tool (deprecated), ‏מה במקום

פעם הייתה ב-Search Console כלי בשם "URL Parameters" שאיפשר להגיד לגוגל "תתעלם מהפרמטר color, ‏הוא לא משנה את התוכן". ‏כלי שימושי שעזר באלפי מקרים. ‏הוא הוסר במרץ 2024. ‏אז מה עושים עכשיו?

למה הוא הוסר

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

מה לעשות במקום

1. canonical חזק לעמוד הראשי

   הפתרון הכי טוב. ‏לכל וריאציה של פרמטרים, ‏ה-canonical מצביע על העמוד הראשי בלי פרמטרים. ‏גוגל מאחד signals. ‏ראו מדריך טיפול נכון בפרמטרים.

2. robots.txt לפרמטרי מעקב

   פרמטרים כמו utm_source, ‏fbclid, ‏gclid לא משנים את התוכן ולא צריך אותם באינדקס. ‏חסמו ב-robots.txt: Disallow: /*?utm_, Disallow: /*?fbclid=.

3. noindex על וריאציות פילטרים

   בעמודים עם פילטרים פעילים, ‏הוסיפו noindex דינמית כש-URL מכיל פרמטרי פילטר. ‏ב-PHP: if (!empty($_GET['color'])) echo '<meta name="robots" content="noindex">';.

4. URL clean architecture

   הפתרון העמוק. ‏עברו ל-clean URLs במקום פרמטרים. ‏/shirts/red/medium/ במקום /shirts?color=red&size=M. ‏פותר את הבעיה משורש.

טיפול ספציפי לפלטפורמות

מה גוגל מצהירה היום על פרמטרים

גוגל פרסמה הצהרה שאם יש לכם פרמטרים שלא משנים את התוכן, ‏הם יזהו אוטומטית. ‏זה נכון חלקית. ‏באתרים פשוטים (4-5 ‏פרמטרים, ‏מבנה צפוי), ‏זה אכן עובד. ‏באתרים מורכבים (Magento, ‏אתרי אנטרפרייז) ‏עם 20+ ‏פרמטרים שונים, ‏מקוננים, ‏עם משמעויות שונות לפי הקשר, ‏גוגל מתבלבל. ‏צריך עזרה ידנית. ‏הכלל שלי, ‏אם site: מציג יותר מ-1,000 ‏URLs עם פרמטרים, ‏גוגל לא הולך לפתור את זה לבד.

הזרמת UTMs שלא בהכרח גורמת bloat

UTMs קלאסיים (utm_source, ‏utm_medium, ‏utm_campaign) ‏נחשבים ל-tracking parameters שגוגל בדרך כלל מסתכלת עליהם וטוענת שהם זהים לעמוד הראשי. ‏אבל זה לא תמיד עובד. ‏הפתרון הבטוח, ‏canonical חזק בכל עמוד שמצביע על הגרסה ללא פרמטרים. ‏ובנוסף, ‏Disallow: /*?utm_ ב-robots.txt לחסוך crawl budget.

🏗 שיטה 5, ‏structural restructure

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

מתי restructure הוא הפתרון

• אתר עם מאות עמודי קטגוריה ריקים כי הקטגוריזציה נעשתה לפני 10 ‏שנים
• חנות עם מבנה פילטרים מבולגן שאי אפשר לתקן עם canonical
• בלוג עם 50 ‏עמודי tag כפולים שכותבים לא ידעו שכבר קיים tag דומה
• אתר WordPress שעבר כמה rebrand ויש 200 ‏עמודי author למשתמשים שכבר לא קיימים
• אתר מסחר עם הרבה מוצרים שכבר לא במלאי אבל עמודיהם פעילים

5 שלבי ה-restructure

1. אינוונטר מלא, ‏הריצו Screaming Frog על כל האתר, ‏ייצאו רשימה מלאה של כל ה-URLs. ‏לכל אחד, ‏בדקו, ‏האם הוא מקבל תנועה? ‏האם יש לו backlinks חיצוניים? ‏האם הוא רלוונטי לעסק היום?
2. החלטה לכל עמוד, ‏שלוש אפשרויות, ‏(א) ‏השאיר ושפר, ‏(ב) ‏אחד עם עמוד אחר (301), ‏(ג) ‏מחק (410)
3. תכנון 301s, ‏לפני שמוחקים, ‏וודאו שיש redirect לעמוד דומה. ‏לעמודים בלי דומה, ‏301 לעמוד קטגוריה. ‏לעמודים לחלוטין מיותרים, ‏410 Gone.
4. ביצוע בגלים, ‏לא להרוס הכל ביום אחד. ‏עבדו בגלים של 100-200 ‏עמודים, ‏עקבו אחרי השפעה ב-Search Console, ‏המשיכו.
5. עדכון internal links + sitemap, ‏אחרי כל גל, ‏נקו internal links שמובילים לעמודים שנמחקו, ‏עדכנו את ה-sitemap. ‏אל תסמכו רק על ה-301.

מה לעשות עם תוכן ישן שאי אפשר למחוק

לפעמים יש לכם 5,000 פוסטים ישנים שמקבלים 0 ‏תנועה אבל יש להם backlinks. ‏אי אפשר למחוק (תאבדו authority), ‏אבל הם פוגעים באתר. ‏הפתרון:

איך להחליט בין מחיקה למיזוג

השאלה הפשוטה, ‏האם יש לעמוד backlinks חיצוניים? ‏אם כן, ‏מיזוג (consolidation) ו-301 חובה. ‏אם לא, ‏בדקו את התנועה האורגנית ב-12 ‏החודשים האחרונים. ‏אם 0, ‏מועמד למחיקה (410). ‏אם תנועה מינימלית אבל קבועה, ‏בדקו אם יש עמוד דומה לאחד איתו. ‏אם אין, ‏ובכלל הוא לא משרת מטרה עסקית, ‏מחיקה. ‏אם הוא כן משרת מטרה, ‏שיפור משמעותי או noindex לפי מקרה.

💰 הקשר בין bloat ל-crawl budget

אחד הנזקים החמורים ביותר של Index Bloat הוא בזבוז crawl budget. ‏גוגל מקצה לכל אתר כמות סופית של עמודים לסרוק בכל יום. ‏אם 80% מהתקציב הזה הולך על bloat, ‏רק 20% נשאר לעמודים שחשובים לכם. ‏זה משפיע על כל מה שעובד באתר.

איך גוגל מחליטה על crawl budget

הקצאת crawl budget מבוססת על 2 ‏גורמים, ‏(1) ‏crawl rate limit, ‏כמה מהר השרת שלכם יכול להגיב בלי לקרוס, ‏(2) ‏crawl demand, ‏כמה גוגל רוצה לסרוק את האתר שלכם בהתבסס על הפופולריות, ‏העדכניות, ‏וה-authority. ‏שני אלה ביחד נותנים את ה-budget היומי.

איך bloat פוגע ב-crawl budget

1. גוגל סורק bloat לפני תוכן חדש

   אם יש לכם 50,000 ‏עמודי bloat ו-200 ‏עמודי תוכן, ‏גוגל יחלק את התקציב היחסי. ‏פוסט חדש שאתם רוצים שיופיע מהר באינדקס, ‏יחכה שבועות.

2. שינויים בעמודים קיימים לא מתעדכנים

   עדכון תוכן, ‏שינוי כותרת, ‏שינוי description, ‏כל אחד מאלה דורש סריקה חדשה. ‏אם crawl budget מנוצל ל-bloat, ‏העדכון שלכם יישב באוויר חודשים.

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

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

איך לבדוק את crawl budget שלכם

ב-Search Console, ‏לכו ל-Settings > Crawl Stats. ‏שם תראו, ‏(1) ‏Total crawl requests בכל יום, ‏(2) ‏Average response time, ‏(3) ‏פילוח לפי file type, ‏purpose (discovery vs refresh), ‏ו-response code. ‏פעולה מומלצת:

• בדקו את הגרף של Total crawl requests. ‏ירידה הדרגתית = ‏בעיית שרת או bloat קיצוני
• בדקו את ה-pie chart של Purpose. ‏אם יותר מ-50% "Discovery" באתר ותיק, ‏זה bloat (גוגל מגלה כל הזמן עמודים חדשים)
• בדקו את Response Codes. ‏אחוז גבוה של 3xx (redirects) = ‏אובדן crawl budget על redirect chains
• השוו את Total Requests למספר העמודים שאתם רוצים שגוגל תסרוק. ‏אם פי 10, ‏יש bloat

מתי crawl budget נהיה הדאגה המרכזית

לאתרים קטנים (פחות מ-10,000 ‏עמודים), ‏crawl budget בדרך כלל לא בעיה. ‏גוגל יכולה לסרוק את כל האתר תוך ימים. ‏הסיפור משתנה דרסטית באתרים בינוניים-גדולים. ‏אתר עם 100,000 ‏עמודים אמיתיים + 500,000 ‏עמודי bloat = ‏גוגל יבחר לסרוק רק את החלק הקטן בכל יום. ‏עדכון תוכן בעמוד חשוב יכול לקחת חודשים להתעדכן. ‏זה הקשר הישיר בין bloat ל-מהירות אינדוקס של העדכונים שלכם. ‏ככל שהאתר גדול יותר, ‏ככה הבעיה חריפה יותר.

⚖️ Helpful Content System ו-bloat רחב-אתר

הנזק החמור ביותר של Index Bloat לא מתבטא בעמודים הספציפיים של ה-bloat, ‏אלא ב-quality assessment רחב-אתר של גוגל. ‏מאז ה-Helpful Content Update של ספטמבר 2023, ‏זה לא רק "חלק מהאלגוריתם". ‏זה מערכת אקטיבית שיכולה להוריד אתר שלם בעמוד אחד באלפי מקומות. אם יש לכם bloat קיצוני, ‏אתם מועמדים.

איך ה-Helpful Content System מסתכלת על האתר שלכם

HCS לא בודק עמודים בודדים. ‏היא בודקת את האתר כיחידה. ‏השאלות שהיא שואלת:

• אחוז עמודים שנותנים ערך אמיתי
• אחוז עמודים דקים (פחות מ-300 ‏מילים)
• אחוז עמודים אוטומטיים או מ-AI
• אחוז עמודים שמועתקים או דומים מאוד זה לזה
• אחוז עמודים שלא מקבלים תנועה כלל

אתר עם bloat קיצוני נכשל בכל אחד מהמדדים. ‏עמודי tag עם 1-2 ‏פוסטים = ‏דקים. ‏עמודי פילטרים = ‏דומים זה לזה. ‏רוב עמודי הארכיון = ‏לא מקבלים תנועה. ‏HCS רואה אתר "שמייצר הרבה תוכן בלי לתת ערך" ופוגע באתר כולו.

הנזק האמיתי, ‏גם בעמודים הטובים

קלאסיק, ‏לקוח עם בלוג של 200 ‏פוסטים איכותיים + 800 ‏עמודי bloat (tags, ‏archives, ‏author). ‏פתאום בעדכון HCS, ‏מאמרים שדורגו #2-3 ‏ירדו ל-#15-25. ‏לא בגלל שמשהו השתנה במאמרים עצמם, ‏אלא כי כל האתר סווג כ-"low quality site". ‏הפתרון, ‏ניקוי ה-bloat, ‏העלאת יחס "תוכן עוזר" ל-"תוכן לא עוזר".

איך לתקן site-wide HCS penalty

1. אינוונטר מלא

   צפרדע על האתר, ‏רשמו כל עמוד, ‏עם word count, ‏impressions, ‏clicks מ-GSC, ‏backlinks מ-Ahrefs.

2. סיווג

   עמודים שמקבלים תנועה ויש להם backlinks = ‏שמירה ושיפור. ‏עמודים בלי תנועה ובלי backlinks = ‏מועמדים ל-noindex/מחיקה. ‏שטח אפור = ‏שיפור או מיזוג עם עמודים דומים.

3. ביצוע בגלים

   לא להרוס את הכל ביום אחד. ‏גלים של 50-100 ‏עמודים בכל פעם. ‏מעקב אחרי השפעה ב-GSC.

4. סבלנות

   HCS לא מתקנת את עצמה תוך שבוע. ‏זה לוקח 2-3 ‏חודשים אחרי שמסיימים את הניקוי. ‏עדכוני HCS קורים כל 6-8 ‏שבועות. ‏לאחר אחד מהם, ‏אתם מתחילים לראות שינוי.

מה לא לעשות בזמן HCS recovery

שלוש טעויות נפוצות. ‏(1) ‏פאניקה ופרסום עוד תוכן כדי לפצות, ‏זה רק מחמיר את היחס "תוכן עוזר" ל-"תוכן לא עוזר". ‏(2) ‏מחיקה גורפת בלי הבחנה, ‏אובדן authority של עמודים עם backlinks. ‏(3) ‏שינויים גדולים במבנה האתר בזמן הריקאברי, ‏מסבך את האבחנה של גוגל. ‏שמרו על יציבות, ‏נקו בהדרגה, ‏חכו לעדכון HCS הבא של גוגל. ‏הסבלנות היא המפתח.

📅 צ'ק ליסט חודשי + workflow audit ב-10 שלבים

פתרון Index Bloat זה רק חצי מהעבודה. ‏החצי השני זה לוודא שהוא לא חוזר. ‏הנה צ'ק ליסט חודשי שאני עובד לפיו ב-90% מהאתרים שאני מנהל, ‏ועקבותיו של תהליך audit מלא ב-10 ‏שלבים שעובד בכל סוג של אתר.

צ'ק ליסט חודשי

• הריצו site:yoursite.co.il ב-גוגל. ‏רשמו את המספר. ‏השוו לחודש שעבר. ‏עלייה גדולה = ‏bloat חדש שצריך לבדוק
• פתחו Search Console > Pages. ‏ספרו עמודים ב-"Crawled, currently not indexed". ‏עלייה משמעותית = ‏גוגל מתחיל לסנן עוד עמודים. ‏מועד לאודיט
• בדקו "Indexed, not submitted in sitemap". ‏עמודים חדשים שם = ‏bloat שגוגל מצא לבד
• בדקו crawl stats. ‏ירידה ב-total requests = ‏בעיית שרת. ‏עלייה רבה ב-discovery = ‏bloat חדש
• הריצו צפרדע מהירה (rapid, ‏100 ‏עמודים בלבד) ‏על הקטגוריות הקריטיות, ‏tags, ‏authors, ‏פילטרים
• בדקו עמודי tag חדשים שנוצרו החודש. ‏אם דקים (1-2 ‏פוסטים), ‏noindex מיד
• בדקו עמודי search results שנוצרו (?s=). ‏אם רואים שגוגל סרק, ‏הוסיפו robots.txt
• וודאו canonical תקין על העמודים הראשיים. ‏בדקו 5-10 ‏עמודים אקראיים
• בדקו אם נוספו פרמטרים חדשים (tracking, ‏campaigns). ‏צריך לחסום או לטפל ב-canonical
• תיעוד, ‏רשמו ב-spreadsheet כל ה-changes החודש. ‏עוזר לזהות טרנדים

10 השלבים של אודיט מלא, ‏בקצרה

זה ה-process המעשי שלי. ‏(1) ‏Initial scope, ‏site: ב-גוגל מול sitemap מול GSC. ‏(2) ‏Search Console deep dive, ‏ייצוא של הקטגוריות הבעייתיות. ‏(3) ‏Screaming Frog full crawl. ‏(4) ‏Pattern identification, ‏זיהוי 5 ‏מקורות bloat גדולים. ‏(5) ‏Traffic analysis לכל דפוס. ‏(6) ‏Backlink analysis. ‏(7) ‏Decision tree, ‏noindex/canonical/robots.txt/restructure. ‏(8) ‏Phased execution בגלים של 100-500. ‏(9) ‏Cleanup orphans + sitemap. ‏(10) ‏Long-term monitoring 6 ‏חודשים.

מתי bloat איננו בעיה

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

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