אחסון וורדפרס ל-SEO 2026: לבחור לפי TTFB, לא לפי הייפ

אחסון הוורדפרס הטוב ביותר ל-SEO הוא זה שמשיב ל-Googlebot מהר, משיב לו 200 בכל פעם, ולא נותן לעותק נוסף של האתר שלכם להיכנס לאינדקס. זו כמעט כל הרשימה. כמעט כל דבר אחר שסקירת אחסון מוכרת כ"פיצ'ר SEO" הוא או תוצאה נגזרת של שלושת אלה, או שיווק.

והחלק שרוב המדריכים על אחסון וורדפרס ל-SEO לא אומרים בקול: אחסון הוא גורם דירוג אמיתי, וגורם קטן. התיעוד של Google בנושא page experience קובע במפורש ש"אין אות יחיד", ושהחיפוש "תמיד שואף להציג את התוכן הרלוונטי ביותר, גם אם חוויית הדף אינה מיטבית". שרת של 100 מילישניות לא יציל דף רדוד. אבל שרת שמחזיר 502 מדי פעם באמצע זחילה, או שלוקח לו שתי שניות לייצר HTML לקוראים בצד השני של העולם, אכן יעצור דפים שראויים לדרג. המדריך הזה עוסק בדיוק בפער הזה: במה האחסון באמת שולט, במה הוא לא נוגע בשום מחיר, ואיך למדוד את השרת שלכם בעצמכם במקום לסמוך על טבלת דירוג של מישהו.

עיקרי הדברים

• האחסון אחראי לשלושה דברים שנוגעים ל-SEO: זמן תגובה ראשון (TTFB), זמינות, וקודי ה-HTTP ש-Googlebot מקבל. הוא לא אחראי לאיכות התוכן, למבנה האתר או לקישורים, ואלה מכריעים את רוב הדירוגים.
• ספי ה"טוב" של Google, באחוזון ה-75 של ביקורים אמיתיים: LCP עד 2.5 שניות, INP עד 200 מילישניות, ו-CLS עד 0.1. TTFB הוא מדד אבחוני עם יעד של 0.8 שניות, ולא Core Web Vital.
• CLS הוא כמעט לחלוטין בעיה של תבנית, פרסומות וגופנים. שום מארח לא יתקן אותו בשבילכם.
• שגיאות שרת הן כשל יקר: Google מאטה את קצב הזחילה ביחס למספר הכתובות שמחזירות 5xx, וכתובות ששוגות באופן מתמשך מוסרות מהאינדקס.
• הנזק הנפוץ ביותר שמארח גורם ל-SEO שלכם הוא אתר staging בלחיצה אחת שגוגל יכולה לזחול אליו. חסמו אותו באימות HTTP, לא ב-robots.txt.
• למדו למדוד: curl ל-TTFB, נתוני שדה ב-PageSpeed Insights, ודוח סטטיסטיקות הזחילה ב-Search Console.

במה אחסון וורדפרס ל-SEO באמת שולט

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

תוצאת SEO	כמה האחסון משפיע	מה באמת מתקן
TTFB (זמן לבייט הראשון)	כמעט לחלוטין	גרסת PHP, מטמון דפים, מטמון אובייקטים, בריאות מסד הנתונים, מיקום השרת
קצב זחילה ותקציב זחילה	במידה רבה	תגובות מהירות ועקביות, בלי סופות 5xx או 429
זמינות בזמן זחילה	כמעט לחלוטין	קיבולת, מגבלות משאבים הגיוניות, קוד סטטוס נכון בזמן תחזוקה
LCP	חלקית	TTFB, ובנוסף פורמט תמונה, preload לאלמנט ה-LCP, בלי hero שנטען ב-JS
INP	מעט מאוד	פחות JavaScript, פחות תוספים, תבנית קלה יותר
CLS	כמעט בכלל לא	מידות לתמונות, אסטרטגיית טעינת גופנים, שריון מקום לפרסומות
כתובות כפולות שדלפו לאינדקס	חלקית, ובדרך כלל לרעה	נעילת סביבות staging, אכיפת דומיין קנוני, הפניות נקיות
רלוונטיות ועומק התוכן	בכלל לא	אתם
קישורים פנימיים וקישורים נכנסים	בכלל לא	אתם

