thelaw.co.il דאשבורד פרויקט הגירה
החלטות אסטרטגיות בפרויקט

הסברים — מה החלטנו, ולמה

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

עודכן לאחרונה: 9 במאי 2026
9 שאלות / תגליות

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

אם משהו לא ברור או חסר — תגיד, נוסיף קלף חדש.

החלטה מס׳ 1 · CMS
איזה CMS משמש את האתר החדש?

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

חלופה — להישאר על WordPress
WP + theme חדש או WP-headless
UI בעברית, אלון מכיר
תחזוקה מתמדת (גרסאות, אבטחה, תוספים)
PHP attack surface, סיכון נפילות
שירת המטרה לסיים עם WP — מנוגד
המומלצת
Sanity (hosted CMS)
אפס תחזוקה — אין שרת, אין DB, אין updates
Image pipeline מוביל בשוק (חיוני לאתר תוכן)
Free tier מספיק (5GB מדיה, 10K מסמכים)
Studio בכתובת נפרדת — אלון לא יכול לשבור עיצוב
Studio באנגלית (ניתן לכוון RTL ושמות שדות בעברית)
חלופות שלא נבחרו ולמה:
  • Strapi — דורש self-host (Node.js + DB), אנחנו חוזרים לבעיית התחזוקה
  • Payload v3 — אלגנטי, פתוח, אבל גם self-host וגם דורש Postgres
  • Contentful / Storyblok — יקרים משמעותית מ־Sanity, לא מצדיקים את ההפרש
  • Decap CMS / Tina — Markdown ב־Git, מעולה למפתחים, מסובך מדי לעו"ד שיוסיף מאמר אחת לחודש
החלטה: Sanity. הסטיודיו ייפרס ב־studio.thelaw.co.il כתת־דומיין נפרד. לאלון יוצר משתמש ב־Sanity, הוא מתחבר עם Google, רואה טפסים בעברית RTL ומוסיף תוכן.
החלטה מס׳ 2 · מבנה כתובות
מבנה הקישורים (permalinks) של מאמרים — לשמור או לשנות?

הפוסטים באתר הקיים יושבים על מבנה /YYYY/MM/DD/<slug>/ — לדוגמה /2026/04/16/...גניבת-זהות.../. זה מבנה ישן (היה ברירת מחדל ב־WP בעבר) ולא מומלץ היום.

המומלצת
לשמור — /YYYY/MM/DD/slug/
123 redirects 1:1, סיכון אפס ל־SEO
URLs ישנים מדורגים בגוגל ממשיכים לעבוד מיידית
פחות עבודת מיפוי (פשוט מעתיקים)
URL ארוך ופחות יפה
חלופה — לשנות
/articles/<slug>/
URL נקי וקצר יותר
CTR קצת יותר טוב בגוגל
123 redirects חדשים מ־/YYYY/MM/DD/ ל־/articles/
סיכון קטן של ירידה זמנית בדירוגים בזמן ההעברה
המלצה: לשמור על המבנה הקיים. הסיכון מהשינוי לא מצדיק את הרווח האסתטי. אם בעוד שנה תרצה לשנות — תמיד אפשר, וגם אז זה רק שכבת redirects נוספת.
החלטה מס׳ 3 · מבנה תוכן
סדרות (CPT series) — להשאיר או למזג?

באתר הקיים יש 5 "סדרות" כסוג תוכן נפרד: פטור ממס הכנסה, קורונה, זיוף מקרקעין, יבוא בלעדי, כתב הגנה. כל אחת חיה ב־/series/<slug>/ ומאגדת מספר מאמרים.

המומלצת
לשמור — סוג תוכן נפרד ב־Sanity
SEO: 5 דפי landing נפרדים שכבר מדורגים בגוגל
UX: עמוד "סדרת מאמרים" עם כותרת, תיאור, ורשימה — ערך לקורא
Sanity תומך ב־schema יעודי בקלות
חלופה — למזג ל־tag
להפוך לתגית מסוג מיוחד
סכימה פשוטה יותר
איבוד 5 דפי landing מדורגים בגוגל
חוויית משתמש פחות טובה
החלטה: סדרות נשארות כסוג תוכן עצמאי ב־Sanity (series document type). כל מאמר מקבל reference לסדרה (אופציונלי — לא כל מאמר חייב להיות בסדרה). ה־URL נשאר /series/<slug>/.
החלטה מס׳ 4 · SEO
איך מטפלים ב־159 ה־URLs הישנים?

