SEO טכני מאפשר למנועי חיפוש לגלות, לאחזר ולהבין את העמודים שתרצו שאנשים ימצאו. התחילו בכתובות נגישות, בקודי תגובה נכונים ובאותות אינדוקס עקביים, ואז חברו את העמודים באמצעות ניווט שימושי. עמוד מהיר עם כתובת קנונית שגויה או noindex שנוסף בטעות עדיין סובל מבעיית נראות בסיסית.
המדריך מציע בסיס למפתחים ולבעלי אתרים, ולא הבטחת דירוגים. נראות בחיפוש תלויה גם בתוכן וברלוונטיות. המטרה כאן מצומצמת וניתנת לבדיקה: העמוד הרצוי צריך להחזיר את התוכן הרצוי עם אותות שתואמים לגבי זהותו ומטרתו.
הפרידו בין גילוי, סריקה, אינדוקס ודירוג
גילוי מתרחש כאשר מנוע חיפוש לומד שכתובת קיימת, למשל דרך קישור או מפת אתר. סריקה היא אחזור הכתובת. רינדור עשוי להריץ JavaScript וליצור תוכן להמשך העיבוד. אינדוקס כולל ניתוח של התוכן והחלטה כיצד לייצג אותו באינדקס. דירוג הוא הבחירה והסידור המאוחרים של תוצאות עבור שאילתה.
אלה שלבים נפרדים. כתובת במפת אתר לא בהכרח תיסרק מיד, ועמוד שנסרק בהצלחה אינו מובטח להיכלל באינדקס. גם עמוד שנוסף לאינדקס לא בהכרח יופיע לביטוי שבחרתם. זהו היכן נעצרות הראיות לפני שינוי הגדרות לא קשורות.
התחילו מקבוצת תבניות מייצגת: דף בית, קטגוריה, מאמר או מוצר, עימוד, גרסת שפה, הפניה ועמוד חסר. בדקו דוגמאות ואת הכללים שיוצרים אותן. דף בית אחד שהוגדר נכון אינו מוכיח שאלפי כתובות עם פרמטרים מתנהגות כראוי.
בכל דוגמה תעדו את הסטטוס הרצוי, אפשרות האינדוקס, הכתובת הקנונית ומקור הקישורים הפנימיים. השוו לתגובת HTTP ולמידע של Search Console. רשימה כזאת שימושית יותר מרשימת אזהרות ארוכה שאין מאחוריה החלטה מה כל כתובת אמורה לעשות.
השתמשו ב-robots.txt לשליטה בסריקה, לא להגנה או לאינדוקס
קובץ robots.txt נותן לסורקים תומכים הוראות אילו משאבים מותר לבקש. הוא אינו מאמת משתמשים ואינו מגן על תוכן חסוי. כתובת חסומה עדיין יכולה להיות מוכרת מקישורים, וחסימת האחזור מונעת מ-Google לראות הוראות בתוך העמוד.
הדוגמה הבאה לקובץ בשורש האתר חוסמת נתיב חיפוש פנימי ומצהירה על מפת אתר:
User-agent: *
Disallow: /internal-search/
Sitemap: https://example.com/sitemap.xmlזו אינה המלצה גורפת לחסום כל כתובת חיפוש. החליטו אם העמודים דורשים ניהול סריקה, מניעת אינדוקס או אסטרטגיית כתובות אחרת. אם עמוד צריך לצאת מהאינדקס באמצעות noindex, Google חייבת לאחזר את ההוראה. חסימה מוקדמת עלולה למנוע בדיוק את הבדיקה הנחוצה.
אל תחסמו CSS, JavaScript או תמונות שנדרשים לרינדור תוכן ציבורי חשוב. כלל שיועד לתיקיית משאבים ישנה יכול להשפיע על תבניות עדכניות אחרי פריסה. בדקו את שם המארח, הפרוטוקול והנתיב המדויקים, וודאו שתבנית רחבה אינה תופסת יותר מהמתוכנן.
לתוכן חסוי השתמשו בבקרת גישה אמיתית. לעמוד ציבורי שצריך להישאר שימושי אך לא להופיע בחיפוש, הגדירו הוראת אינדוקס. Google תומכת בתג הבא באזור הראש של עמוד שניתן לסריקה:
<meta name="robots" content="noindex">כותרת התגובה X-Robots-Tag יכולה לקבוע הוראות גם לקובצי PDF ולמשאבים שאינם HTML. בדקו כותרות ותגים יחד. הוראות סותרות עשויות ליצור תוצאה מגבילה יותר מכפי שנראה מתג בודד. ברירת המחדל המאפשרת אינדוקס אינה מחייבת להוסיף index לכל עמוד.
התאימו את קוד התגובה לתוצאה האמיתית
תגובת השרת צריכה להבחין בין תוכן שימושי, עמוד שעבר כתובת, עמוד חסר וכשל זמני בשירות. החזרת אותה מעטפת יישום מוצלחת לכל נתיב יכולה להסתיר את ההבדלים עד ש-JavaScript רץ. הדבר מקשה גם על האבחון וגם על עיבוד החיפוש.
הטבלה מסייעת בהחלטה, ואינה מחליפה את התנהגות HTTP של היישום:
| מצב | תגובה מקובלת | מה לבדוק |
|---|---|---|
| עמוד שימושי זמין | 200 |
גוף התגובה מכיל את התוכן הצפוי |
| תוכן מקביל שעבר לצמיתות | 301 או 308 |
היעד הוא התחליף המתאים |
| מעבר זמני | 302 או 307 |
ההתנהגות הזמנית מכוונת |
| תוכן חסר או שהוסר | 404 או 410 |
אין החלפה בעמוד הצלחה לא רלוונטי |
| תקלה זמנית בשרת | קוד 5xx מתאים |
הניטור מזהה ומאפשר לתקן את התקלה |
תגובת 200 שמכילה רק הודעת שגיאה עשויה להיחשב soft 404. שינוי ההודעה בלי שינוי התגובה לא מתקן את הסתירה. גם הפניית כל מוצר או מאמר שנמחק לדף הבית אינה יוצרת תחליף רלוונטי לכל אחד מהם.
העדיפו הפניה ישירה לכתובת המקבילה הסופית. שרשראות מוסיפות בקשות, מסבכות בדיקות ויוצרות עוד אפשרויות לכללים סותרים. בדקו פרמטרים, מוסכמות ישנות של לוכסן סופי ומעבר מ-HTTP ל-HTTPS. שמרו כתובת היסטורית אם היא עדיין מספקת את התוכן הנכון; עיצוב חדש אינו מחייב כתובת חדשה.
טפלו בשגיאות שרת מתמשכות לפני שיפורי מטא-נתונים קטנים. המדריך לצמצום זמן תגובת השרת מסייע להבחין בין עיכובי שרת המקור לבין בעיות אספקה שפוגעות גם במבקרים וגם באחזור אמין.
יישרו קו בין כתובות קנוניות, קישורים והפניות
קנוניקל מצביע על הנציג המועדף מבין עמודים זהים או דומים מאוד. זו המלצה למנוע החיפוש, ולא פקודה שמבטלת את כל שאר הראיות. Google יכולה לבחור כתובת אחרת כאשר התוכן והאותות מצביעים אליה.
ה-HTML הבא מגדיר כתובת קנונית למדריך לדוגמה:
<link rel="canonical" href="https://example.com/guides/caching/">השתמשו בכתובת מלאה ושמרו על אותה בחירה בתגים, בקישורים הפנימיים, בהפניות ובמפת האתר. אם מפת האתר מקדמת כתובת אחת, התבנית מצביעה לשנייה והניווט לשלישית, הבעיה היא ארכיטקטורה סותרת, לא מחסור בתג נוסף.
קנוניקל שמפנה לעמוד עצמו יכול להבהיר את זהות העמוד המועדף. גרסאות עם פרמטרי מעקב יכולות להפנות אליו כאשר התוכן זהה. אל תפנו קנונית מאמר נפרד לקטגוריה רק משום שהיא חשובה יותר מסחרית. קנוניקל אינו ממזג כוונות חיפוש שונות ואינו מציל תוכן ריק.
גם תרגומים דורשים תשומת לב. לעמוד מתורגם במלואו יש בדרך כלל זהות קנונית משלו, ו-hreflang מציג את חלופות השפה. הפניית כל התרגומים לאנגלית סותרת את ההפרדה הרצויה. כפילויות אזוריות באותה שפה עשויות לדרוש מדיניות מדויקת יותר לפי התוכן והקהל האמיתיים.
ב-Search Console השוו בין הכתובת שהוגדרה לבין זו ש-Google בחרה. אי-התאמה היא נקודת פתיחה לבדיקה. בחנו הפניות, תוכן כפול, קישורים סותרים ונתוני סריקה ישנים לפני בקשות אינדוקס חוזרות.
בנו מפות אתר מהכתובות שבאמת צריכות להיכלל באינדקס
מפת אתר XML מסייעת בגילוי ומשמשת אות לבחירת כתובת קנונית. היא אינה פקודת אינדוקס. כללו כתובות מועדפות ונגישות שמתאימות לחיפוש, והסירו הפניות ברורות, עמודי שגיאה ועמודים שסומנו בכוונה noindex.
צרו את מפת האתר מאותו מאגר תוכן שמפרסם את האתר. רשימה ידנית נפרדת עלולה לסטות: עמודים שנמחקו נשארים, ומדורים חדשים אינם נכנסים. בדקו מדגם לאחר פריסה וודאו שם מארח, HTTPS, קידומת שפה ומוסכמת לוכסן סופי.
השתמשו ב-lastmod רק לשינוי משמעותי אמיתי. החלפת כל התאריכים בכל בנייה מפחיתה את ערכם. עדכון השנה בתחתית העמוד אינו שקול לשינוי המידע המהותי בכל האתר. קשרו את תאריכי הפרסום והעדכון לשינויי תוכן אמיתיים.
הגישו את המפה ב-Search Console ובחנו שגיאות עיבוד ומספר כתובות שהתגלו בהקשר הנכון. עיבוד תקין אינו מוכיח שכל הכתובות נכללו באינדקס. בדקו חריגים חשובים ברמת העמוד והשוו תבניות דומות לפני הגדרת כל החרגה כתקלה.
חברו עמודים חשובים באמצעות קישורים שימושיים
גם הסורק וגם הקורא צריכים מסלול לתוכן שימושי. השתמשו בקישורים רגילים עם טקסט תיאורי וכתובות יעד אמיתיות. כרטיס שנפתח רק באמצעות אירוע JavaScript יכול לעבוד למשתמש ועדיין להיות מסלול גילוי חלש. רכיב קישור תקני הוא הבסיס האמין.
ארגנו קטגוריות סביב משימות הקורא והוסיפו קישורים בהקשר כאשר עמוד מסביר תנאי מקדים או צעד הבא. אוסף מדריכי SEO טכני מדגים חיבור נושאי בין מדריכים. הניווט צריך להסביר את מבנה האתר, ולא רק להציג את כל הכתובות בגוש ארוך.
עומק סריקה הוא כלי אבחון, לא כלל מספרי אוניברסלי. עמוד חשוב שקבור מאחורי שלבים מיותרים דורש טיפול, אבל אין מספר לחיצות שמבטיח אינדוקס או דירוג. חפשו עמודים יתומים, עימוד שבור וקטגוריות שנגישות רק בחיפוש הפנימי.
בקטלוגים גדולים בדקו מסננים ומיון. מספר מצומצם של דפי נחיתה שנבחרו במכוון יכול לענות על צורך בחיפוש, בעוד צירופי פרמטרים בלתי מוגבלים יוצרים עמודים כמעט זהים. החליטו אילו צירופים ראויים לעמודים יציבים ונגישים לאינדוקס, ויישרו בהתאם את הקישורים, הקנוניקל ובקרת הסריקה.
אל תסתירו ניווט חסר באמצעות הוספת כל הכתובות למפת האתר. המפה יכולה לחשוף כתובת, אך אינה מתקנת את מסלול המשתמש או את ההקשר שהקישורים מספקים. בדקו עמודים חשובים מדף הבית ומהקטגוריה שבה מבקר היה מחפש אותם.
תארו חלופות שפה בלי לאחד אותן
hreflang עוזר ל-Google לקשר בין גרסאות שפה או אזור מקבילות. הוא אינו מנגנון תרגום ואינו תחליף לתוכן מקומי משמעותי. כל חלופה צריכה להיות זמינה בכתובת יציבה ולכלול קישורים חוזרים לשאר הגרסאות באותה קבוצה.
הדוגמה הפשוטה באנגלית ובספרדית כוללת גם יעד ברירת מחדל:
<link rel="alternate" hreflang="en" href="https://example.com/guides/caching/">
<link rel="alternate" hreflang="es" href="https://example.com/es/guides/caching/">
<link rel="alternate" hreflang="x-default" href="https://example.com/guides/caching/">הציגו את אותה קבוצה מלאה בשני העמודים המקבילים, לרבות הרשומה של כל עמוד עצמו. x-default הוא יעד חלופי אופציונלי למשתמשים ששפתם או אזורם אינם תואמים לאחת הגרסאות. השתמשו בקודי שפה תקינים ובקוד אזור כשצריך; אזור לבדו אינו שפה.
אל תקשרו עמודים לא קשורים רק משום שהם תופסים אותו מקום בניווט. קטגוריה באנגלית ודף בית בספרדית אינם תרגומים מקבילים. שמרו על התאמה בין הקנוניקל של כל שפה לבין הכתובת ברשומה שלה ובדקו שהיעד אינו מפנה למקום לא צפוי.
הציעו גם קישורי שפה גלויים. הפניות כפויות המבוססות רק על מיקום או שפה משוערים עלולות להקשות על הגישה והבדיקה. המבקר צריך לבחור גרסה, והסורק צריך לאחזר אותה ישירות.
הוסיפו נתונים מובנים שתואמים לתוכן הגלוי
נתונים מובנים מתארים ישויות ותוכן בפורמט שמכונות יכולות לקרוא. בחרו סוג מתאים ונתמך ומלאו את השדות הנדרשים במידע אמיתי. JSON תקין הוא רק שכבת התחביר; דיוק וזכאות לתצוגה עדיין חשובים.
סימון של מאמר צריך לתאר את המאמר המוצג. סימון מוצר אינו יכול להמציא זמינות או דירוגים. אל תוסיפו כוכבים, אנשים או פרטי ארגון רק משום שתבנית דורשת שדה. השמיטו מידע שאינו מבוסס ותקנו את התבנית.
השתמשו בבדיקת התוצאות העשירות עבור תכונות Google הנתמכות, ופענחו שגיאות לפי הסוג שנבחר. מעבר הבדיקה אינו מבטיח תוצאה עשירה או מוכיח שהעמוד באינדקס. עדכנו את הסימון כאשר התוכן הגלוי משתנה, במיוחד כשמחירים, זמינות ותאריכים נוצרים בנפרד.
בדקו תוכן לנייד וביצועים בנפרד
Google משתמשת בעיקר בתוכן גרסת הנייד לצורך אינדוקס. שמרו על זמינות טקסטים, כותרות, קישורים, תמונות ונתונים מובנים חשובים. פריסה קומפקטית יכולה לסדר אותם אחרת, אבל הסרת ההסבר המרכזי או דרישת פעולה כדי לטעון אותו יוצרות מסמך חיפוש שונה.
בדקו גם את החוויה עצמה: טקסט קריא, פקדים שמישים, פריסה יציבה ותגובה מהירה. Core Web Vitals טובים תומכים בחוויה, אך אינם מחליפים נגישות, רלוונטיות או אפשרות אינדוקס. המדריך לקשר בין Core Web Vitals לדירוג מפריד בין אותות ביצועים להבטחות דירוג.
תגובה סטטית מהירה יכולה להתקיים לצד עמוד אינטראקטיבי איטי. גם ציון ביצועים טוב יכול להתקבל בעמוד שהתוכן המרכזי שלו חסר בפלט ש-Google רינדרה. אם JavaScript מספק את התוכן החשוב, פעלו לפי תהליך בדיקת רינדור ו-SEO ל-JavaScript במקום להסיק מהמהירות בלבד שאפשר לאנדקס אותו.
הפכו את הבדיקה לחלק קבוע מהפרסום
בכתובת חשובה, שמרו את כותרות התגובה והגוף לפני בדיקת העמוד המרונדר. הפקודה הבאה מאחזרת את עמוד הדוגמה בבקשת GET רגילה:
curl -sS -D response-headers.txt -o response.html https://example.com/guides/caching/הקבצים מציגים סטטוס ו-HTML ראשוני, לא את ה-DOM הסופי שנוצר ב-JavaScript. השוו אותם לבדיקה בדפדפן וכאשר אפשר גם לכלי בדיקת הכתובות של Search Console. הבדילו בין הדוח השמור על האינדקס לבין בדיקה חיה של הנגישות והרינדור הנוכחיים.
בדקו קנוניקל, הוראות robots, טקסט חשוב וקישורים בכל שלב רלוונטי. לאחר מכן בדקו כתובת חסרה, הפניה וגרסת שפה מאותה משפחת תבניות. כך מזהים תקלות בכללים שעמוד תקין יחיד עלול להסתיר.
תעדפו קודם כשלי גישה ותגובה, אחריהם הוראות סותרות, תוכן חסר ומסלולי גילוי שבורים. השתמשו ברשימת בדיקות הביצועים לעבודת המהירות בהמשך. לכל תיקון רשמו התנהגות צפויה, אחראי ותוצאת בדיקה חוזרת, וחזרו על בדיקות התבניות לאחר שינויים בנתיבים, ברינדור או במטא-נתונים.