TTFB: המספר היחיד שהשרת שלכם באמת מחזיק

TTFB מודד את הזמן מתחילת הבקשה ועד שהבייט הראשון של התשובה מגיע. לפי ההנחיות של Google ב-web.dev, החלון הזה כולל זמן הפניות, חיפוש DNS, יצירת חיבור ומשא ומתן TLS, ואת הבקשה עצמה. היעדים: עד 0.8 שניות נחשב טוב, 0.8 עד 1.8 דורש שיפור, ומעל 1.8 גרוע.

שתי מסקנות. ראשית, TTFB אינו Core Web Vital אלא מדד אבחוני שמסביר נתח גדול מה-LCP. שנית, חלק מה-TTFB שלכם אינו עיבוד בשרת בכלל. אתר ששולח גולשים דרך http ואז https ואז www ואז סלאש בסוף מבזבז שלוש נסיעות הלוך-ושוב לפני שוורדפרס בכלל התחיל לעבוד. בחיבור סלולרי זה יכול לעלות יותר מכל זמן העיבוד של PHP, ושום שדרוג אחסון לא יסיר את זה. תקנו קודם את שרשרת ההפניות.

חמישה גורמים שמניעים TTFB בוורדפרס

1. גרסת PHP ו-OPcache. נכון לספטמבר 2026, php.net מציין ש-PHP 8.2 נמצא בתמיכת אבטחה בלבד שמסתיימת ב-31 בדצמבר 2026, 8.3 בתמיכת אבטחה עד סוף 2027, ו-8.4 ו-8.5 בתמיכה פעילה. אם המארח שלכם עדיין מגדיר לכם 8.1 או 8.2 כברירת מחדל, זה אומר משהו על כל התפעול שלו. ודאו גם ש-OPcache פעיל, אחרת PHP מהדר מחדש את כל קבצי התוספים בכל בקשה.

2. מטמון דפים מלא. ההבדל בין פגיעה במטמון לפספוס הוא ההבדל בין קריאת קובץ לבין הפעלה של כל וורדפרס. פספוס טוען את הליבה, כל תוסף פעיל, את קובץ הפונקציות של התבנית, ומריץ עשרות שאילתות לפני שבייט אחד יוצא מהשרת. לכן מטמון ברמת השרת (Nginx FastCGI cache, LiteSpeed, Varnish) עדיף על תוסף מטמון: התוסף עדיין חייב להעיר את PHP כדי להחליט שאין צורך ב-PHP.

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

4. זמן שאילתות במסד הנתונים. החשודים הרגילים: שורת autoload מנופחת בטבלת האפשרויות, טבלת wp_postmeta בלי אינדקסים בחנות עם עשרות אלפי מוצרים, transients יתומים, ו-WP-Cron שמריץ משימות כבדות על גב בקשות של גולשים. מעבר לשרת גדול יותר מסתיר את זה לזמן מה, אבל לא מסיר את זה.

5. מיקום השרת ביחס לקהל. מרחק הוא נסיעות הלוך-ושוב, ו-TLS צריך כמה מהן. זה קריטי במיוחד לאתרים ישראליים: אתר שמאוחסן בארצות הברית ומשרת קוראים בישראל משלם את המרחק הזה בכל בקשת HTML שאינה במטמון. או שמקרבים את המקור לקהל, או ששמים לפניו CDN שממטמן גם HTML.

אם ה-TTFB שלכם גרוע, לכו לפי הסדר הזה

