וורדפרס, שופיפיי או פיתוח מותאם: איך בוחרים תשתית לאתר

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

השאלה האמיתית היא לא באיזו טכנולוגיה

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

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

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

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

האפשרויות על השולחן, בשורה אחת כל אחת

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

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

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

וורדפרס וווקומרס: מתי כן ומתי לא

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

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

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

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

שופיפיי: מתי היא התשובה הנכונה

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

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

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

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

וויקס ובוני אתרים אחרים: מה הם באמת נותנים

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

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

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

פיתוח מותאם ו-headless: מתי זה מוצדק

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

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

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

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

עלות הבעלות על פני שלוש שנים

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

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

ביצועים ומדדי הליבה: מה תלוי בפלטפורמה ומה לא

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

גוגל מודדת שלושה מדדי ליבה בשטח, לפי חוויה אמיתית של גולשים בנייד:

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

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

נגישות ואבטחה: איפה כל פלטפורמה מציבה אתכם

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

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

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

מי יערוך את התוכן, ובאילו שפות

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

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

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

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

לבנות מחדש או לתקן את מה שיש

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

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

מעבר בין פלטפורמות בלי לאבד את גוגל

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

כמה כללים שמצילים מעברים:

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

מטריצת ההחלטה שתמלאו לפני שמחליטים

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

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

מה לכתוב במפרט או במכרז כדי לקבל הצעות שאפשר להשוות

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

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

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

מה עושים עכשיו

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

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