בדיקת אתר (ביקורת אתר, Site Audit) היא סקירה שיטתית של אתר קיים כדי למצוא מה מעכב אותו: בעיות טכניות, איטיות, עמודים שגוגל לא סורקת, תוכן חסר או כפול, חוויית משתמש מבלבלת ובעיות נגישות. בדיקה טובה לא מסתיימת ברשימה של מאות "שגיאות" מכלי אוטומטי, אלא ברשימה קצרה של בעיות שבאמת משנות — מסודרת לפי השפעה וקושי תיקון. במאמר הזה: מה בודקים, באילו כלים, ואיך מתעדפים.
ארבעה תחומים בכל בדיקת אתר
| תחום | מה בודקים | כלים |
|---|---|---|
| טכני | סריקה ואינדוקס, שגיאות, הפניות, מפת אתר, HTTPS, נתונים מובנים | Search Console, סורק אתרים, בדיקת robots.txt |
| ביצועים | זמני טעינה, Core Web Vitals, משקל העמוד, סקריפטים חיצוניים | PageSpeed Insights, נתוני שדה מ-Search Console |
| תוכן ומבנה | עמודים חסרים, עמודים כפולים, עמודים בלי קישורים פנימיים, כותרות ותיאורים | סורק אתרים, Search Console, קריאה ידנית |
| חוויית משתמש ונגישות | ניווט, טפסים, נייד, ניגודיות, מקלדת, טקסט חלופי | בדיקה ידנית, כלי נגישות אוטומטיים |
בדיקה טכנית
השאלה הראשונה: האם גוגל יכולה לסרוק ולאנדקס את העמודים החשובים? בודקים בדוח הדפים של Search Console אילו עמודים לא נכנסו לאינדקס ולמה, מוודאים שקובץ robots.txt לא חוסם עמודים חשובים, שאין תגיות noindex במקומות הלא נכונים, ושתגית הקנוניקל מצביעה על הכתובת הנכונה. אחר כך: שרשראות הפניות, שגיאות 404 על עמודים שיש אליהם קישורים, ומפת אתר שמכילה רק עמודים אמיתיים. פירוט בכל נושא: Google Search Console, robots.txt, תגית קנוניקל ותוכן כפול.
ביצועים
לא מסתפקים בציון אחד. נתוני שדה — מה שגולשים אמיתיים חווים — חשובים יותר מבדיקת מעבדה בודדת. בודקים את התבניות המרכזיות (דף בית, עמוד שירות, מאמר, מוצר), כי בעיה בתבנית חוזרת בכל העמודים מאותו סוג. איך קוראים את הנתונים: בדיקת מהירות אתר וCore Web Vitals.
תוכן ומבנה
כאן הכלים האוטומטיים עוזרים רק חלקית. סורק יגיד שיש שני עמודים עם אותה כותרת; הוא לא יגיד ששירות מרכזי של העסק בכלל לא מופיע באתר, או שעמוד השירות לא עונה על השאלות שלקוחות שואלים בטלפון. בודקים את מבנה האתר מול מה שהעסק מוכר ומה שאנשים מחפשים, עמודים יתומים בלי קישורים פנימיים (ראו עמודים יתומים), ועמודים דלים שכדאי לאחד.
חוויית משתמש ונגישות
עוברים על האתר כמו לקוח: מהנייד, עם מטרה — למצוא שירות, להבין מחיר או תהליך, ליצור קשר. כמה צעדים זה לוקח? איפה נתקעים? בנגישות, W3C מציע בדיקות ראשוניות פשוטות — כותרת העמוד, טקסט חלופי לתמונות, כותרות, ניגודיות, הגדלת טקסט, מקלדת ומיקוד נראה, תוויות בטפסים — אבל מדגיש שהן מכסות רק חלק מהבעיות, ושעמוד יכול לעבור אותן ועדיין להיות לא נגיש. בדיקה מלאה מתבססת על התקן — ראו חוק נגישות אתרים.
איך מתעדפים
הפלט של בדיקה צריך להיות רשימת פעולות, לא דוח. לכל ממצא שואלים שתי שאלות: כמה הוא משפיע על לקוחות, תנועה או חוקיות, וכמה עבודה התיקון דורש. קודם מטפלים בבעיות שחוסמות — עמודים חשובים מחוץ לאינדקס, טופס שלא עובד, אתר שלא נפתח בנייד — אחר כך בתיקונים קלים עם השפעה גבוהה, ורק בסוף בשיפורים קוסמטיים. רוב "השגיאות" שכלים אוטומטיים מדווחים עליהן הן רעש, ואסור לתת להן להסתיר את המעט שחשוב.
כל כמה זמן לבדוק
בדיקה מקיפה כדאי לעשות לפני עיצוב מחדש או העברה, אחרי שינוי משמעותי בתבנית, וכשמשהו משתנה בלי הסבר — ירידה בתנועה או בפניות. בין לבין, מעקב שוטף אחרי דוחות Search Console ואחרי זמינות האתר תופס את רוב הבעיות מוקדם.
שאלות נפוצות
מספיק להריץ כלי בדיקה אוטומטי?
כלי אוטומטי הוא נקודת התחלה טובה לבעיות טכניות, אבל הוא לא מבין את העסק, את התוכן או את הלקוחות. החלק החשוב של הבדיקה הוא הפרשנות והתעדוף.
מה ההבדל בין בדיקת אתר לבדיקת קידום?
בדיקת אתר מסתכלת על האתר כולו — טכניקה, ביצועים, תוכן, חוויית משתמש ונגישות. היבטי החיפוש הם חלק ממנה, לא כל התמונה.
אני מבצע בדיקות אתרים טכניות ומוסר רשימת תיקונים מתועדפת. אפשר לקרוא עוד בעמוד תשתית טכנית מוכנה למנועי חיפוש, או לשלוח לי את כתובת האתר.
אהבתם את המאמר?
