הפוסט נכתב בשיתוף אייל רחמים, המייסד של חברת דיגיטאץ' ושל seolinks קידום אתרים.
תכנון נכון של אתר דומה לתכנון בניין – ושניהם מתחילים ביסודות. ככל שהקבלן ירצה לבנות בניין גבוה יותר, כך יסודותיו צריכים להיות עמוקים ויציבים יותר. זהו אולי הצעד החשוב ביותר של תהליך הבנייה, משום שהבסיס הוא זה שאמור לשאת את כל כובד משקלו של הבניין ולתמוך בו בהצלחה לאורך זמן.
אילו השלד של הבניין יהיה רעוע או יסבול מפגמים, אזי כל הבניין שייבנה עליו בהמשך יהיה בסכנה.
אותו הדבר נכון לגבי עיצוב ובניית אתרים וקידומם במנועי החיפוש. במקרה הזה, את יסודות הבניין מחליף הקוד שנמצא בבסיסו של האתר; ואם נדרש לבנות אתר יציב, בר קיימא, שגם עושה חיל במנועי החיפוש – אזי תכנון אסטרטגיית ה-SEO שלו חייבת להתחיל כבר מהקוד.
זאת משום שתהליך בניית האתר הוא בעיקרו חד כיווני, ומרגע שהקוד קיים ועליו מתווספים אלמנטים של תוכן, עיצוב ופעילויות קידום אורגני, אזי קשה מאוד לחזור לאחור ולבצע תיקונים או שינויים בקוד; לעיתים, כדי לייצר אסטרטגיית SEO טובה אין מנוס מביצוע שינויים גדולים בכל האתר, לעיתים עד כדי בנייתו מחדש.
איך ליצור קוד אתר באופן אופטימלי כך שיתמוך באסטרטגיית ה-SEO שלו בהמשך? להלן כמה נקודות שכדאי להביא בחשבון:
לבחור נכון: HTTP או HTTPS
בעבר רוב אתרי האינטרנט היו מבוססים על פרוטוקול HTTP, אולם תוספת ה-S פירושה שכבת אבטחה נוספת: המידע שעובר בין הדפדפן לשרת מוצפן. זה חשוב במיוחד באתרים שמבצעים סליקה או אוספים פרטים אישיים, אבל גוגל ממליצה על HTTPS בכל אתר, גם כשאין בו מידע רגיש. כדאי לדעת גם שפרוטוקול HTTPS הוא אחד מהשיקולים של האלגוריתם של גוגל. לכן עדיף לבנות את האתר על HTTPS מההתחלה, בכל העמודים שלו.
להתחיל הכי מהר ולהאיץ
למהירות האתר יש חשיבות קריטית הן עבור חוויית המשתמש והן כגורם דירוג באלגוריתמים של מנועי החיפוש. עם זאת, לעיתים קודים של אתרים ותיקים וגדולים כוללים חלקים מיותרים שמכבידים על האתר ומאטים את מהירותו. בעת בניית אתר חדש, כלומר כתיבת קוד מההתחלה, כדאי לוודא שהקוד יהיה נקי מאלמנטים מיותרים ולהקדיש תשומת לב בפרט לאלה הקשורים למהירותו.
גוגל מודד את חוויית השימוש בעמוד בשלושה מדדים שנקראים Core Web Vitals. LCP מודד תוך כמה זמן נטען האלמנט הגדול ביותר שנראה במסך (היעד: עד 2.5 שניות). INP מודד כמה מהר העמוד מגיב ללחיצות ולהקלדה (היעד: פחות מ-200 אלפיות שנייה). CLS מודד כמה התוכן בעמוד זז באופן לא צפוי (היעד: ציון נמוך מ-0.1). את הנתונים של האתר אפשר לראות בדוח Core Web Vitals בסרץ' קונסול וב-PageSpeed Insights. חלק גדול מהתיקונים נעשה בקוד עצמו, למשל הגדרת רוחב וגובה לכל תמונה, כדי שהעמוד לא יקפוץ בזמן הטעינה.
להציג גרסה אחת בלבד למנועי החיפוש
שגיאה נפוצה בקרב אתרים רבים, ולאו דווקא מכוונת, היא מתן אפשרות לגוגל ולמנועי חיפוש אחרים לגשת למספר עותקים של אותו עמוד. למשל, גרסה אחת רגילה ועוד גרסה של תצוגה מקדימה או תצוגה לפני הדפסה. הבעיה בכך היא שהגרסאות השונות מתחרות ופוגעות זו בזו. לכן חשוב לקבוע כבר בעת בניית קוד האתר איזו גרסה תוצג בפני מנועי החיפוש (Canonical Version), באמצעות מתן זיהוי ייחודי לכל עמוד באתר והגדרה שלכל פיסת תוכן ניתן יהיה לגשת אך ורק דרך ה-URL שלו.
בפועל עושים את זה בעיקר בשתי דרכים: הפניית 301 מכל גרסה כפולה של הכתובת (למשל http מול https, או עם www ובלי) לגרסה אחת, ותגית rel="canonical" בכל עמוד שמצביעה על הכתובת המועדפת שלו. לפי גוגל, שתיהן אותות חזקים, והכללת הכתובת במפת האתר היא אות חלש יותר. חשוב שכל האותות יצביעו על אותה כתובת, וגם הקישורים הפנימיים באתר צריכים להוביל אליה ולא לגרסה הכפולה.
לכתוב קוד שגוגל יכול לרנדר
באתרים רבים חלק מהתוכן נבנה בעזרת JavaScript. גוגל מטפל בעמודים כאלה בשלושה שלבים: סריקה, רינדור ואינדוקס. עמוד יכול לחכות בתור לרינדור כמה שניות, ולפעמים יותר, ורק אחרי הרינדור גוגל רואה את התוכן שה-JavaScript מוסיף. גוגל עצמה ממליצה על רינדור בצד השרת (SSR) או על רינדור מוקדם (Pre-rendering): העמוד נטען מהר יותר לגולשים ולזחלנים, וחלק מהבוטים לא מסוגלים להריץ JavaScript. עוד נקודה שקל לפספס: גוגל מזהה קישורים רק כשהם בנויים כתגית a עם מאפיין href. גוגל לא ימצא קישור שעובד רק דרך אירוע לחיצה ב-JavaScript.
פרדון מיי פרנץ', אמיגו
האם האתר המדובר מתוכנן לפנות ליותר ממדינה אחת או יותר משפה אחת? אם כן, חשוב להביא בחשבון כבר בעת בנייתו נושאים רב-שפתיים ורב-איזוריים כגון לוקאליזציה של מילות מפתח, תכנים משוכפלים וכדומה. לדוגמה, האם לבנות אתר שונה עבור כל שפה באמצעות דומיינים שונים, מה שיחייב השקעת משאבים גבוהה בבנייה של מספר אתרים, תפעולם, יצירת תוכן ייחודי לכל אחד מהם וקידומם בנפרד במנועי החיפוש; או אולי מוטב לאחד את כל האתרים תחת דומיין אחד ולחלק אותם לתת-תיקיות שניתן לנהל דרך מערכת ניהול תוכן יחידה?
חשוב לשמור על גמישות!
גוגל נוטה לבצע שינויים תכופים באלגוריתם דירוג האתרים בצורה שלעיתים עשויה להיות משמעותית מבחינת ההשפעה על קידום אתרים מסוימים. לא כל עדכון באלגוריתם מחייב ביצוע שינויים באתר או באסטרטגיית ה-SEO שלו, אולם לעיתים עשוי להיווצר מצב בו כדאי לבצע שינויים כאלה. לפיכך כדאי לבנות את קוד האתר באופן שיאפשר ביצוע עריכה או שינויים מהירים בעת הצורך.
למה לתכנן SEO לפני כתיבת הקוד?
קידום אתרים במנועי החיפוש, ובראשם גוגל, נחשב היום לחלק בלתי נפרד מהקמה וניהול של אתר. לא תמיד זה היה כך: בעבר נהוג היה קודם כל לבנות אתר, וככל שהתפתחו מנועי החיפוש כך התפתחו בהתאם אסטרטגיות לקידומו של האתר הקיים. הסדר הזה נשמר לאורך שנים רבות: קודם בונים אתר ואחר כך חושבים איך לקדם אותו במנועי החיפוש – אולם המציאות השתנתה ומחייבת את היפוך הסדר: קודם מתכננים את קידומו של האתר באמצעות בנייה מדוקדקת של אסטרטגיית SEO, ולפיה בונים את הקוד באופן יעיל שיתמוך באותה אסטרטגיה בהמשך.
אף בונה אתרים או מומחה קידום אתרים לא יכול להשפיע על מה שגוגל עושה, אבל בהחלט ניתן לבנות אתרים בצורה שתאפשר התאמה אופטימלית לאלגוריתם הדינאמי של גוגל ולטפס לצמרת תוצאות החיפוש. להלן הוצגו מספר נושאים שכדאי להביא בחשבון, אבל חשוב לזכור שאלה היו רק דוגמאות שמטרתן לכוון את אופן החשיבה של המפתח/ים. בקוד יש לכלול גם אלמנטים טכניים יותר, כמו תגי כותרת, תיאורי מטא, תגי קנוניקל וכדומה – אולם בשורה התחתונה: חשוב לבנות את האתר מתוך מחשבה עתידית על קידומו.
