בדיקות לפני העלאת אתר לאוויר: רשימה מסודרת לעסק

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

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

מה בודקים לפני שמעלים אתר לאוויר?

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

מי צריך לעשות את הבדיקות?

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

כמה זמן זה לוקח?

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

איך מוודאים שגוגל יכול לאנדקס את האתר החדש?

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

איפה התג הזה יכול להסתתר?

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

ומה עם הגדרה במערכת ניהול התוכן?

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

מה בודקים בקובץ robots.txt?

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

אפשר לכתוב noindex בתוך robots.txt?

לא. לפי התיעוד של גוגל, כלל noindex בקובץ robots.txt לא נתמך. מי שרוצה להסתיר עמוד משתמש בתג, ולא בקובץ.

מה כן כדאי שיהיה בקובץ?

חסימה רק של אזורים שאין סיבה שייסרקו, וכתובת של מפת האתר. פירטנו במדריך לקובץ robots.txt.

איך מכינים מפת אתר לפני העלייה?

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

איפה שמים את מפת האתר?

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

מה עוד בודקים בה?

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

מה עושים עם הכתובות של האתר הישן?

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

איך יודעים אילו כתובות להפנות?

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

ומה עם http ו-www?

כל הגרסאות של הכתובת, עם www ובלעדיו, ועם http או https, צריכות להוביל לגרסה מאובטחת אחת. אחרת לאותו עמוד יש כמה כתובות, ולא ברור איזו מהן היא הכתובת הראשית.

איזו הפניה לבחור?

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

איך בודקים שהטפסים באמת שולחים פניות?

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

מה עוד בודקים סביב הטופס?

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

ומה עם הודעת האישור לפונה?

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

מה בודקים בטלפון לפני העלייה?

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

על אילו עמודים לא מוותרים?

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

איך בודקים את מהירות האתר לפני העלייה?

מודדים את העמודים המרכזיים בכלי מדידה, ומתקנים קודם תמונות כבדות וסקריפטים מיותרים. לפי ההסבר של web.dev על מדדי הליבה, חוויה טובה פירושה שהתוכן הגדול בעמוד נטען תוך 2.5 שניות, שהתגובה ללחיצה היא 200 מילישניות או פחות, ושציון יציבות התצוגה הוא 0.1 או פחות. אותו הסבר ממליץ למדוד את הספים האלה באחוזון ה-75 של טעינות העמוד, בנפרד לנייד ולמחשב.

למה המדידה לפני העלייה לא מספיקה?

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

מה בודקים בכותרות ובתיאורים?

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

איך בודקים את כל העמודים מהר?

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

ומה עם טקסט לדוגמה?

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

מה בודקים בקישורים ובעמוד השגיאה?

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

איך נראה עמוד שגיאה טוב?

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

מה עושים ביום שאחרי העלייה?

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

ממה כדאי להיזהר בשבוע הראשון?

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

איך מקימים את סרץ' קונסול?

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

מה לבקש מהסטודיו שבונה את האתר?

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

על שם מי רשומים הדומיין והחשבונות?

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

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

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

שאלות נפוצות על בדיקות לפני העלאת אתר