גוגל יודע על 159 כתובות באתר הקיים. כשנעלה אתר חדש, צריך שכל אחת תפנה ליעד תואם — אחרת איבדנו דירוגים, קישורים נכנסים ותנועה אורגנית. השאלה היא איך מקצים את ה־redirects.

המומלצת
Full Coverage — 301 לכל URL
אפס סיכון לאיבוד דירוגים
לא תלוי ב־GSC או נתוני traffic (יש רק 3 שבועות)
תחזוקה אפסית: קובץ אחד עם 159 שורות
חלופה — סינון לפי תנועה
Redirect רק ל־URLs עם traffic
פחות שורות בקובץ ה־redirects
דורש שנה+ של נתוני GSC (אין לנו)
סיכון: URL שעדיין מדורג ולא ראינו תנועה אליו ב־3 שבועות → 404
החלטה: כל 159 ה־URLs מקבלים redirect 301. היחידים שיקבלו 410 (Gone, deleted) הם דפים שתסמן ידנית כזבל (כרגע 5 מועמדים: form-test, formtest, test, 4306, 4234).
החלטה מס׳ 5 · זיהוי דפים מיותרים
5 דפים נראים כמו leftovers של פיתוח — מה לעשות איתם?

בסקירה ראשונית של 31 הדפים גילינו 5 שנראים כמו דפי בדיקה שנשארו מפיתוח קודם:

  • /form-test/ — כותרת: "form test"
  • /formtest/ — כותרת: "בדיקת טפסים"
  • /test/ — כותרת: "משפט מסחרי, ליטיגציה..."
  • /4306/ — ללא כותרת
  • /4234/ — ללא כותרת
נדרש: תפתח את 5 הקישורים, תוודא שאין שם תוכן בעל ערך, ותחזיר אישור. אם הכל זבל — נסמן 410 Gone (URL נמחק לצמיתות, גוגל יוריד אותו מהאינדקס תוך כמה שבועות). אם איזשהו דף הוא לא זבל — נסמן 301 ליעד תואם.
החלטה מס׳ 6 · אירוח
איפה האתר החדש יתארח?

צריך אירוח מהיר, יציב, וזול. האתר הוא static-rendered (Next.js SSG) עם תוכן שנשלף מ־Sanity בזמן הבנייה.

המומלצת
Cloudflare Pages
חינמי ל־500 builds/חודש (יותר מספיק)
CDN גלובלי כלול
SSL אוטומטי, קובץ _redirects מובנה
כבר עובדים שם — ה־8 סקיצות וה־דאשבורד הזה מאוחסנים בו
חלופה
Vercel / Netlify
אינטגרציה טובה יותר עם Next.js
חיוב מדורג, פחות נדיב מ־Cloudflare
פחות שליטה בהגדרות DNS
החלטה: Cloudflare Pages, בחשבון של אלון. אלון יפתח חשבון ויזמין אותך כ־Super Administrator.
החלטה מס׳ 7 · גישה ל־WP הקיים
איזה רמת גישה אנחנו צריכים ל־thelaw.co.il הנוכחי?

אפשרויות תיאורטיות: SSH לשרת, גישת אדמין ל־WP, רק REST API פומבי.

המומלצת
Application Password ל־REST API
קריאה בלבד מהקוד, מעולם לא נוגעים
אלון יוצר ב־5 דקות, ניתן לבטל בלחיצה
לא דורש מאלון להתעסק עם cPanel/SFTP
חלופה
SSH/SFTP לשרת
גישה ל־access logs (תועיל ל־traffic insights)
דורש לערב את חברת האחסון, מסבך את אלון
מסכן: גישה ישירה אומרת אפשרות לטעות
החלטה: Application Password בלבד. read-only מוחלט — לא נוגעים ב־WP הקיים בשום שלב. גם בשלב ההגירה רק שולפים תוכן ולא משנים דבר. אם בעתיד יוחלט שצריך access logs לוודאות נוספת על traffic, נבקש מאלון לפנות לחברת האחסון.
תגלית מס׳ 8 · בסיס SEO קיים
מצב ה־SEO באתר הקיים — מה גילינו, ולמה זה משנה את הגישה?

