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

איך משתמשים בצ׳קליסט הזה

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

כלי העבודה המרכזיים הם בחינם: Google Search Console, בדיקת מהירות כמו PageSpeed Insights, ודפדפן רגיל עם כלי המפתחים. אם עדיין לא חיברתם את האתר ל-Search Console, התחילו ממדריך ההגדרה שלנו לGoogle Search Console למתחילים, כי רוב הבדיקות כאן נשענות עליו.

שלב 1: סריקה ואינדוקס

קובץ robots.txt

הקובץ נמצא בכתובת האתר-שלכם/robots.txt ומגדיר לאילו כתובות הסורקים רשאים לגשת. בדקו שלא נשארה בו הוראת Disallow כללית משלב הפיתוח, ושלא נחסמו תיקיות של קבצי CSS ו-JavaScript שהדפים צריכים כדי להיראות נכון.

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

תג noindex בדפים חשובים

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

מפת אתר (Sitemap)

• המפה צריכה לכלול רק כתובות קנוניות שאתם רוצים לראות בתוצאות, כולל כתובת מלאה עם https.
• אל תכניסו אליה דפים מנותבים, דפי שגיאה או דפי noindex.
• קובץ אחד מוגבל ל-50,000 כתובות או ל-50MB לא דחוס. אתר גדול יותר מפצלים לכמה קבצים.
• שלחו אותה ב-Search Console וציינו אותה גם בקובץ robots.txt.

דוח האינדוקס

ב-Search Console פתחו את דוח "ההוספה של דפים לאינדקס" (Page indexing) ובדקו כמה מהדפים החשובים באמת מאונדקסים, ומה הסיבות לשאר: "נסרק – לא נכלל באינדקס כרגע", "עותק כפול בלי שנבחר דף קנוני על ידי המשתמש", "הדף לא נמצא (404)" ועוד. רוב הבעיות הטכניות מתגלות כאן.

בדיקת כתובת בודדת

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

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

שלב 2: מבנה כתובות, קנוניות והפניות

• גרסה אחת של האתר: http מול https, עם www ובלי www. כולן צריכות להפנות (301) לגרסה אחת. אם עדיין לא עברתם, קראו על המעבר מ-http ל-https.
• תג canonical: לכל דף כדאי תג קנוני שמצביע על עצמו, בכתובת מוחלטת. גוגל מגדירה אותו כסימן חזק, אבל לא מחייב, ולכן הוא עובד הכי טוב כשכל שאר האותות (קישורים פנימיים, מפת אתר) תואמים אותו.
• שרשראות הפניות: כתובת א׳ שמפנה ל-ב׳ שמפנה ל-ג׳ מבזבזת זמן סריקה וטעינה. תקנו כך שא׳ מפנה ישר ל-ג׳.
• פרמטרים וכתובות כפולות: סינון, מיון ומעקב קמפיינים יכולים ליצור עשרות גרסאות של אותו דף. ודאו שהן מצביעות לקנוני.

שלב 3: קודי שגיאה ודפי 404

סרקו את האתר עם כלי סריקה (Screaming Frog בגרסה החינמית מספיק לאתר קטן) ורשמו כל כתובת שמחזירה 404 או 5xx. דף שנמחק ויש לו תחליף ראוי להפנות בהפניית 301 לדף הרלוונטי. אם אין תחליף, מותר להשאיר 404 אמיתי. מה שלא כדאי הוא להפנות הכול לעמוד הבית. כך נראה עמוד שגיאה 404 שעובד כמו שצריך: הודעה ברורה, חיפוש וקישורים לדפים עיקריים.

שלב 4: מהירות וחוויית דף (Core Web Vitals)

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

מדד	מה הוא מודד	סף "טוב"
LCP	זמן עד שהאלמנט הגדול בדף מוצג	עד 2.5 שניות
INP	תגובה ללחיצות והקלדות	עד 200 מילישניות
CLS	קפיצות של תוכן בזמן הטעינה	עד 0.1