• איטי רק בבקשה הראשונה ומהר אחר כך? המטמון עובד, אבל פג מהר מדי או קטן מדי. בדקו TTL וכללי החרגה.
• איטי תמיד, גם בלי להיות מחובר? מטמון דפים כבוי, או שמשהו (עוגייה, פרמטר, תוסף סשן) גורם לכל בקשה לעקוף אותו.
• מהיר מנותקים ואיטי מחוברים? חסר לכם מטמון אובייקטים, וכדאי לבדוק מי רץ על admin-ajax.php.
• איטי רק בעומס? זו מגבלת משאבים, לא בעיית מטמון.
• איטי ממדינה אחת ותקין מאחרת? זו גאוגרפיה, לא השרת.

Core Web Vitals ואחסון: מה מארח באמת יכול להזיז

התיעוד של Google מגדיר את הסט הנוכחי כ-LCP, INP ו-CLS, עם ספי "טוב" של 2.5 שניות, 200 מילישניות ו-0.1 בהתאמה, הנמדדים באחוזון ה-75 של טעינות הדף ומופרדים בין מובייל לדסקטופ. האחוזון הזה חשוב: לא שופטים אתכם לפי הביקור הטוב שלכם אלא לפי אחד מהאיטיים. לכן מארח מהיר בממוצע אבל לא עקבי יכול לקבל ציון גרוע יותר ממארח איטי מעט אך יציב.

LCP: האחסון עוזר, אך לרוב לא מסיים את העבודה

ה-TTFB הוא הרצפה שמתחת ל-LCP. אם השרת לוקח 1.2 שניות לבייט הראשון, שום עבודת פרונט לא תביא אתכם ל-2.5 שניות במובייל. אבל ברוב התבניות אלמנט ה-LCP הוא תמונת hero או כותרת מאחורי גופן אינטרנט, והרסנים נפוצים כמו lazy-load על תמונה שמעל הקיפול, סליידר שנבנה ב-JavaScript או PNG לא דחוס אינם באחריות המארח.

INP: לאחסון כמעט אין חלק

INP מודד כמה זמן לוקח לדף להגיב חזותית לאחר אינטראקציה, וזו עבודת JavaScript בדפדפן. עשרים תוספים שכל אחד טוען סקריפטים משלו יפיקו INP גרוע גם על האחסון היקר בעולם. החריג הוא אינטראקציות שממתינות לרשת, כמו הוספה לעגלה מול admin-ajax.php או חיפוש חי מול ה-REST API. שם מטמון אובייקטים ומספיק PHP workers באמת עוזרים.

CLS: המארח לא יכול לעזור, וזה בסדר

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

תקציב זחילה וקודי תגובה של השרת

תיעוד תקציב הזחילה של Google מתאר את המנגנון ישירות: אם זמני התגובה יציבים או משתפרים, המגבלה עולה ואפשר להשתמש ביותר חיבורים לזחילה. אם ההשהיה עולה או שהאתר מחזיר שגיאות 5xx או 429, המגבלה יורדת וגוגל זוחלת פחות.

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

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

זמינות, שגיאות 5xx וחלונות תחזוקה שגוגל סולחת עליהם

אחוזי זמינות בעמודי שיווק כמעט חסרי ערך, כי המספר לא מספר מתי הייתה ההשבתה ומה הוחזר בה. התיעוד של Google מדויק יותר: תגובות 5xx ו-429 גורמות לזחלנים להאט זמנית, וההאטה פרופורציונלית למספר הכתובות שמחזירות שגיאת שרת. אם זה נמשך, מנגנון האינדוקס מסיר מהאינדקס כתובות ששוגות באופן מתמשך. ההתאוששות הדרגתית ברגע שחוזרים להחזיר 2xx.

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

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

HTTP/2, HTTP/3 ו-TLS: רווח אמיתי, בסדר גודל נכון

HTTP/2 מרבב בקשות רבות על חיבור אחד ומסיר את מגבלת שישה החיבורים לדומיין. HTTP/3 רץ מעל QUIC ומקטין את עלות ה-handshake ואת ההשפעה של אובדן חבילות, מה שבולט במיוחד ברשתות סלולריות ובחיבורים למרחקים גדולים, כלומר בדיוק המצב של גולש ישראלי מול שרת אמריקאי. שניהם שווים.

