מעבר אחסון לוורדפרס בלי דאון-טיים — נוהל מלא שלב אחר שלב

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

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

למה בכלל יש דאון-טיים

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

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

שלב 0 — הכנה (יומיים לפני)

הורידו את ה-TTL

TTL קובע כמה זמן שרתי DNS שומרים תשובה במטמון. ברירת המחדל היא לרוב 3600 שניות או יותר.

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

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

תעדו הכול

• רשומות DNS נוכחיות — צילום מסך של כל הרשומות
• רשומות דואר (MX) במיוחד
• גרסת PHP הנוכחית
• רשימת תוספים פעילים
• אילו שירותים חיצוניים מצביעים על האתר

גיבוי מלא

לפני שנוגעים במשהו. זו נקודת הנסיגה שלכם.

שלב 1 — הקמת האתר החדש

צרו את החשבון החדש והעלו את האתר, בלי לגעת ב-DNS.

העברת הקבצים

באתר קטן — ארכיון וחילוץ. באתר גדול, rsync חוסך זמן רב:

rsync -avz --progress /old/public_html/ user@newhost:/home/user/public_html/

היתרון: אפשר להריץ שוב לפני המעבר הסופי, והוא יעביר רק מה שהשתנה.

העברת מסד הנתונים

mysqldump -u user -p --single-transaction --quick olddb > backup.sql
mysql -u user -p newdb < backup.sql

--single-transaction חשוב: הוא מייצא תמונת מצב עקבית בלי לנעול את הטבלאות, כך שהאתר הישן ממשיך לעבוד בזמן הייצוא.

עדכון wp-config.php

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

שלב 2 — בדיקה לפני שעוברים

כאן ההבדל בין מעבר חלק למעבר מלחיץ. בדקו את האתר החדש לפני ש-DNS משתנה.

עריכת קובץ hosts

הפניית המחשב שלכם בלבד לשרת החדש:

Windows: C:\Windows\System32\drivers\etc\hosts macOS / Linux: /etc/hosts

203.0.113.45  example.co.il www.example.co.il

עכשיו הדפדפן שלכם רואה את השרת החדש, וכל שאר העולם עדיין את הישן.

רשימת בדיקה

• [ ] דף הבית נטען
• [ ] חמישה דפים פנימיים אקראיים
• [ ] התחברות לניהול
• [ ] טופס יצירת קשר — שולח מייל בפועל?
• [ ] חיפוש פנימי
• [ ] תמונות נטענות (בדקו קונסול)
• [ ] בחנות: הוספה לעגלה, תהליך תשלום מלא
• [ ] קישורים קבועים (Permalinks) עובדים
• [ ] SSL תקין
• [ ] TTFB — האם באמת השתפר?

טופס המייל הוא הכשל הנפוץ ביותר. שרת חדש אומר IP חדש, ואם רשומות SPF ו-DKIM לא עודכנו — המיילים נכנסים לספאם או לא נשלחים כלל.

שלב 3 — הסנכרון האחרון

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

סנכרנו שוב, סמוך למעבר:

rsync -avz --delete /old/public_html/ user@newhost:/home/user/public_html/
mysqldump ... | mysql ...

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

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

שלב 4 — מעבר ה-DNS

עכשיו, ורק עכשיו.

1. שנו את רשומת ה-A לכתובת החדשה
2. שנו גם את רשומת www
3. אל תיגעו ברשומות MX אלא אם הדואר עובר גם הוא

עם TTL של 300 שניות, רוב העולם יעבור תוך 5–15 דקות.

מה קורה בזמן המעבר

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

מעקב

dig example.co.il +short

מכמה רשתות שונות אם אפשר — סלולר, משרד, בית.

שלב 5 — אחרי המעבר

מיד

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

תוך 24 שעות

• בדקו את יומני השגיאות בשרת החדש
• ודאו שהגיבויים החדשים רצים
• ודאו שמשימות ה-cron פועלות
• בדקו ב-Search Console שאין קפיצה בשגיאות סריקה

תוך שבוע

• השוו ביצועים: TTFB לפני ואחרי
• ודאו שהתנועה האורגנית יציבה
• ורק אז — בטלו את החשבון הישן

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

מקרים שדורשים תשומת לב מיוחדת

דואר שרץ על אותו דומיין

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

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

אתר עם מספר דומיינים

אם האתר עונה גם ל-example.co.il וגם ל-example.com, ודאו ששניהם מוגדרים בשרת החדש לפני המעבר. דומיין שנשכח יציג שגיאת אישור SSL.

ריבוי אתרים (Multisite)

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

הפניות מותאמות

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

מה אנחנו רואים אצל מי שנכשל

מניסיון בהעברות, שלוש הטעויות שחוזרות:

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

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

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

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

לשנות DNS לפני שבודקים. הבסיס של כל מה שכתוב כאן.

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

לא לעדכן SPF. ה-IP השולח השתנה. בלי עדכון, המיילים נחשבים מזויפים.

להעביר רק את הקבצים. בלי מסד הנתונים אין אתר.

לשכוח את הקישורים הקבועים. אם מבנה השרת שונה, ייתכן שצריך לשמור מחדש את הגדרות ה-Permalinks כדי לייצר את .htaccess.

לבטל את הישן מיד. אין דרך חזרה.

אם משהו השתבש

זו הסיבה ל-TTL הנמוך: החזרת רשומת ה-A לכתובת הישנה מחזירה את המצב תוך דקות. האתר הישן עדיין שם, עדיין עובד, עדיין עם הנתונים.

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

שאלות נפוצות

כמה זמן לוקח מעבר מלא? העברת קבצים ומסד נתונים — בין חצי שעה למספר שעות לפי גודל. הבדיקה — שעה. מעבר ה-DNS עצמו — דקות, אם ה-TTL הוכן מראש. סך הכל: יום עבודה אחד, רובו המתנה.

האם אאבד דירוג בגוגל? לא, אם הכתובות נשארות זהות והאתר לא יורד. מעבר שרת אינו שינוי כתובת. אם משהו כן משתנה במבנה — הפניות 301 שומרות על הדירוג.

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

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

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

שלוש נקודות לזכור

ה-TTL הוא הכל. הורדתו 48 שעות מראש היא ההבדל בין מעבר של חמש דקות למעבר של יומיים, והיא הצעד היחיד שאי אפשר להשלים בדיעבד.

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

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

---

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