אודיט SEO הוא החלטה מה לתקן באתר קודם, עם הוכחה ליד כל המלצה ועם דרך לבדוק אחרי היישום. רשימת שגיאות מכלי היא רק חומר גלם לאודיט. אודיט טכני הוא החלק שבודק אם הרובוטים של מנועי החיפוש ושל עוזרי ה-AI יכולים להוריד ולקרוא את האתר, ואם מנוע החיפוש יכול לשמור אותו באינדקס.
אני עושה אודיט בשמונה שלבים:
- אני קובע את המטרה ואת מצב האתר לפני שאני מפעיל קראולר, כלומר תוכנה שעוברת על האתר כמו רובוט של מנוע חיפוש.
- אני בודק אם הרובוטים בכלל מקבלים את האתר.
- אני אוסף נתונים מכמה מקורות ובודק מה כל אחד מהם לא רואה.
- אני בודק מילות מפתח ותוצאות גוגל לפני שאני עוסק בצד הטכני.
- אני עובר על האתר לפי קטלוג בעיות עם תנאי עדיפות.
- ליד כל נושא אני מציג הוכחה.
- אני קובע סדר, היקף עבודה וחלופות.
- אני מעביר את התוצאה לבקרה צולבת, ואחרי היישום בודק כל נושא.
המספרים בטקסט הזה מגיעים מארכיון אודיטים שהכנתי מאז 2020 בעצמי או עם צוות. בארכיון יש 77 מסמכי אודיט משנים 2020-2026. מהם 63 כוללים לפחות ממצא אחד, בסך הכול 938 ממצאים ב-50 אתרים (כל דומיין נספר בנפרד). מהממצאים האלה בניתי באוקטובר 2026 קטלוג של 256 סוגי בעיות. “בעיה ב-24 מתוך 63 אודיטים” אומר שכותב האודיט החליט שכדאי לדווח עליה, ולא ש-38% מהאתרים בפולין סובלים ממנה. זו תדירות הדיווח באודיטים האלה, ולא מדידה של כמה פעמים הבעיה מופיעה באתרים.
תוכן העניינים
מהו אודיט SEO ובמה אודיט טכני שונה ממנו?
אודיט SEO אומר באיזה מצב האתר ומה מגביל את הנראות שלו, ואודיט טכני בודק אם מנוע החיפוש יכול להוריד את האתר, לרנדר אותו ולשמור אותו באינדקס. באודיט מלא אני בודק את הצד הטכני, ארכיטקטורה ותוכן בדפים, מילות מפתח, קישורים חיצוניים ומתחרים, ובסוף קובע את סדר הפעולות. אודיט טכני מספיק כשהשאלה טכנית: ירידה אחרי יישום, מיגרציה, דפים שנושרים מהאינדקס.
| סוג האודיט | על איזו שאלה הוא עונה | מאיפה אני לוקח נתונים |
|---|---|---|
| טכני | האם הרובוטים מורידים, מרנדרים ומאנדקסים את הכתובות הנכונות | סריקה עם הרצת JavaScript ובלעדיה, Search Console, נתוני Chrome ממשתמשים (CrUX), לוגים של השרת |
| ארכיטקטורה ותוכן | האם לכל מילת מפתח חשובה יש דף והאם הקישור הפנימי תומך בו | מילות מפתח, תוצאות גוגל, מפת קישורים פנימיים |
| קישורים חיצוניים | האם פרופיל הקישורים עוזר והאם הוא מסכן | Ahrefs, Search Console |
| גישה ל-AI | האם הרובוטים של עוזרי AI מקבלים את האתר ומה הם רואים בו | בדיקת רובוטים, robots.txt, HTML לפני הרצת JavaScript |
אודיט הוא הקלט של האסטרטגיה ולא האסטרטגיה עצמה. האסטרטגיה אומרת על איזה ביקוש נלחמים ועל מה מוותרים, והאודיט אומר מה היום עומד בדרך. בטקסט על אסטרטגיית SEO תיארתי איך האחד עובר לשני.
איך עושים אודיט SEO שלב אחר שלב?
לסדר השלבים יש משמעות, כי השלבים המוקדמים קובעים אם המספרים בשלבים המאוחרים אמינים. בשני מקומות אני עוצר את התהליך להחלטה: אחרי השלב הראשון אני קובע היקף, ואחרי הבקרה הצולבת, לפני השליחה ללקוח, אני בודק סדרי עדיפויות וטענות.
שלב 1. מטרה ומצב האתר, לפני שאני מפעיל קראולר
השאלה הראשונה היא אם האתר מאבד תנועה או שהוא לא בונה אותה, כי בתשובה תלוי כל האודיט. אתר בלי נראות צריך קודם מפה של מילות מפתח ודפים שאמורים לענות עליהן. אתר שיש לו נראות צריך קודם הגנה על מה שכבר תופס מיקומים, ורק אחר כך שיפור.
לפני שמתחילים אני שואל על דברים שאף כלי לא יראה. אילו מוצרים או שירותים מכניסים כסף, אם מתוכנן שינוי של מערכת ניהול התוכן או בנייה מחדש, מי יישם את ההמלצות וכמה זמן יש לו. מהתשובות נגזרים היקף האודיט ורשימת הדברים שאני לא מפרט, כי אף אחד לא יישם אותם.
את השלב הזה צריך לעבור לבד, אף שמומחים רבים מעבירים אותו היום למודל שפה. מודל שפה יכול לעזור, אבל הוא לא יבין את העסק של הלקוח. הוא גם לא יביא את המבט היצירתי והייחודי של מומחה SEO מנוסה.
שלב 2. האם הרובוטים בכלל מקבלים את האתר
לפני שאני קורא מספר כלשהו מכלי, אני בודק אם השרת נותן לרובוטים להיכנס, כי רובוט חסום מחזיר נתונים שנראים כמו בעיות SEO. בשבוע אחד של יולי 2026 שלוש “בעיות SEO” בשלושה אתרים שונים התבררו כחסימת רובוטים:
- אתר “איבד” יותר מ-2,200 קישורים, כי הדפים שמהם הם הובילו עמדו מאחורי חומת אש שדחתה את הרובוט של כלי ניתוח הקישורים.
- לחנות היה בכלי ציון בריאות אתר 0 עם כמעט 42,000 שגיאות, כי במקום דפים הרובוט של הכלי קיבל תגובות של חומת האש Cloudflare.
- באתר השלישי חסימה עצרה את הקראולר בכתובת הראשונה, ושלושה שבועות אף אחד לא שם לב.
את אותה כתובת אני מוריד כדפדפן רגיל וכרובוטים של Google, Bing, OpenAI, Perplexity ו-Anthropic, ואחר כך משווה קודי תגובה וגודל דף. ההבדל בין דפדפן לרובוט הוא הדבר הראשון שאני מברר לפני שאני סופר משהו. בדיקה כזו שולחת בקשות מכתובת ה-IP שלי בשם הרובוט, וחומות אש מזהות רובוטים אמיתיים של Google ו-Bing לפי הכתובת שממנה הם מגיעים. חסימת “Googlebot” בבדיקה אינה מוכיחה אפוא חסימה של Googlebot האמיתי. Search Console, הלוח החינמי של גוגל לבעלי אתרים, מראה איך Googlebot האמיתי רואה את האתר.
את קובץ robots.txt אני קורא עד הסוף בעזרת פרסר, כלומר תוכנה שמיישמת את הכללים כמו רובוט, ולא בעין. הרובוט של גוגל מיישם רק קבוצת כללים אחת, זו עם שם הרובוט המתאים ביותר, ומתעלם משאר הקבוצות. כלל Disallow: בלי נתיב לא חוסם דבר (Google Search Central). באוגוסט 2026 מקטע של robots.txt של אחד האתרים נראה כאילו הוא חוסם את גוגל. הפרסר הראה ש-Googlebot קיבל גישה מלאה, וחסומים היו הרובוטים של Bing ושל עוזרי AI. האבחנה הייתה אפוא שונה: הבעיה נגעה ל-Bing ולרובוטי AI ולא לגוגל.
היעדר קובץ robots.txt לא חוסם את גוגל, אבל אחרי כל יישום אני בודק שהקובץ לא נעלם. גוגל מתייחסת לשגיאת 4xx על robots.txt (חוץ מ-429) כאילו אין קובץ, כלומר בלי מגבלות (Google Search Central). האתר שלי החזיר באוגוסט 2026 שגיאת 404 על robots.txt, עד שתיקנתי את זה.
שלב 3. נתונים מכמה מקורות ומה שכל אחד מהם לא רואה
כל מספר מקראולר הוא השערה, עד שמקור שני מאשר אותו. אני אוסף סריקה עם הרצת JavaScript ובלעדיה, ונתוני מהירות ממשתמשים אמיתיים מדוח CrUX. לזה אני מוסיף פרופיל קישורים ותוצאות גוגל למילות מפתח חשובות מיום המדידה. בטקסט על בניית קישורים תיארתי איך אני בודק את פרופיל הקישורים לפני תוכנית קמפיין. ליד כל קובץ אני רושם מקור, תאריך והיקף, כדי שאפשר יהיה לשחזר כל מספר גם אחרי חודש.
נתונים מ-Search Console אני מושך דרך ה-API, כלומר ממשק למשיכת נתונים אוטומטית, כי הייצוא מהלוח קוצץ את הרשימה ל-1,000 שורות. ה-API מחזיר עד 50,000 שורות ביום לכל סוג תוצאות, למשל בנפרד לתוצאות של דפים, תמונות ווידאו (Google, Search Console Help). בטקסט על כלי AI ב-SEO הראיתי איך ייצוא קטוע ניפח את ה-CTR באתר אחד.
קראולר יכול להמעיט בגודל האתר, ולכן מספרי דפים ומוצרים אני בודק במקור שני. בשתי חנויות הקראולר הגיע לעמוד הראשון של רשימת המוצרים בקטגוריה ולא המשיך, אף שהעמודים הבאים ברשימה עבדו ולא היו חסומים. בחנות אחת הוא מצא פחות ממחצית המוצרים, בשנייה פחות משליש. אילו הייתי מציג את המספרים האלה כמצב החנויות, האודיט היה מתאר חסרים במבחר שלא היו קיימים.
שינויים פתאומיים בנתונים יומיים אני מתאר לפני שאני מייחס להם סיבה. אני עושה זאת להקלקות, לחשיפות, למיקומים, לביקורים ולבקשות של הרובוט של גוגל. אני מחפש ימים שמהם חציון של שבעה ימים רצופים שונה בלפחות 25% מחציון של ארבעה עשר הימים שלפניהם. ליד כל תאריך כזה אני רושם הסבר: יישום, עדכון של גוגל, תקלה, שינוי במדידה או “סיבה לא ידועה”. תיאור התאריכים נותן השערות, ואת הסיבה אני מציין רק אחרי שבדקתי הסברים אפשריים אחרים.
שלב 4. מילות מפתח ותוצאות גוגל לפני הצד הטכני
קודם אני מחפש הזדמנויות, ואחר כך מתקן שגיאות. חלק מהבעיות הטכניות אפשר להעריך רק על רקע מילות המפתח: האם פילטר בחנות צריך להיות באינדקס, האם תגית ראויה לדף נפרד, האם שני דפים באמת מתחרים על אותו דבר. בקטלוג 32 סוגי בעיות מסומנים כך שבלי ניתוח מילות מפתח ותוצאות גוגל אי אפשר להעריך אותם.
היעדר דף למילת מפתח חשובה הוא אחת הבעיות הנפוצות יותר באודיטים שלי: 15 מתוך 63 אודיטים, ב-14 מתוך 50 אתרים. קראולר לא ידווח על כך, כי הוא מוריד רק דפים שקיימים. רואים את זה רק כשמשווים ביקוש לרשימת כתובות ולדפי המתחרים שמופיעים בתוצאות.
שלב 5. סקירה לפי קטלוג עם תנאי עדיפות
אותה שגיאה יכולה להיות בעדיפות גבוהה או נמוכה, תלוי איפה היא מופיעה. קישור פנימי לכתובת עם הפניה בתבנית שחוזרת באלפי דפים הוא בעדיפות גבוהה. אותו קישור בתוכן של פוסט אחד הוא בעדיפות בינונית, ובפוסטים בארכיון בעדיפות נמוכה.
לכל סוג בעיה בקטלוג יש כלל זיהוי, תנאי דיווח, הוכחה נדרשת, עדיפות עם תנאים ודרך בדיקה אחרי היישום. מ-256 הסוגים ב-86 כלל העדיפות מתחיל ב“גבוהה”, אבל כמעט תמיד עם תנאי: כשלמילת המפתח יש ביקוש, כשלדף יש תנועה, כשהשגיאה בתבנית.
לכן ציון בריאות האתר מכלי לא קובע עדיפויות. הכלי סופר שגיאות, ולא את התנועה שתלויה בהן. המלצה על דפים שהתנועה אליהם לא ידועה לא מקבלת עדיפות גבוהה לפני שבדקתי את הנתונים.
שלב 6. הוכחה ליד כל נושא
נושא בלי הוכחה נשאר באודיט כ“לבדיקה” ולא כהמלצה. הוכחה היא צילום מסך של המקום בקוד או HTML מהשרת לצד הגרסה אחרי הרצת JavaScript. היא יכולה להיות גם גרף מ-Search Console או מדידת מהירות עם שם האלמנט שפוגע בה. לאלמנט שמאט את הטעינה או מזיז את פריסת הדף אני קורא בשם שמצביעה עליו המדידה, ולא בשם שמתאים להשערה שלי.
כל נושא אני מתאר בארבעה חלקים, מהבעיה ועד בדיקת התיקון. אני כותב במה הבעיה, למה היא מזיקה ועל מה היא משפיעה, איך מתקנים אותה צעד אחר צעד ואיך נבדוק שהתיקון עבד. קוד לתיקון אני מעתיק מהאתר מילה במילה, כדי שהמתכנת יראה בדיוק את המקום שעליו לשנות.
כך נראה בקצרה דיווח אחד על קישורים להפניות:
- הבעיה: הקישורים בתפריט מובילים לכתובות בלי לוכסן בסוף, שמופנות לגרסה עם לוכסן.
- למה זה מזיק: התפריט בכל דף, ולכן כל הקלקה וכל הורדה על ידי רובוט עוברות הפניה נוספת. בדוחות של כלים אלפי קישורים כאלה מקשים למצוא שגיאות חשובות יותר.
- תיקון: בתבנית התפריט להחליף את הכתובות בכתובות היעד, עם קטע קוד לפני השינוי ואחריו.
- בדיקה: אחרי היישום הסריקה לא מראה בתבנית קישורים לכתובות עם הפניה.
שלב 7. סדר, היקף עבודה וחלופות
תוצאת האודיט היא סדר, ולא מספר הממצאים. בתחילת המסמך עומדת טבלה של כל הנושאים עם עדיפות והיקף עבודה. את ההיקף אני מתאר בארבע קטגוריות: כמה שעות, יום או יומיים, שבוע או פרויקט שלם. צוות עם יכולות קטנות יותר מקבל חלופה מינימלית לצד המלאה, עם תיאור ברור של מה הוא מפסיד כשהוא בוחר בדרך הקצרה.
היישום נעשה בדיוק לפי האודיט. אם בהצעת מחיר ליישום מופיעה חלופה זולה יותר, הלקוח בוחר בה ואני רושם זאת במפורש, ולא מחליף המלצה בלי ידיעתו.
שלב 8. בקרה צולבת ובדיקה אחרי היישום
לפני שהאודיט מגיע ללקוח, בודק אותו מי שלא כתב אותו. אני עושה שני סבבי בקרה: הראשון על המסמך כולו, השני רק על מה ששונה אחרי הראשון. הבקרה מחשבת מחדש את המספרים מאפס ומחפשת טענות שאי אפשר להגן עליהן בהוכחה. בסוף אני בודק בעצמי את העדיפויות ואת הטענות שתלויות במצב הלקוח.
אחרי היישום אני בודק כל נושא באתר שעובד ומסמן אותו כמיושם נכון, חלקית או שלא יושם. הבדיקה הזו כלולה במחיר האודיט. בלי השלב הזה האודיט נגמר במסמך ולא בשינוי באתר.
מה אני בודק באודיט טכני?
באודיט טכני אני עובר על כמה תחומים, והבעיות שאני מדווח עליהן הכי הרבה הן בהפניות, בארכיטקטורת האתר ובתוכן. העמודה האחרונה מראה בכמה מ-63 האודיטים בארכיון המחבר דיווח על לפחות בעיה אחת בתחום. העמודה “מה אני בודק” נותנת דוגמאות, ולא את ההיקף המלא של התחום. הטבלה מציגה תחומים נבחרים, והקטלוג מחלק את הבעיות ל-22.
| תחום | מה אני בודק | אודיטים עם בעיה (מתוך 63) |
|---|---|---|
| הפניות וקודי תגובה | שרשראות הפניות, קישורים לכתובות 3xx ו-404, הפניות לדף הבית | 50 |
| ארכיטקטורה וקישור פנימי | דפי יעד למילות מפתח, קישורים מהבלוג לדפים מרכזיים, עומק בהקלקות | 49 |
| תוכן בדפים | קניבליזציה, דפים עם תוכן דל וכפילויות | 47 |
| כותרות, תיאורים וכותרות משנה | כותרות דפים, תיאורים וכותרות H1 בתבניות | 44 |
| Robots.txt ומפת אתר | חסימות, כתובות שאינן 200 במפה, תאריך שינוי אחרון | 41 |
| נתונים מובנים | תיאור מלא של החברה והכותבים, מוצר והצעה בחנויות | 39 |
| אינדוקס | דפים חשובים מחוץ לאינדקס ודפים שלא אמורים להיות בו | 34 |
| כתובות קנוניות וכפילויות | כתובת קנונית (canonical), כלומר הגרסה המסומנת של דף, פרמטרים, וריאציות של כתובות | 28 |
| תמונות | משקל קבצים, פורמטים, תמונות חסומות לאינדוקס | 27 |
| פילטרים ופרמטרים | פילטרים באינדקס ובטווח הרובוט | 25 |
| עימוד | קישורים לדפים הבאים ברשימות, דפי עימוד ריקים עם קוד 200 | 19 |
| מהירות ו-Core Web Vitals | LCP, INP ו-CLS, כלומר זמן טעינה, זמן תגובה ויציבות הפריסה, מנתוני משתמשים | 16 |
| גרסאות שפה | תגי hreflang הדדיים בין גרסאות שפה, גרסת ברירת מחדל | 14 |
| רינדור JavaScript | תוכן וקישורים ב-HTML מהשרת ואחרי הרצת JavaScript | 12 |
| AI ונראות בצ'אטים | גישת רובוטי AI, חומת אש, מטרת נראות בצ'אטים | 4 |
בעיה שמדווחים עליה לעיתים רחוקות לא חייבת להופיע לעיתים רחוקות. למהירות ול-JavaScript יש בטבלה מעט דיווחים, אבל לאודיטים מהארכיון היה היקף שונה. מספר דיווחים נמוך לא אומר אפוא כמה פעמים הבעיות האלה מופיעות באתרים.
איך אני בודק אינדוקס של אתר?
אינדוקס אני בודק על שלוש רשימות: מה במפת האתר, מה גוגל שמרה באינדקס ומה הקראולר מוצא דרך קישורים. פער בין שלוש הרשימות מראה בעיה טוב יותר מכל אחת מהן לבדה. מפת אתר עם כתובות שמחזירות הפניה, שגיאה או מוחרגות מהאינדקס דווחה ב-20 מתוך 63 אודיטים, ב-18 מתוך 50 אתרים. לכתובות בודדות אני משתמש בבדיקת כתובת ב-Search Console, שמראה גם את הדף אחרי הרצת JavaScript.
האם Core Web Vitals משפיעים על המיקומים?
Core Web Vitals הם חלק ממערכות הדירוג של גוגל, אבל הם לא מנצחים את הרלוונטיות של התוכן. גוגל כותבת במפורש שמערכות הדירוג משתמשות ב-Core Web Vitals. היא כותבת גם שהיא תמיד מנסה להציג את התוכן הרלוונטי ביותר, גם כשהחוויה בדף חלשה (Google Search Central). באודיט אני משתמש בנתונים ממשתמשים אמיתיים מדוח CrUX, ולא בבדיקה אחת בכלי מעבדה. איפה שלגוגל יש נתונים כאלה לסוגי דפים בודדים, אני מציג אותם בנפרד. היעדר הנתונים האלה אני מתאר באודיט. מ-12 במרץ 2024 המדד לתגובת הדף הוא INP, שהחליף את FID (web.dev).
אילו טעויות אני מוצא הכי הרבה באודיטים של SEO?
הכי הרבה חוזרות שגיאות תחזוקה שוטפת, כלומר כאלה שכלים מזהים בקלות: קישורים להפניות ולשגיאות 404, מפות אתר עם כתובות לא נכונות וכותרות ותיאורים כפולים. קישורים פנימיים לכתובות עם הפניה הופיעו ב-24 מתוך 63 אודיטים, ב-20 מתוך 50 אתרים. הכלים מזהים אותם היטב, ועלות התיקון תלויה בתבנית ובמערכת האתר.
בעיות מבנה שמדווחים עליהן לעיתים רחוקות יותר יכולות להשפיע על התנועה יותר משגיאות תחזוקה שוטפת. היעדר דפים למילות מפתח חשובות דווח ב-15 מתוך 63 אודיטים, ובדיוק אותו מספר פעמים בלוג שלא מקשר לדפי השירותים והקטגוריות. הקטלוג נותן לדף חסר עדיפות גבוהה כשלמילת המפתח יש ביקוש והמתחרים תופסים מיקומים בדפים נפרדים. בלוג בלי קישורים מקבל עדיפות גבוהה כשלדפי היעד יש תנועה או הכנסה ולבלוג יש סמכות. את התנאים האלה אני בודק בנתונים לפני שאני קובע עדיפות.
- 938ממצאים ב-63 אודיטים ב-50 אתרים, שמהם בניתי קטלוג של 256 סוגי בעיותארכיון אודיטים 2020-2026, קטלוג מ-11.10.2026
- 38%מהאודיטים עם קישורים פנימיים לכתובות עם הפניה, הבעיה שמדווחים עליה הכי הרבה בארכיון (24 מתוך 63)קטלוג מ-11.10.2026
- 15 מתוך 63אודיטים עם היעדר דפים למילות מפתח חשובות, מה שקראולר לא ידווח עליוקטלוג מ-11.10.2026
- 14סוגי המלצות שהקטלוג מסמן היום כמיושנות, ועוד 30 כשינוי בפרקטיקהקטלוג מ-11.10.2026
מה השתנה באודיטים של SEO מאז 2020?
באודיטים משנים 2023-2026 נתונים מובנים ועימוד מופיעים יותר מאשר בשנים 2020-2022, והפניות, כתובות קנוניות ואינדוקס פחות. בעיות בנתונים מובנים דווחו ב-23 מתוך 33 אודיטים חדשים יותר לעומת 16 מתוך 30 ישנים יותר. הפניות וקודי תגובה: 23 מתוך 33 לעומת 27 מתוך 30. חסימות של רובוטי AI מופיעות רק באודיטים משנת 2026. שנת האודיט היא תאריך הקובץ בארכיון, ולכן לא תמיד שנת ביצוע העבודה.
הירידה לא מוכיחה שבעיות ההפניות נעלמו. הרכב האודיטים השתנה: החדשים יותר עסקו יותר בנתונים מובנים, בתוכן ובנראות ב-AI, וגם שיטת העבודה השתנתה. מהגרף הזה אפשר ללמוד במה עסקו האודיטים, ולא איך השתנו אתרים בפולין.
אילו המלצות SEO כבר לא עדכניות?
חלק מההמלצות עדיין מופיעות באודיטים ובמדריכים, אף שהיום לא כדאי ליישם אותן. חלקן עבדו לפני כמה שנים, וחלקן גוגל מזהירה מפניהן או מתעלמת מהן כבר מזמן. בטבלה אני נותן ליד כל פרקטיקה את הסיבה ואת מה לעשות במקומה.
| פרקטיקה לא עדכנית | למה היום לא | מה לעשות במקומה |
|---|---|---|
| Canonical מכל דפי העימוד לדף הראשון | גוגל מזהירה מפני זה מאז 2013 וממליצה שלכל דף עימוד יהיה canonical משלו | לכל דף עימוד canonical משלו והוא ניתן לאינדוקס |
| תגי FAQPage ו-HowTo לתוצאות מורחבות | מ-8 באוגוסט 2023 גוגל מציגה תוצאות FAQ רק לאתרי ממשלה ובריאות מוכרים, ומ-13 בספטמבר 2023 לא מציגה תוצאות HowTo | מקטע שאלות בתוכן, כשתוצאות גוגל מציגות שאלות של משתמשים |
| nofollow פנימי כדי להפנות כוח קישורים לדפים חשובים | מאז 2009 הכוח שמיועד לקישור עם nofollow לא עובר לשאר הקישורים בדף | הסרת קישורים מיותרים מהתבנית |
| הפניה לדף הבית כשאין מקבילה | גוגל מתייחסת להפניות המוניות לדף הבית כ-soft 404, כלומר כהיעדר דף | המקבילה הנושאית הקרובה ביותר או קוד 410 |
| Crawl-delay ב-robots.txt | גוגל מעולם לא תמכה בהנחיה הזו | קצב הורדה שמוגדר בשרת או ב-CDN |
| שדות changefreq ו-priority במפת אתר | גוגל לא משתמשת בהם, כפי שאישרה ב-2023 | תאריך שינוי אחרון נכון ורק כתובות קנוניות עם קוד 200 |
| FID כקריטריון מהירות | מ-12 במרץ 2024 INP החליף אותו | INP מנתוני משתמשים |
| WebSite עם SearchAction לתיבת חיפוש בתוצאות | גוגל כיבתה את התיבה הזו מ-21 בנובמבר 2024 | סימון WebSite רק לשם האתר |
מקורות לטבלה: Google על עימוד, Google על חמש טעויות עם rel=canonical, Google על תוצאות FAQ ו-HowTo, Matt Cutts על nofollow ועל חלוקת כוח קישורים, John Mueller על הפניות לדף הבית, דרך Search Engine Roundtable, Google על robots.txt, Google על כללים לא נתמכים ב-robots.txt, Google על מפות אתר, Google על השדות lastmod, changefreq ו-priority, web.dev על INP, Google על תיבת חיפוש בתוצאות.
לכן לכל המלצה בקטלוג שלי יש שדה עדכניות עם נימוק. הקטלוג מסמן היום 14 סוגי המלצות כמיושנות ו-30 כשינוי בפרקטיקה. המלצה שהייתה נכונה לפני כמה שנים לא תיכנס לאודיט רק משום שפעם עבדה.
איך בודקים גישה של רובוטי AI באודיט?
גישה של רובוטי AI אני בודק באותו שלב שבו אני בודק גישה של Googlebot, כי אותה הגדרה של חומת אש או CDN יכולה לחסום אותם. CDN היא רשת שרתים מתווכת, למשל Cloudflare. בספטמבר 2026 בדקתי 12 דומיינים של לקוחות שלי שעובדים מאחורי Cloudflare. robots.txt לבדו הראה:
- 3 דומיינים חסמו אותה קבוצה של שבעה רובוטים שאוספים נתונים לאימון מודלים, עם רשימת שמות זהה. רשימה זהה מרמזת על מקור משותף, למשל הגדרה מוכנה בלוח של Cloudflare. מבחוץ אי אפשר לראות את ההגדרה הזו, ולכן צריך לאשר אותה בלוח עצמו.
- 1 מהדומיינים חסם רובוטים שמורידים דפים לתשובות של ChatGPT, של Perplexity ושל Claude. הוא לא עשה זאת במפורש, אלא בכלל כללי לכל הרובוטים שלא הוזכרו בשמם. אותו דומיין הציג ל-GPTBot דף אבטחה בלי תג noindex, שמוציא דף מהאינדקס. אילו קיבל דף כזה רובוט שעושה אינדוקס, לאינדקס היה יכול להגיע דף החסימה במקום התוכן.
- ל-8 דומיינים לא היו חסימות ב-robots.txt.
על רובוטים שמורידים דפים לתשובות ועל רובוטים שאוספים נתונים לאימון אתם מחליטים בנפרד. בטקסט על קידום ב-AI תיארתי איך להבדיל ביניהם. מ-31 באוגוסט 2026 יש גם הגדרה נפרדת ב-Search Console שמוציאה אתר מ-AI Overview, ממצב AI ומתכונות גנרטיביות ב-Discover. לפי גוגל היא לא משפיעה על שאר תוצאות החיפוש (Search Console Help). הגדרה כזו אני בודק באודיט כמו robots.txt, כי מישהו יכול היה להפעיל אותה בלי ידיעת האחראי על ה-SEO. אם אחרי פתיחת הגישה המותג מופיע בתשובות, זו כבר מדידה נפרדת שתיארתי בטקסט על נראות מותג ב-AI.
בדיקה מכתובת IP אחת מראה רק חלק מהמצב, ויכולה בעצמה לתת התראת שווא. באותה סקירה סדרת בקשות דיווחה על חסימה בשני דומיינים אחרי חריגה ממגבלה. את החסימה הזו הפעילו הבקשות הקודמות שלי עצמן. בדיקה כמה דקות אחר כך, עם מזהה רובוט אחד ובקשות בודדות, נתנה חמש ושבע תשובות תקינות ברצף. לולא הבדיקה הזו, שני לקוחות היו מקבלים מידע על חסימה שלא הייתה. רק לוגים של השרת מראים אם ChatGPT באמת מוריד את האתר. בטקסט על קובץ llms.txt אני מראה מה רואים בלוגים של האתר שלי.
קוד 200 לא אומר שהרובוט קיבל תוכן. אצל לקוח אחד עם אפליקציית JavaScript, Googlebot ו-Bingbot קיבלו HTML מוכן משירות prerender, ורובוטי עוזרי AI קיבלו דף ריק. השירות זיהה רובוטים לפי שם ולא היו ברשימה שלו רובוטי AI. הבדיקה שלי נתנה “תקין”, כי מדדה קוד תגובה ולא תוכן. מאז אני משווה את התוכן שמקבל הרובוט לתוכן אחרי הרצת JavaScript בדפדפן.
האם אודיט SEO חינמי מספיק?
כלי חינמי יציג רשימת שגיאות, אבל מהדוח עצמו לא יוצא אילו מהן עולות לכם בתנועה. על “audyt seo” (בפולנית: אודיט SEO) 7 מתוך 9 התוצאות האורגניות בעמוד הראשון של גוגל הן כלים או הצעות לאודיט חינמי (תוצאות מ-17 באוקטובר 2026). דוח כזה סופר שגיאות לפי כללי הכלי, ולא לפי כמה תנועה והכנסה תלויות בהן. צריך גם לבדוק שהתוצאה לא באה מחסימת רובוט, כמו במקרה של החנות עם ציון בריאות 0.
הרבה אפשר לעשות בחינם, אם יודעים איפה להסתכל. Search Console מראה נתוני גוגל על אינדוקס, על Core Web Vitals ועל הדף אחרי הרצת JavaScript. הגרסה החינמית של Screaming Frog עוברת עד 500 כתובות בסריקה אחת (Screaming Frog), וזה מספיק לאתר עסקי קטן. אודיט עם יועץ הגיוני כשטעות עולה הרבה (מיגרציה, ירידה בתנועה, חנות גדולה) או כשאין לכם זמן להרכיב את הנתונים ולהעריך אותם.
האם ChatGPT יעשה אודיט SEO?
ChatGPT ושום מודל AI אחר לא יעשו אודיט מלא לבד, כי הם לא רואים את האתר כמו רובוט של מנוע חיפוש. בדרך כלל הם רואים אותו דרך כלי שמוריד אותו והופך לטקסט. המודל יקרא נתונים שתתנו לו ויציע מה לבדוק. אבל כלי ההורדה יכול לאבד חלק מהדף: בספטמבר 2026 בדקתי שהכלי להורדת דפים ב-Claude Code מוחק נתונים מובנים כשהוא הופך דף לטקסט. המודל ענה שאין מידע, אף שהוא היה בתגית באותו דף. אודיט שנעשה כך היה מדווח על היעדר נתונים מובנים שלא חסרים. בתהליך שלי AI הוא כלי, בעיקר לצבירת נתונים מסריקה, מ-Search Console ומעוד מקורות. את ההיקף, ההערכה והעדיפויות אני קובע בעצמי.
כמה עולה אודיט SEO?
אני מחייב על אודיט כמו על ייעוץ: 70 אירו נטו לשעת עבודה, עם תקרת שעות שנקבעת לפני ההתחלה. מספר השעות תלוי במה שצריך לבדוק:
- אודיט אבחון, כלומר בעיה אחת או שתיים מוגדרות (ירידה, מיגרציה, אינדוקס), הוא בדרך כלל 10-16 שעות, כלומר 700-1,120 אירו נטו;
- אודיט מלא עם סדר פעולות הוא בדרך כלל 32-50 שעות, כלומר 2,240-3,500 אירו נטו;
- אתר קטן עד 500 כתובות קרוב לגבול התחתון, וחנות עם אלפי כתובות ופילטרים קרובה לעליון;
- גרסאות שפה מוסיפות בדרך כלל 3-5 שעות, ומשבר מתמשך שצריך לאבחן 4-8 שעות.
במחיר כלולים ניתוח, דוח עם המלצות, פגישה שבה אנחנו עוברים עליו ובדיקה אחרי היישום. את היישום עצמו עושה הצוות שלכם, או שאני מתמחר אותו בנפרד.
בלי גישה ל-Search Console, ללוח ה-CDN ולאחסון את החלק הטכני לא אוכל לבדוק במלואו, ואני אומר זאת לפני התמחור. אז אני מציין מה לא אוכל לוודא בלי הגישות האלה ומצמצם בהתאם את ההיקף. בטקסט על ייעוץ SEO תיארתי מתי במקום אודיט מספיקה שיחה על החלטה אחת.
שאלות נפוצות על אודיט SEO
כמה זמן לוקח אודיט SEO?
אודיט אבחון של בעיה אחת או שתיים הוא בדרך כלל 10-16 שעות עבודה, ואודיט מלא 32-50 שעות. המועד ביומן תלוי בעיקר בכמה מהר אקבל גישות ל-Search Console, לאנליטיקס ולאחסון. הוא תלוי גם בגודל האתר, כי סריקה עם הרצת JavaScript ובלעדיה אני מפעיל בזו אחר זו.
איך עושים אודיט לאתר בעצמכם?
התחילו מ-robots.txt ובדקו שהקובץ קיים ושהוא לא חוסם שום דבר חשוב. אחר כך ב-Search Console פתחו את דוח האינדוקס של הדפים ובחרו את התצוגה של דפים שנשלחו במפת האתר. ראו אילו כתובות לא באינדקס ומאילו סיבות. בסוף העבירו את האתר בגרסה החינמית של Screaming Frog וחפשו קישורים להפניות ולשגיאות 404 וכן כותרות ותיאורים כפולים של דפים. אלה הבעיות הנפוצות ביותר באודיטים שלי, ואפשר לזהות אותן בלי כלים בתשלום.
באיזו תדירות כדאי לעשות אודיט SEO?
אודיט מלא אני עושה לפני שינוי גדול (מיגרציה, מערכת חדשה, בנייה מחדש) ובודק את האתר אחרי היישום. בין האודיטים מספיקה מדידה קבועה: התראות ב-Search Console וסריקה עם אותה תצורה כמו קודם, כדי להשוות תוצאות ולא להתחיל מאפס.
מה צריך להיות בדוח אודיט SEO?
הדוח צריך להתחיל בטבלה של כל הנושאים עם עדיפות והיקף עבודה. ליד כל נושא צריך תיאור של הבעיה, ההשפעה שלה, פתרון צעד אחר צעד, הוכחה (צילום מסך, קוד, גרף) ודרך בדיקה אחרי היישום. דוח בלי סדר פעולות ובלי הוכחות הוא רשימת שגיאות ולא אודיט.
האם אודיט SEO ישפר את המיקומים בגוגל?
אודיט עצמו לא משנה דבר באתר, התוצאה באה רק מהיישום. לכן אחרי היישום אני בודק את השינויים באתר שעובד, ואת התוצאה אני מודד על מילות המפתח והדפים שהשינויים נגעו בהם, ולא על התנועה הכללית.
האם אודיט SEO כולל נראות ב-AI?
הוא כולל גישה של רובוטי עוזרי AI לאתר: robots.txt, חומת אש, CDN ומה שהרובוט מקבל ב-HTML. את הנראות של המותג בתשובות AI אני מודד בנפרד, על סט שאלות של הלקוחות, כי זו מדידה אחרת מאודיט של האתר.
מאיפה מתחילים?
התחילו משאלה אחת: האם האתר מאבד תנועה או שהוא לא בונה אותה. בתשובה תלוי אם קודם מגנים על דפים שיש להם מיקומים או מחפשים מילות מפתח שחסרים להן דפים. אחר כך עשו שלוש בדיקות חינמיות מהתשובה על אודיט עצמי: robots.txt, דוח האינדוקס ב-Search Console וסריקה בגרסה החינמית של Screaming Frog. אם התוצאה תפתיע אתכם או שאתם לא יודעים מה לתקן קודם, זה נושא טוב לייעוץ.
מקורות חיצוניים (נבדקו ב-18 באוקטובר 2026):
- Google Search Central: How Google interprets the robots.txt specification (developers.google.com)
- Google Search Central: Build and submit a sitemap (developers.google.com)
- Google Search Central Blog: A note on unsupported rules in robots.txt (developers.google.com)
- Google Search Central Blog: Sitemaps ping endpoint is going away (developers.google.com)
- Google Search Central: Pagination, incremental page loading, and their impact on Google Search (developers.google.com)
- Google Search Central Blog: 5 common mistakes with rel=canonical (developers.google.com)
- Google Search Central: Understanding page experience in Google Search results (developers.google.com)
- Google Search Central Blog: Changes to HowTo and FAQ rich results (developers.google.com)
- Google Search Central Blog: Farewell, sitelinks search box (developers.google.com)
- web.dev: Interaction to Next Paint becomes a Core Web Vital on March 12 (web.dev)
- Search Console API: Getting all your data (developers.google.com)
- Search Console Help: Export data directly from a Search Console report (support.google.com)
- Search Console Help: Search generative AI control (support.google.com)
- Search Engine Roundtable: Google, 301 redirects to the home page are soft 404s (seroundtable.com)
- Matt Cutts: PageRank sculpting (mattcutts.com)
- Screaming Frog: SEO Spider (screamingfrog.co.uk)
נתונים עצמיים: ארכיון של 77 אודיטים משנים 2020-2026 וקטלוג של 256 סוגי בעיות (11 באוקטובר 2026), סקירת גישת רובוטים ב-12 דומיינים (12 בספטמבר 2026), תוצאות גוגל וביקוש מ-DataForSEO (17 באוקטובר 2026).