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

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

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

שני עולמות תוכן, ולמה זה כל הסיפור

אתר Bebop. בנוי על ארכיטקטורה היברידית. הפרונט הוא Next.js 16 (App Router, עברית RTL) שרץ על Vercel ומשרת את bebop.co.il. הבק-אנד הוא WordPress headless שרץ על Cloudways תחת cms.bebop.co.il, נחשף דרך WPGraphQL, ומוגדר ב-noindex בכוונה כדי שגוגל יראה רק את הדומיין הראשי. אם המבנה הזה זר לכם, ההשוואה בין Headless ל-WordPress קלאסי היא נקודת ההתחלה הנכונה.

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

• עמודים שיווקיים (code-driven): הבית, עמודי השירות, about, האבחון. אלה אובייקטי data מוקלדים תחת src/lib/bebop/data, שמוזנים לטמפלייטים תחת src/components/bebop/templates, ומנוהלים ב-Git.
• הבלוג (/blog): נמשך מ-WordPress דרך GraphQL עם ISR, כך שתוכן מתרענן אוטומטית כל שעה בלי deploy.

השאלה הראשונה לפני כל פעולה היא תמיד אותה שאלה: לאיזה עולם השינוי הזה שייך. כל שאר המדריך נבנה על התשובה.

מה אפשר ומה אי אפשר דרך WordPress

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

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

הפלואו לפי סוג שינוי

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

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

מתכון: עריכת טקסט בעמוד שירות

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

1. פותחים את src/lib/bebop/data/services/.ts (למשל seo.ts או geo.ts).
2. עורכים את השדה הרלוונטי באובייקט. השדות המרכזיים: h1, dek (פסקת הפתיחה), whatIs, audience, includes, process, whyBebop, faq ו-closing.
3. שומרים. בסביבת הפיתוח (npm run dev) השינוי מופיע מיד.

שני כללי כתיבה שמובנים לתוך הטמפלייט עצמו:

• הדגשת ליים: עטיפת מקטע טקסט בכוכביות הופכת אותו להדגשת הליים של המותג. כך ה-h1 של עמוד ה-SEO כולל *תשתית שמייצרת לידים ומכירות*, וזה מה שמודגש על המסך.
• כיווניות אוטומטית: מונחים באנגלית בתוך טקסט עברי RTL נעטפים אוטומטית לכיווניות LTR, כך ש-SEO ו-GEO נשארים קריאים בתוך משפט עברי בלי התערבות ידנית.

מתכון: הוספת עמוד שירות חדש

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

1. קובץ data. יוצרים אובייקט ServiceData תחת src/lib/bebop/data/services/ וממלאים את שדותיו: slug, category, primaryKeyword, metaTitle, metaDesc, crumbs, h1, dek, whatIs, audience, includes, process, whyBebop, faq ו-closing.
2. ראוט. מוסיפים את הנתיב ל-src/lib/bebop/routes.ts, כדי שיהיה קבוע אחד שכל שאר הקוד מפנה אליו.
3. קובץ page.tsx. מייצאים metadata שכולל title, description ו-alternates.canonical, ומרנדרים את התוכן בתוך BebopFrame שמרנדר גרסת מובייל וגרסת דסקטופ. ה-JSON-LD נפלט פעם אחת ברמת העמוד דרך קומפוננטת JsonLd.
4. חיווט. מקשרים את העמוד לתפריטים ולפוטר.

נקודה קריטית: ה-JSON-LD חייב להיפלט פעם אחת בלבד ברמת העמוד, ולא מתוך הטמפלייט. הסיבה היא ש-BebopFrame מרנדר את התוכן פעמיים, פעם למובייל ופעם לדסקטופ. אם הסכמה תיפלט מתוך הטמפלייט, מנועי החיפוש ומנועי ה-AI יראו שתי סכמות כפולות לאותו עמוד. לכן ה-JsonLd יושב ב-page.tsx, מחוץ למסגרת שמכפילה. אותו עיקרון חל על ה-canonical וכל המטא: הם נגזרים פעם אחת מאובייקט ה-data, ולא מהטמפלייט.

מתכון: פרסום פוסט בלוג

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

1. נכנסים ללוח הניהול ב-cms.bebop.co.il, בוחרים Posts ואז Add New.
2. כותבים את התוכן, מגדירים קטגוריות, תגיות ומחבר.
3. ממלאים את Rank Math: כותרת SEO, תיאור מטא ותמונת OG.
4. מעלים תמונה ראשית. התמונה מתארחת על cms.bebop.co.il, וזה הדומיין היחיד שממנו הפרונט מורשה לטעון תמונות בלוג.
5. לוחצים Publish.