אבל תנו לזה את הגודל הנכון. הפרוטוקולים משנים את אופן ההגעה של הנכסים ולכן מופיעים בנתוני שדה, אך הם אינם תיבת סימון שגוגל מתגמלת עליה, ומעבר מ-HTTP/2 ל-HTTP/3 באתר עם תגובת שרת של 900 מילישניות לא ישנה דבר. תקנו קודם את זמן התגובה. ואם אתם מאחורי CDN, הפרוטוקול שהגולשים מקבלים הוא של ה-CDN, לא של השרת שלכם.

CDN מול מיקום השרת: איזו בעיה אתם פותרים

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

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

• קהל במדינה אחת: העמידו את השרת באותה מדינה או קרוב אליה. לאתר ישראלי זה בדרך כלל אירופה. זה מנצח CDN עבור ה-HTML.
• שניים-שלושה אזורים: שרת בשוק הגדול ביותר, ומטמון HTML בקצה לשאר.
• קהל גלובלי באמת: מטמון HTML בקצה אינו אופציונלי.
• רוב התנועה מחוברת: הקצה עוזר פחות. עדיפים שרת קרוב ומטמון אובייקטים טוב.

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

בעיית ה-staging: אסון SEO אמיתי שמארחים גורמים

סביבת staging בלחיצה אחת היא פיצ'ר שימושי, וגם המקור לתקלות ה-SEO החמורות ביותר שנגרמות על ידי מארחים. התבנית תמיד זהה: המארח יוצר עותק של האתר בכתובת כמו staging.example.com, העותק נגיש לציבור, ובסוף גוגל מוצאת אותו.

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

• אימות HTTP ברמת שרת האינטרנט על שם המארח של ה-staging. Googlebot מקבל 401 ואין מה לאנדקס. זו האפשרות היחידה שעמידה גם כשמישהו מקשר לכתובת.
• כותרת X-Robots-Tag: noindex על ה-vhost של ה-staging כשהאתר נשאר ניתן לזחילה, כדי שהכותרת אכן תיראה.
• הגבלה לפי כתובות IP אם לצוות יש כתובות קבועות.

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

איך למדוד בעצמכם את השפעת האחסון על ה-SEO

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

1. מדידת TTFB עם curl

curl -o /dev/null -s -w "dns:     %{time_namelookup}s
connect: %{time_connect}s
tls:     %{time_appconnect}s
ttfb:    %{time_starttransfer}s
total:   %{time_total}s
status:  %{http_code}
" https://example.com/

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

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

for i in 1 2 3 4 5 6 7 8 9 10; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

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

curl -o /dev/null -s -w "uncached ttfb: %{time_starttransfer}s\n" "https://example.com/?cachebust=90210"

ולבסוף ודאו שהמטמון בכלל פעיל, דרך כותרות התשובה:

curl -sI https://example.com/ | grep -Ei "^(http|server|cache-control|age|x-cache|x-litespeed-cache|cf-cache-status)"

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

2. PageSpeed Insights: נתוני שדה, לא הציון

פתחו את PageSpeed Insights והתעלמו מהציון הצבעוני, שהוא נתוני מעבדה ממכשיר מובייל מדומה בחיבור מוגבל. לפי התיעוד של Google, החלק שחשוב הוא נתוני המשתמשים האמיתיים מ-Chrome User Experience Report, שמכסים את 28 הימים האחרונים ומדווחים באחוזון ה-75. זה אותו סוג נתונים שמערכות הדירוג משתמשות בו.

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

3. סטטיסטיקות זחילה ב-Search Console

בתוך Search Console, גשו להגדרות ואז לסטטיסטיקות זחילה. הדוח מציג סך בקשות הזחילה, נפח ההורדה וזמן התגובה הממוצע, בפילוח לפי קוד תגובה, סוג קובץ, מטרת הזחילה וסוג ה-Googlebot, יחד עם מצב המארח שמכסה שליפת robots.txt, פענוח DNS וקישוריות לשרת.

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

