פורסם 2 ביולי 2026
מיגרציית אתר לשרת חדש היא לרוב מהלך של שעות בודדות, ובתנאי שהיא מתוכננת היא לא אמורה לפגוע בדירוג האורגני. הסדר שעובד: גיבוי מלא שנבדק, העברת קבצים ובסיס נתונים, בדיקה על השרת החדש לפני שמישהו רואה אותו, עדכון DNS, ואז סריקה שמאתרת שגיאות 404 ומטפלת בהן בהפניות 301. רוב הירידות בדירוג אחרי מעבר נובעות מפרטים קטנים שנשכחו, לא מהמעבר עצמו. המדריך הזה עובר על השלבים לפי הסדר, ומסמן איפה בדרך כלל נופלים.
למה מעבר שרת נחשב מסוכן, ולמה בדרך כלל הוא לא
גוגל לא מדרג שרתים, הוא מדרג כתובות URL. כל עוד אותן כתובות ממשיכות להחזיר את אותו תוכן ואת אותו קוד סטטוס, המעבר שקוף כמעט לחלוטין למנועי החיפוש. הסיכון מתחיל כשמשהו משתנה בלי כוונה: מבנה כתובות שהשתנה, קובץ robots.txt שנשאר בגרסת פיתוח וחוסם סריקה, דפים שמחזירים שגיאת שרת במשך יממה, או אתר שפתאום איטי בהרבה. אלה דברים שאפשר למנוע מראש, ולכן מעבר שרת נכשל בעיקר כשהוא נעשה בלי רשימת בדיקות.
כדאי לקרוא גם: קידום אתרים לעסקים קטנים ב-2026: המדריך המלא ל-SEO ול-GEO · קישורים פנימיים באתר: מדריך Internal Linking לדירוג · איך לכתוב תוכן שגוגל ו-AI בוחרים להציג בתשובות – מדריך מעשי ל-SEO בעידן החדש
שלב 1: גיבוי מקדים שאפשר באמת לשחזר ממנו
גיבוי הוא לא קובץ שיושב בתיקייה, הוא יכולת שחזור. לפני שנוגעים בכלום כדאי להוציא גיבוי מלא של הקבצים (כולל ספריית המדיה, קבצי התצורה והתוספים) וגיבוי נפרד של בסיס הנתונים, ולשמור אותם בשני מקומות שאינם השרת הישן.
- לוודא שקובץ בסיס הנתונים נפתח ולא נקטע באמצע הייצוא.
- לתעד את גרסאות PHP, מסד הנתונים ושרת האינטרנט בשרת הישן, כדי לשחזר סביבה דומה.
- לשמור עותק של קובצי ההגדרה: htaccess. או תצורת nginx, robots.txt ומפת אתר.
- לייצא רשימת כתובות מלאה של האתר לפני המעבר. זו תהיה נקודת ההשוואה אחר כך.
מי שמנהל אתר עם רכישות או טפסים יעדיף להקפיא פעילות לזמן קצר: הזמנה שנכנסת אחרי הגיבוי ולפני המעבר פשוט תיעלם.
שלב 2: העברת קבצים ובסיס נתונים
את הקבצים מעבירים בדרך כלל ב-SFTP או בהעתקה ישירה בין שרתים, ואת בסיס הנתונים בייצוא וייבוא של קובץ SQL. שתי נקודות שנוטות להישבר: הרשאות קבצים ותיקיות, וקידוד התווים. אתר בעברית שיובא בקידוד שגוי יציג ג'יבריש בכל הדפים, ולכן כדאי לוודא שהייצוא והייבוא נעשים ב-utf8mb4.
אחרי הייבוא מעדכנים את פרטי החיבור בקובץ התצורה, ואם כתובת האתר משתנה, מבצעים החלפה מסודרת של הכתובות בבסיס הנתונים בכלי שמטפל נכון בשדות מסודרים (serialized) ולא בהחלפת טקסט גולמית.
שלב 3: בדיקה על השרת החדש לפני עדכון DNS
זה השלב שהכי חוסך כאב ראש, והכי מדלגים עליו. אפשר להפנות את המחשב המקומי לשרת החדש דרך קובץ hosts, ולגלוש לאתר בכתובת האמיתית בזמן שכל שאר העולם עדיין רואה את השרת הישן.
- לעבור על עמוד הבית, קטגוריה, מאמר, עמוד יצירת קשר ותהליך רכישה מלא.
- לוודא ש-robots.txt לא חוסם סריקה ושאין תגית noindex שהגיעה מסביבת הבדיקה.
- לבדוק שהתעודה SSL מותקנת ותקפה, ושהמעבר מ-HTTP ל-HTTPS עובד.
- למדוד מהירות טעינה ולהשוות לשרת הישן. שרת חדש אמור להיות מהיר יותר, לא איטי יותר.
שלב 4: עדכון DNS וזמן ההשבתה הצפוי
יום-יומיים לפני המעבר כדאי להוריד את ערך ה-TTL של רשומות ה-DNS לערך נמוך (למשל 300 שניות), כדי שהשינוי יתפשט מהר. ביום המעבר מעדכנים את רשומת ה-A לכתובת ה-IP החדשה, ומשאירים את השרת הישן פעיל עוד 24 עד 72 שעות כדי לשרת גולשים שה-DNS שלהם עדיין לא התעדכן.
| שלב | זמן משוער | השבתה בפועל |
|---|---|---|
| גיבוי ותיעוד | שעה עד שעתיים | אין |
| העברת קבצים ובסיס נתונים | שעה עד ארבע שעות | אין (האתר הישן חי) |
| בדיקות על השרת החדש | שעה עד שלוש שעות | אין |
| עדכון DNS והתפשטות | עד 48 שעות | לרוב דקות עד שעות בודדות |
| בדיקות אחרי המעבר | יום עד שבוע | אין |
הטווחים משוערים ומשתנים לפי גודל האתר, נפח המדיה וספק האחסון. באתר תדמית קטן כל התהליך יכול להסתיים בחצי יום עבודה, באתר מסחר עם עשרות אלפי מוצרים מדובר במהלך של כמה ימים.
שלב 5: בדיקת 404 והפניות 301
מיד אחרי שהאתר החדש חי, מריצים סריקה מלאה בכלי סריקה (crawler) ומשווים לרשימת הכתובות שנשמרה לפני המעבר. כל כתובת שמחזירה 404 וקיבלה תנועה או קישורים בעבר צריכה הפניה 301 ליעד הרלוונטי ביותר. הפניה לעמוד הבית היא פתרון עצל: גוגל מתייחס אליה לא פעם כאל שגיאה רכה, והערך של הדף המקורי הולך לאיבוד.
במקביל כדאי לשלוח מפת אתר מעודכנת ב-Search Console, לבדוק את דוח הכיסוי בימים שאחרי, ולוודא שאין שרשראות הפניה ארוכות. אם משתמשים בשיטות תוכן שמותאמות גם למנועי תשובות, זה גם הרגע לחזור למדריך העוגן שלנו על קידום אתרים SEO ו-GEO ולוודא שהנתונים המובנים והסכמות עברו עם האתר ולא נשארו מאחור.
טעויות נפוצות שפוגעות בדירוג ואיך למנוע אותן
| הטעות | מה קורה בפועל | איך מונעים |
|---|---|---|
| robots.txt מסביבת פיתוח | חסימת סריקה מלאה, נשירת דפים מהאינדקס תוך שבועות | לבדוק את robots.txt מיד אחרי עדכון DNS ולוודא Allow |
| תגית noindex שנשארה | דפים יורדים מהאינדקס בלי הודעה | סריקה שמאתרת noindex לפני ואחרי המעבר |
| שינוי מבנה כתובות בלי הפניות | מאות שגיאות 404 ואובדן קישורים נכנסים | מיפוי כתובת ישנה מול חדשה והפניות 301 אחד לאחד |
| SSL לא מותקן או לא תואם | אזהרת דפדפן, נטישה מיידית, ירידה בהמרות | להתקין ולבדוק תעודה לפני שמעדכנים DNS |
| שרת חדש איטי יותר | פגיעה בחוויית העמוד ובקצב הסריקה | מדידת זמני תגובה לפני ואחרי, שימוש במטמון ו-CDN |
| כיבוי מוקדם של השרת הישן | חלק מהגולשים מגיעים לשום מקום | להשאיר את הישן פעיל 24 עד 72 שעות |
| קוד מדידה שלא הועתק | נתונים חסרים בדיוק בתקופה הקריטית | לאמת ירי אירועים ופיקסלים ביום המעבר |
| אובדן קבצי אימות בעלות | ניתוק מ-Search Console ומכלים חיצוניים | להעתיק קובצי אימות ורשומות TXT |
מה למדוד בשבועיים שאחרי
אחרי מעבר, המדידה חשובה לא פחות מהביצוע. כדאי לעקוב אחרי מספר הדפים המאונדקסים, שגיאות סריקה, זמני תגובת שרת ותנועה אורגנית יומית לעומת התקופה המקבילה. תנודה של כמה אחוזים בימים הראשונים היא נורמלית, ירידה חדה ומתמשכת היא סימן שמשהו טכני נשבר. מי שרוצה לדעת אילו דוחות באמת מספרים את הסיפור יכול להיעזר במדריך על Google Analytics 4 לבעלי עסקים. מי שמריץ קמפיינים בתשלום צריך לוודא שדפי הנחיתה חיים ושהמרות נרשמות, כי תקציב שרץ לדף שבור נשרף במהירות. הנקודה הזו מפורטת גם במדריך על פרסום בגוגל לעסקים.
שאלות נפוצות
כמה זמן האתר יהיה למטה?
אם השרת הישן נשאר פעיל במהלך התפשטות ה-DNS, ההשבתה בפועל היא בדרך כלל דקות עד שעות בודדות, ולעיתים קרובות אפסית. התפשטות מלאה יכולה להימשך עד 48 שעות, אבל בזמן הזה הגולשים רואים אתר תקין, ישן או חדש.
האם מעבר שרת פוגע בדירוג בגוגל?
מעבר מתוכנן, שבו הכתובות והתוכן נשארים זהים, לרוב לא משפיע על הדירוג. השפעה שלילית מגיעה משגיאות נלוות: חסימת סריקה, שגיאות שרת ממושכות, אובדן הפניות או ירידה משמעותית במהירות.
צריך להודיע לגוגל על המעבר?
כשהדומיין נשאר זהה אין צורך בהודעה מיוחדת. מספיק לשלוח מפת אתר מעודכנת ולעקוב אחרי דוחות הסריקה. כלי שינוי הכתובת ב-Search Console נדרש רק כשמחליפים דומיין, לא שרת.
מתי הזמן הטוב ביותר לבצע מיגרציית אתר?
בשעות התנועה הנמוכות של האתר, ולא לפני אירוע עסקי גדול או קמפיין. כדאי להימנע מימי שישי ומערבי חג, כדי שיהיה מי שיטפל בתקלה אם היא מתגלה שעות אחר כך.
מה עושים אם התנועה צנחה אחרי המעבר?
קודם בודקים את robots.txt, תגיות noindex, קודי סטטוס וזמני תגובה, ורק אחר כך מחפשים הסברים תוכניים. ברוב המקרים מדובר בכשל טכני נקודתי שמתוקן תוך שעות, והתנועה חוזרת בתוך שבוע עד שבועיים.
לסיכום
מיגרציית אתר לשרת חדש היא פרויקט של סדר פעולות, לא של מזל. גיבוי שנבדק, העברה מסודרת של קבצים ובסיס נתונים, בדיקה מלאה לפני עדכון DNS, השארת השרת הישן פעיל ליומיים, וטיפול מהיר בשגיאות 404 באמצעות הפניות 301: חמשת אלה מכסים את רוב הסיכון. מי שמקצה לתהליך חצי יום עבודה ורשימת בדיקות כתובה, יסיים את המעבר עם אתר מהיר יותר ובלי חור בדוחות.
עורך, שיווק דיגיטלי
עומר לביא עורך את evpweb. עשר שנים בניהול קמפיינים ובאנליטיקס לעסקים קטנים לימדו אותו שרוב הכסף בשיווק דיגיטלי הולך לאיבוד בגלל החלטות קטנות: מילת מפתח לא נכונה, דף נחיתה איטי, מדידה שלא הוגדרה. הוא כותב בשביל בעלי עסקים שרוצים להבין מה הם קונים לפני שהם משלמים.