הנתונים האמיתיים נמצאים בדוח Core Web Vitals ב-Search Console (נתוני משתמשים), ואילו PageSpeed Insights נותן גם בדיקת מעבדה עם הצעות לתיקון. את הנתונים האמיתיים כדאי להעדיף כשיש כאלה.

התיקונים השכיחים

• תמונות ענקיות: לדחוס, להמיר לפורמט מודרני כמו WebP ולהגדיר רוחב וגובה כדי שהדף לא יקפוץ (משפר CLS).
• תמונת הפתיחה בדף לא נטענת בהשהיה (lazy loading); השהיה מתאימה לתמונות שמתחת לקפל.
• יותר מדי תוספים וסקריפטים של צד שלישי: ללכת עליהם אחד אחד ולהסיר מה שלא משמש.
• שרת איטי: לפעמים הבעיה היא החבילה ולא האתר, ואז שווה לבדוק אחסון אתרים ומנגנון מטמון.

שלב 5: מובייל ואבטחה

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

בנוסף, ודאו שאין תוכן מעורב (דף https שטוען תמונה או סקריפט דרך http) ושתעודת האבטחה לא עומדת לפוג.

שלב 6: מבנה פנימי ונתונים מובנים

• עומק הקליקים: דפים חשובים צריכים להיות במרחק של כמה קליקים בודדים מעמוד הבית.
• דפים יתומים: דף שאף דף אחר לא מקשר אליו יתקשה להיסרק. קישורים פנימיים טובים פותרים את זה.
• כותרות וכותרות משנה: כותרת H1 אחת לכל דף, וכותרות title ו-description ייחודיות.
• נתונים מובנים (Schema): אם הוספתם, בדקו אותם בכלי בדיקת תוצאות עשירות של גוגל ואת השגיאות בדוחות השיפורים ב-Search Console.

דוגמה: איך נראית בדיקה בפועל

נניח אתר של עסק שירותים עם 120 כתובות במפת האתר. ב-Search Console מתברר ש-70 מהן מאונדקסות, ו-50 מסומנות "נסרק – לא נכלל באינדקס כרגע" או "עותק כפול בלי שנבחר דף קנוני על ידי המשתמש". (המספרים כאן להמחשה בלבד.) בבדיקה מגלים ש-30 מהכתובות הן גרסאות עם פרמטרים, ו-20 הן דפי תגיות דקים. התיקון: קנוניות לכתובות הנקיות, הוצאת דפי התגיות ממפת האתר, ובדיקה חוזרת אחרי כמה שבועות. כך הבעיה נפתרת בלי לכתוב אפילו מילה חדשה.

איך מתעדפים את התיקונים

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

טעויות נפוצות

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

כל כמה זמן בודקים

בדיקה מלאה אחת לרבעון מתאימה לרוב האתרים הקטנים, ובדיקה קצרה של Search Console (אינדוקס, שגיאות סריקה, Core Web Vitals) פעם בחודש. אם אתם בונים תוכנית קידום מאפס, שלבו את הבדיקה הזאת בתחילת הדרך, כמו בתוכנית קידום אורגני לעסק חדש.

שאלות נפוצות

מה זה SEO טכני?

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

האם robots.txt מוציא דף מגוגל?

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

מהם ערכי Core Web Vitals הטובים?

לפי Google: LCP עד 2.5 שניות, INP עד 200 מילישניות ו-CLS עד 0.1, כשההערכה נעשית לפי האחוזון ה-75 של הטעינות.

כמה כתובות אפשר לשים בקובץ sitemap אחד?

עד 50,000 כתובות או 50MB לא דחוס. מעבר לכך מפצלים לכמה קבצים ומחברים אותם בקובץ אינדקס.

כל כמה זמן כדאי לבדוק SEO טכני?

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

מקורות

• Google Search Console Help: דוח ההוספה של דפים לאינדקס
• Google Search Central: חסימת אינדוקס באמצעות noindex
• Google Search Central: מבוא ל-robots.txt
• Google Search Central: בניית מפת אתר
• Google Search Central: איחוד כתובות כפולות וקנוניזציה
• web.dev: Core Web Vitals
• Google Search Console Help: כלי בדיקת כתובות (URL Inspection)