אחסון וורדפרס ל-SEO: איזו רמה מתאימה לאתר שלכם

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

רמה	פרופיל עלות	חוזקות SEO	סיכוני SEO	למי מתאים
שיתופי זול	הנמוך ביותר	HTTPS, מספיק לתנועה נמוכה	תקרות משאבים, שכנים רועשים, ברירות מחדל ישנות של PHP	אתרים חדשים, בלוגים לפני תנועה
שיתופי איכותי או NVMe	נמוך	מטמון ברמת שרת, PHP עדכני, TTFB סביר	מגבלות שמתגלות דווקא בעומס, גישה מוגבלת ללוגים	אתרי עסקים קטנים, בלוגים בינוניים
וורדפרס מנוהל	בינוני עד גבוה	מטמון ומטמון אובייקטים מוגדרים מראש, staging, תמיכה שמכירה וורדפרס	הגבלות תוספים, תמחור לפי אתר, פחות שליטה	עסקי תוכן שמעדיפים לקנות את הכוונון
מנוהל מבוסס קצה	גבוה	HTML ממוטמן בקצה כברירת מחדל, הפתרון החזק ל-TTFB גלובלי	מחיר פרימיום, מורכבות עקיפת מטמון באתרים דינמיים	מפרסמים וחנויות עם קהל בכמה יבשות
VPS לא מנוהל	נמוך עד בינוני	שליטה מלאה ב-PHP, במטמון, ב-Redis, באזור ובמגבלות	כל שגיאת הגדרה היא שלכם, כולל זו שמחזירה 500 בשלוש לפנות בוקר	מפתחים וסוכנויות עם מישהו זמין
VPS מנוהל או ענן	בינוני	שליטה, ובנוסף מישהו אחר מתחזק את מערכת ההפעלה	איכות התמיכה משתנה מאוד בין ספקים	חנויות צומחות שיצאו משיתופי

לבחור את המארח הטוב ביותר ל-SEO: אפשרויות ופשרות

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

ספקי וורדפרס מנוהל כמו Kinsta ו-WP Engine מוכרים קונפיגורציה ותמיכה: מטמון שרת, מטמון אובייקטים, staging וגיבויים מוכנים מראש. הפשרות אמיתיות, ובהן תמחור לפי אתר ורשימות תוספים אסורים.

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

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

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

Devoster רלוונטי בשתי נקודות. אחסון וורדפרס מנוהל ואחסון שיתופי מתחילים ב-2.90 דולר לחודש בתוכנית Lite ו-5.90 ב-Standard, עם cPanel זמין. שרתי ה-VPS מסוג KVM נעים מ-Nano ב-3.49 דולר לחודש (1 vCPU, 1 GB זיכרון, 25 GB NVMe) ועד Mega ב-34.99 (10 vCPU, 24 GB, 200 GB), על חומרת Intel Xeon Gold 6138 עם אחסון NVMe, קו 1 Gbps, תעבורה בלתי מוגבלת, הגנת DDoS, גישת root מלאה והעברה חינם.

ומתי Devoster אינו הבחירה הנכונה, בלי לייפות:

• מעט אזורים. באחסון השיתופי ובוורדפרס המנוהל אפשר לבחור אירופה או ארצות הברית בלי תוספת מחיר; קו ה-VPS נמצא בדרום ארצות הברית בלבד. לקהל בהודו או באוסטרליה, כל בקשת HTML שאינה במטמון חוצה אוקיינוס, אלא אם תשימו לפניה CDN שממטמן HTML. לקהל שכולו מחוץ לאזורים האלה, מארח מקומי ינצח אותנו ב-TTFB, ועדיף שתדעו את זה עכשיו.
• קו ה-VPS אינו מנוהל. גישת root מלאה פירושה שעדכוני ליבה, כוונון PHP-FPM, Redis, גיבויים והשגיאה של שלוש לפנות בוקר הם שלכם.
• אין לנו רשת קצה גלובלית משלנו. תצטרכו להביא Cloudflare או BunnyCDN ולהגדיר מטמון HTML בעצמכם. זה עובד היטב ועולה מעט, אבל זו משימה ולא תיבת סימון.

