ניתוח log files: איך לראות מה גוגל באמת עושה באתר שלכם (ולא מה שהוא מספר לכם)

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

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

מה בעצם יש בתוך log file

כל שורה בלוג היא בקשה אחת לשרת, וכל שורה מכילה בערך את השדות האלה:

• IP address, כתובת המקור של הבקשה. חשוב במיוחד לאימות בוטים.
• timestamp, מתי בדיוק הבקשה הגיעה.
• ה-URL המבוקש, איזה עמוד או קובץ ביקשו.
• method, בדרך כלל GET או POST.
• status code, מה השרת ענה: 200, 301, 404, 500 וכן הלאה.
• user agent, מי שלח את הבקשה, דפדפן או בוט.

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

שלב ראשון: להשיג את הקבצים ולנקות אותם

קודם כל צריך לחלץ את הלוגים, וזה תלוי איפה האתר יושב:

• שרת עצמאי עם Apache או NGINX: הקבצים יושבים בדרך כלל ב-var log apache2 access.log או ב-var log nginx access.log.
• אחסון WordPress משותף: לרוב דרך cPanel או SFTP, ולפעמים צריך לבקש מהתמיכה כי השמירה מוגבלת.
• מי שעובד מאחורי CDN כמו Cloudflare: מגדירים Logpush אל דלי אחסון בענן.

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

• מבודדים את הבוטים של מנועי החיפוש לפי ה-user agent שלהם.
• מסירים בקשות לקבצים סטטיים ובקשות כפולות.
• מנרמלים את הפורמט של התאריכים והכתובות כדי שאפשר יהיה לסנן ולפלח.

נקודה חשובה, אל תסמכו על ה-user agent לבד. כל אחד יכול להתחזות ל-Googlebot. תעשו אימות הפוך של ה-IP מול הטווחים הרשמיים שגוגל מפרסמת. אחרת אתם מנתחים תנועה של scrapers ומדמיינים שזה גוגל.

מבחינת כלים, אין צורך להפחיד את עצמכם. לאתר קטן, Excel או Google Sheets עם קצת סבלנות יעשו את העבודה. לאתרים גדולים יש כלים ייעודיים כמו ה-Log File Analyzer של Semrush או Screaming Frog, וכשמגיעים לנפחים אמיתיים, Python עם pandas או פתרון מבוסס ענן נותנים לכם גמישות אינסופית. הכלי פחות חשוב מהשיטה. אני מכיר אנשי SEO שעשו תובנות שוות זהב עם טבלה פשוטה, ואחרים שקנו מנוי יקר ולא הסתכלו בו אף פעם.

ארבע השאלות שהלוגים עונים עליהן

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

• יעילות crawl budget: אילו עמודים בעלי ערך נמוך מקבלים תשומת לב מוגזמת מהבוט? אם גוגל מבזבז מאה זחילות ביום על פילטרים של faceted navigation ועל pagination אינסופי, זה זמן שהוא לא מקדיש לעמודים שחשובים לכם.
• עומק זחילה וגילוי: האם העמודים החשובים באמת נזחלים? כאן מגלים עמודים יתומים שאין אליהם קישורים, ואזורים שלמים באתר שהבוט כמעט לא נוגע בהם.
• שגיאות status: כמה 404 יש, האם יש שרשראות redirect, האם יש 500 שצצים. בלוגים רואים את זה בזמן אמת, לא שבועיים אחרי שזה כבר פגע בכם.
• אימות בוטים: לוודא שהתנועה שאתם מייחסים לגוגל היא באמת גוגל, ולא מתחזה.

הבעיות שכמעט תמיד צצות

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

• מלכודות זחילה: לוחות שנה אינסופיים, פרמטרים שמייצרים אינסוף כתובות, לולאות redirect ששורפות תקציב.
• שרשראות redirect: שלושה וארבעה קפיצות במקום אחת, מה שמאט את הזחילה.
• עמודים שנזחלים אבל לא נכנסים לאינדקס, סימן לבעיית איכות או כפילות.
• פרמטרים שנזחלים יתר על המידה, במיוחד בחנויות ecommerce עם פילטרים.

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

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

העידן החדש: בוטים של AI בלוגים שלכם

וכאן מגיע החלק שהפך את ניתוח הלוגים לרלוונטי מתמיד. היום הלוגים שלכם מלאים לא רק ב-Googlebot וב-Bingbot, אלא גם ב-GPTBot, ClaudeBot ודומיהם. אלה בוטים שאוספים תוכן עבור מנועי ה-AI, והם צורכים משאבים אמיתיים מהשרת שלכם.

• פלחו את הלוגים לפי הבוטים האלה בנפרד. תגלו איזה סוגי תוכן מושכים אותם באופן לא פרופורציונלי.
• החליטו במודע: להרשות, להגביל קצב, או לחסום דרך robots.txt. Cloudflare אפילו מציעה מנגנון Pay Per Crawl שמאפשר לגבות תשלום או לחסום בוטים של AI.
• עקבו אחרי השינויים לאורך זמן. קפיצה או צניחה חדה בהתנהגות בוט היא לרוב הסימן המוקדם ביותר לבעיה טכנית עמוקה יותר.

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