אתר טוב לא מתחיל מרשימת עמודים. הוא מתחיל מהעסק שהוא צריך לייצג.
כל עוד האתר קטן, אפשר להסתדר עם עמודים שנבנו אחד אחרי השני. הקושי מופיע כשנוספים פרויקטים, קטגוריות, שפות, אנשי תוכן ומסלולי מכירה. אז מתברר אם האתר הוא מערכת שאפשר להרחיב או אוסף עמודים שצריך לתקן בכל שינוי.
ארכיטקטורת אתר מגדירה את יחידות המידע, את הקשרים ביניהן ואת הדרך שבה משתמש מתקדם להבנה ולפעולה.
השאלה שמובילה את התכנון היא: מהו המבנה הפנימי של העסק, ואיך מתרגמים אותו למודל דיגיטלי עקבי, ניתן לניהול וניתן להרחבה?
מהי ארכיטקטורת אתר?
מפת אתר, תפריט וכתובות הם רק הביטוי החיצוני. הארכיטקטורה מחברת ארבע שכבות:
- המודל העסקי: מה העסק מציע ואיך הלקוחות קונים.
- ארכיטקטורת המידע: איך המשתמש מוצא תוכן ומבין את הקשרים.
- מודל התוכן: אילו ישויות קיימות, מה מתאר כל אחת ואיך הן מתחברות.
- היישום: איך המודל הופך לנתיבים, תבניות, רכיבים ומערכת ניהול.
במקום לשאול כמה עמודים צריך, שואלים מה מנוהל פעם אחת, היכן הוא מוצג ומה יקרה כשכמות התוכן תוכפל. העמודים הם תוצאה של ההחלטות האלה.
דלתות המושב: להפוך גלריית עבודות למודל קטלוג דינמי
דלתות המושב מציג מגוון גדול של דלתות, מדרגות, חיפויי קיר ופרויקטים בהתאמה אישית. גלריה אחת הייתה מציגה את התמונות, אבל לא עוזרת למשתמש להגיע לסוג העבודה שהוא מחפש.
לכן האתר נבנה סביב היררכיה ברורה:
תחום → קטגוריה → תת־קטגוריה → דגם או פרויקט.
ברמה היישומית, ההיררכיה הזאת מקבלת ביטוי גם במבנה הנתיבים:
/gallery/[category]/[subcategory]/[slug]
הנתיב משקף את מקומו של הפריט במודל. תבנית דינמית אחת מקבלת את שם הפרויקט, התיאור, הקטגוריות והמדיה, וממקמת אותו בעמודים ובגלריות המתאימים. כך אפשר להוסיף עבודה חדשה בלי לבנות שוב את מבנה האתר.
מה העסק מרוויח?
המשתמש מתקדם מתחום רחב לדגם מסוים. צוות התוכן מוסיף עבודה למבנה קיים במקום לעצב עמוד חדש. מנועי חיפוש מקבלים היררכיה וקישורים פנימיים עקביים. הארכיטקטורה אינה מבטיחה דירוג, אבל היא מסירה חסמים להבנת התוכן.
PROJECT SYSTEM / 01: לא קטלוג, אלא ארכיטקטורה של קבלת החלטה
PROJECT SYSTEM / 01 הוא דמו למערכת אתר של עסק שירותי שצומח דרך פרויקטים ומקרי בוחן. כאן הלקוח צריך להבין את השירות, לראות הוכחה ולבחור את הצעד הבא.
אותה תשתית טכנולוגית יכולה לשרת קטלוג ואתר שירותים, אבל המודל העסקי מכתיב מבנה אחר. ב־Uni.Mi, המוצר הקמה ובניית אתר נשען על Uni.Mi Foundation, שמספקת מנגנוני הנדסה משותפים. Uni.Mi CMS מחברת את מודל התוכן לניהול, פרסום ומדידה.
במערכת הפרויקטים, הישויות המרכזיות הן:
שירותים, מסלולי ליווי, פרויקטים, מאמרים ופעולות המרה.
הקשר המרכזי הוא בין צורך, שירות והוכחה:
צורך → מסלול שירות → הסבר מקצועי → פרויקט רלוונטי → הוכחה → שיחת התאמה.
עמוד שירות מחבר לפרויקטים שממחישים אותו, למאמרים שעונים על התלבטויות ולפעולה הבאה. פרויקט הוא אובייקט הוכחה: הוא מציג את ההקשר, התהליך והתוצאה. מאמר מסיר חסם ומוביל לתוכן או לשירות הרלוונטי.
כך מתקבלת מערכת של קשרים:
Service ← Project
Service ← Article
Project → Relevant Service
Article → Relevant Service
Service → Conversion
כך האתר מחבר בין מידע, הוכחה ופעולה.
STORE / 01: כשהקטלוג הופך למסלול רכישה
STORE / 01 מדגים חנות דיגיטלית שמחברת בין גילוי, בחירה ורכישה. כל מוצר הוא ישות עם שם, תיאור, מחיר, מדיה, קולקציה, אפשרויות רכישה וקשרים למוצרים או למארזים נוספים.
במערכת החנות, הישויות המרכזיות הן:
מוצרים, קולקציות, מארזים, מועדפים, סל והזמנה.
מסלול המשתמש נראה כך:
צורך → גילוי → מוצר → השוואה או שמירה → מארז → סל → הזמנה.
כל מוצר עובר דרך אותה תבנית. הנתונים והמדיה קובעים את הנתיב, התמונות, פעולות הרכישה והקשרים המסחריים.
במהדורה הנוכחית המועדפים, הסל וה־checkout פועלים עם נתוני דמו מקומיים בלבד. אין סליקה חיה או חיבור לנתוני לקוחות. מטרת ההדגמה היא להראות את מבנה היחסים שמערכת מסחר צריכה לנהל.
כך מתקבלת מערכת קשרים אחרת:
Collection ← Product
Product ↔ Related Product
Product → Favorite
Product → Bag
Set → Products
Bag → Order
הערך נמצא ביכולת להוסיף מוצרים ולשנות שיוכים בלי לפרק את חוויית הקנייה.
אותה מילת מפתח, שלוש ארכיטקטורות שונות
שלוש המערכות מתרחבות דרך יחידות תוכן, אבל כל אחת פותרת בעיה אחרת:
- בדלתות המושב, הטקסונומיה מובילה מתחום לפריט.
- במערכת הפרויקטים, קשרים בין שירות, תוכן והוכחה מובילים לפנייה.
- בחנות, מסלול מסחרי מוביל מגילוי להזמנה.
לכן אין מבנה אחד שנכון לכל אתר. גם כשמתחילים מתשתית מוכנה, מתאימים לעסק את מודל התוכן, הקשרים ומסלול ההמרה.
כיצד מתרגמים עסק לארכיטקטורה דיגיטלית?
1. מיפוי הדומיין העסקי
ממפים מה החברה מוכרת, איך הפעילות מחולקת, מה צוות השיווק מנהל ואילו שינויים צפויים. המטרה היא לזהות את המבנה הלוגי של העסק.
2. הגדרת ישויות וקשרים
מגדירים את יחידות המידע המרכזיות, למשל:
Product
Category
Subcategory
Project
Service
Article
Media
Location
Team Member
לכל ישות מגדירים שדות וקשרים. פרויקט יכול להיות קשור לשירות, פריט לקטגוריה ותמונה לפרויקט וגם לעמוד קטגוריה. זה הבסיס למודל התוכן ולמערכת הניהול.
3. בניית הטקסונומיה ומבנה הכתובות
לא כל חלוקה עסקית צריכה להופיע בתפריט, ולא כל שדה צריך להפוך לעמוד. מחליטים:
- מהו עמוד נחיתה עצמאי.
- מהי קטגוריה שניתן לנווט אליה.
- מה משמש רק לסינון.
- מהו הקשר בין ההיררכיה העסקית למבנה ה־URL.
- איך נשמרת עקביות כשהאתר גדל.
מבנה הכתובות נגזר מהמודל ולא מהצטברות מקרית של עמודים.
4. תכנון התבניות הדינמיות
אחרי שהישויות ברורות, מגדירים תבניות. תבנית פרויקט אחת יכולה להציג מאה פרויקטים בצורה עקבית. כללי קטגוריה מחליפים בנייה ידנית של כל עמוד.
5. תכנון מסלולי המשתמש והקישורים הפנימיים
מחליטים איזה פרויקט יופיע ליד שירות, לאן מאמר יוביל ומה הפעולה המתאימה בכל שלב. כל עמוד פנימי צריך לספק הקשר, המשכיות וצעד הבא גם למי שלא עבר בעמוד הבית.
6. תכנון ניהול, מדידה וצמיחה
לבסוף מגדירים מה העורך מזין, מה נוצר אוטומטית, איך מודדים עניין, איזו מדיה נטענת ומה יידרש בהוספת שפה או סוג תוכן. ההחלטות האלה קודמות לעיצוב.
למה זה חשוב לחברות שגדלות?
בארכיטקטורה מסודרת, תוכן חדש נכנס לתבנית קיימת, הקשרים נשמרים והמדידה תואמת למודל העסקי. בלי מבנה כזה, כל שינוי יוצר שכפול, כתובת חדשה או חיבור ידני. התוצאה היא אתר שקשה לנהל, למדוד ולהרחיב.
בעידן שבו קל לייצר מסך, קשה יותר לבנות מערכת טובה
כלים אוטומטיים ו־AI יכולים לייצר מסכים במהירות. הם לא מחליטים מהו מודל העסק, אילו ישויות הוא מנהל ואיך נשמרת עקביות כשהמערכת גדלה.
Uni.Mi מתחילה מהדומיין העסקי, מגדירה את מודל התוכן והקשרים, ואז מתרגמת אותם לניווט, לתבניות, למערכת ניהול ולחוויית משתמש.
העיצוב הוא שכבת הממשק של האתר.
הארכיטקטורה היא מנגנון ההפעלה שלו.