מעבר מארח בלי לאבד דירוגים

מיגרציות מאבדות דירוגים מסיבות משעממות, לא מסתוריות. לפני המעבר: סרקו את האתר החי עם Screaming Frog או Sitebulb ושמרו את הייצוא כנקודת ייחוס לכל כתובת, קוד סטטוס וקנוניקל; תעדו מדידות בסיס של TTFB, נתוני שדה וסטטיסטיקות זחילה; קחו גיבוי מלא שאתם יודעים לשחזר בעצמכם; והורידו TTL של DNS לחמש דקות לפחות 48 שעות מראש.

במהלך המעבר: בנו ובדקו על המארח החדש כשהדומיין מופנה דרך קובץ ה-hosts, כדי ששום דבר לא יהיה נגיש לציבור מוקדם מדי, ואם חייבים כתובת זמנית שימו עליה אימות HTTP. השאירו את המארח הישן פעיל לפחות שבוע. שחזרו את ההפניות במדויק ושטחו שרשראות לקפיצה אחת. ודאו שהדומיין הקנוני נפתר בדרך אחת בלבד, https בלבד.

ב-24 השעות שאחרי: בדקו הגדרות ואז קריאה בוורדפרס כדי לוודא שהאתר אינו מסומן כחסום למנועי חיפוש; משכו את robots.txt ואת מפת האתר מהדומיין החי; סרקו מחדש והשוו לייצוא שלפני המעבר; השתמשו בבדיקת כתובות ב-Search Console על כמה עמודים חשובים; ועקבו אחרי קפיצת 5xx בסטטיסטיקות הזחילה בשבוע שאחרי.

מתי האחסון בכלל לא הבעיה שלכם

זה החלק שכתבות אחרות משמיטות, כי הוא לא מוכר אחסון. אם נתוני השדה שלכם ירוקים, ה-TTFB הלא ממוטמן שלכם נמוך בנוחות מחצי שנייה מהאזור של הקהל, ובסטטיסטיקות הזחילה אין 5xx וזמן התגובה יציב, ואתם עדיין תקועים בעמוד השני, האחסון אינו האילוץ שלכם. מעבר ספק לא ישנה דבר שתראו ב-Search Console.

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

שאלות נפוצות

האם אחסון וורדפרס באמת משפיע על SEO?

כן, בשלוש דרכים: זמן התגובה של השרת נכנס לתוך LCP שהוא Core Web Vital שמערכות הדירוג משתמשות בו; תגובות איטיות ושגיאות 5xx מקטינות את היקף הזחילה; ושגיאות שרת מתמשכות עלולות להוציא כתובות מהאינדקס. זה גורם אמיתי, וקטן ביחס לתוכן ולקישורים.

לאיזה TTFB כדאי לכוון?

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

האם מעבר למארח מהיר יותר ישפר את הדירוגים שלי?

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

האם אחסון שיתופי גרוע ל-SEO?

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

האם צריך CDN לקידום אתר וורדפרס?

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

האם מיקום השרת משנה ל-SEO?

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

בשורה התחתונה

בחירת אחסון וורדפרס ל-SEO מסתכמת בארבע בדיקות ולא בטבלת דירוג. האם הוא נותן TTFB נמוך ועקבי מהאזור שבו הקוראים שלכם? האם הוא מחזיר 200 באופן אמין, ואפשר לראות לוגים כשלא? האם הוא מריץ PHP עדכני עם מטמון אמיתי ברמת השרת ומטמון אובייקטים? והאם סביבת ה-staging שלו נעולה בפני Googlebot כברירת מחדל?

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