בדיקה ישירה של ה־HTML של האתר (curl + Screaming Frog crawl) חשפה תמונה מפתיעה: אין באתר ניהול SEO פעיל. כל ההנחות הקודמות שהיו על "Yoast configuration שצריך לשמר" התבררו כשגויות.

מה שגילינו:
  • Yoast SEO Premium מותקן (גרסה 4.8 ישנה) אבל כבוי
  • אין שום תוסף SEO פעיל אחר (לא Rank Math, לא AIO SEO)
  • 0 JSON-LD schema בכל הדפים
  • 0 meta description tags ב־180 דפים שנסרקו (לא 0 מלא — אפס מלא)
  • אין Open Graph / Twitter Cards
  • רק 2 redirects פנימיים פעילים (www→non-www, trailing slash) — אין Yoast Redirects
  • sitemap.xml שבור — מחזיר HTML של homepage
מה שכן יש (וצריך לשמר):
  • Title tags — 181 דפים, נוצר אוטומטית מ־post_title של WordPress
  • URLs (זה ה־redirect map שלנו)
  • תוכן (מועבר 1:1)
  • google-site-verification + facebook-domain-verification (נשמרים)
השלכה לעבודה: ה־"שמירת SEO" הופכת להיות פשוטה הרבה יותר ממה שחשבנו — שומרים URLs + titles + תוכן, וזהו. אין שכבת תוסף לחקות. כל schema/meta description שיתווסף באתר החדש = רווח נטו של 100%, לא החלפה. זאת הזדמנות עצומה — האתר החדש יקבל בבת אחת את כל מה ש־Google דורש ב־2026 (LegalService, Article, FAQPage, BreadcrumbList, Person + Organization), ולא יצטרך להיאבק לשמור פיצ'רים קיימים.
החלטה מס׳ 9 · פיד פייסבוק
איך מציגים פוסטים מפייסבוק באתר החדש?

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

חלופה — להמשיך עם SocialKit
וידג'ט בלבד
אוטומטי לחלוטין
מוכר לאלון
זול — חינם עד כמה שקלים
לא מאונדקס בגוגל
תלות בצד שלישי
פייסבוק מצמצמת הרשאות API בהדרגה
המומלצת
N8N → סניטי (כבר רץ אצלך)
אוטומטי לחלוטין
מאונדקס בגוגל וב-AEO
0 דולר עלות נוספת
התוכן נשמר לתמיד גם אם פייסבוק תחסום בעתיד
הקמה חד-פעמית של 2-3 שעות עם Facebook Developer App
ארבע אופציות מלאות שנשקלו:
אופציהעלות חודשיתהאם מאונדקסמורכבות
SocialKit widget (כמו היום) $0-9 ❌ לא קלה
SocialKit Pro API + N8N → סניטי $25 ✅ כן בינונית
N8N ישיר → פייסבוק → סניטי $0 ✅ כן בינונית-גבוהה
הזנה ידנית לסניטי $0 ✅ כן אלון משקיע זמן
החלטה (ממתינה לאישור): N8N ישיר. אתה כבר משתמש ב-N8N על שרת קיים, אין עלות נוספת, התוכן מאונדקס בגוגל וב-AEO, ושומרים על העיצוב שאלון אהב. אם בעתיד פייסבוק תחסום API — הפוסטים שכבר באתר נשארים. הקמה חד-פעמית של 2-3 שעות, תחזוקה אפסית. אם ההקמה מורכבת מדי — אופציה 2 (SocialKit Pro + N8N) נותנת אותו תוצר ב-25 דולר לחודש בתמורה לפחות עבודה.