הפוסט מופיע ב-bebop.co.il/blog תוך עד שעה הודות ל-ISR, או מיד אחרי redeploy. ה-slug של הפוסט הוא הכתובת הסופית שלו באתר, אז בוחרים אותו בקפידה.

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

ניווט ממקור אמת אחד

כל הניווט באתר נובע ממקום אחד: src/lib/bebop/routes.ts. שם מוגדרים קבועי הראוט, קבוצות המגה-מניו, הניווט העליון ועמודות הפוטר. העיקרון הוא best practice קלאסי: מקור אמת אחד לניווט. כשמשנים נתיב במקום אחד, כל הקישורים באתר מתעדכנים יחד, ואין סיכוי לקישור שבור בגלל עריכה חלקית.

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

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

גדול לוקאלית, קטן מרחוק

לא כל שינוי דורש את אותה סביבה. הכלל הוא לפי גודל העבודה.

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

1. git clone של הריפו.
2. npm install.
3. npm run dev כדי לראות שינויים בזמן אמת.
4. עובדים בענף עבודה נפרד, לא ב-main.
5. npm run build כדי לוודא שה-build נקי.
6. git push שיוצר Preview Deployment אוטומטי לבדיקה.

שינוי קטן, מרחוק. תיקון טקסט קצר בקובץ data אפשר לעשות דרך עורך הקוד של GitHub בדפדפן (github.dev) או דרך Codespace, בלי להקים סביבה מקומית.

נקודה שחשוב להפנים: Vercel הוא לתפעול, לא לעריכת קוד. שם עושים redeploy, קוראים לוגים, מנהלים משתני סביבה ומגדירים דומיינים. את הקוד עורכים ב-Git. שלושת משתני הסביבה שהאתר תלוי בהם הם NEXT_PUBLIC_SITE_URL, NEXT_PUBLIC_WORDPRESS_API_URL ו-NEXT_PUBLIC_WORDPRESS_URL. הם נצרבים ב-build, ולכן כל שינוי בערך שלהם דורש redeploy כדי להיכנס לתוקף. הזרימה המלאה הזו, מ-push ועד אתר חי, מתוארת בהרחבה ב-מדריך CI/CD עם Git ו-Vercel בלי לשבור SEO.

איפה נשמר ה-SEO הטכני

הצד הטכני של ה-SEO לא חי ב-WordPress וגם לא בקובצי ה-data של העמודים. הוא מיוצר על ידי Next.js ומוגש מ-bebop.co.il: sitemap.xml, robots.txt ו-llms.txt. ה-metadataBase נגזר מ-NEXT_PUBLIC_SITE_URL ומייצר canonical מוחלט לכל עמוד. ל-Google Search Console שולחים רק את bebop.co.il/sitemap.xml, אף פעם לא את ה-CMS.

בצד ה-GEO, קובץ llms.txt זמין ב-bebop.co.il/llms.txt, וה-JSON-LD (סכמות Service, BreadcrumbList ו-FAQPage) נפלט פעם אחת ברמת העמוד, מאותה סיבה בדיוק שתיארנו במתכון העמוד החדש. ההיגיון המלא מאחורי המבנה הזה מפורט ב-המדריך ל-SEO טכני באתר Headless: sitemap, canonical ו-ISR.

הצ’קליסט לפני כל העלאה

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

• build נקי. npm run build רץ עד הסוף בלי שגיאות.
• בלי קישור לעמוד לא בנוי. כל ראוט חדש שמקשרים אליו כבר קיים כעמוד.
• כל מקורות הניווט מסונכרנים. אם הוספתם פריט תפריט, הוא קיים גם ב-routes.ts וגם בכל מערך נוסף שמרנדר ניווט בדסקטופ.
• עמוד חדש שלם. כולל canonical ו-JSON-LD ברמת העמוד, פעם אחת.
• הקופי עומד בחוקי הברנד. הסמן תמיד Bebop. באנגלית, בלי em-dash, תמיד “12 שנים”, בלי טענות כמות לקוחות, “לידים ומכירות”, בלי אימוג’י.
• פוסט בלוג מוכן. אם פרסמתם פוסט, הוא כולל Rank Math מלא ותמונה ראשית מ-cms.bebop.co.il.

למה אנחנו מפרסמים את ספר ההפעלה

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