2026-07-05 3 دقیقه مطالعه

به گزارش ساخت خوش آمدید: اینجا واقعاً چه چیزی منتشر می‌کنیم

چرا اوربیتال به‌جای وبلاگ عمومی، یک گزارش ساخت عمومی منتشر می‌کند، اولین جلسه‌های ساخت دقیقاً چه چیزی تحویل دادند، و چک‌لیستی که می‌توانید همین امروز برای مهاجرت SSR خودتان استفاده کنید.

وضعیت واقعی

بیشتر وبلاگ‌های استودیوهای طراحی، تبلیغاتی هستند که لباس وبلاگ پوشیده‌اند — «۵ دلیل برای انتخاب ما»، بدون تاریخ، بدون عددی که واقعاً بشود راستی‌آزمایی کرد. ما این را نمی‌خواستیم؛ به‌جای نوشتن درباره اینکه چقدر خوبیم، گزارش ساخت دقیقاً منتشر می‌کند چه چیزی ساختیم، چه زمانی، و چه هزینه یا بهبودی داشت. اگر ادعایی را نتوانیم به چیزی در همین کدبیس ردیابی کنیم، در پست جایی ندارد.

چه کاری انجام دادیم

چهار جلسه ساخت اخیر، این سایت را از یک اپلیکیشن تک‌صفحه‌ای چهار-صفحه‌ای سمت کاربر، به یک پلتفرم رندرشده روی سرور تبدیل کرد: SSR کامل با سئو و اسکیمای اختصاصی هر صفحه، فرم تماس واقعی متصل به پایگاه‌داده D1 با محافظت از اسپم Turnstile و امتیازدهی سرنخ، مسیر رزرو تماس روی Cal.com، و چت زنده‌ای که روی API کلود اجرا می‌شود. تک‌تک این صفحات داده‌محور هستند — چهار حوزه خدماتی، ده صفحه صنعت و چهارده صفحه محصول گردش‌کار عامل، همه از فایل‌های محتوایی تایپ‌شده رندر می‌شوند، نه HTML دستی کپی‌شده — یعنی افزودن یک مورد جدید، تغییر داده است، نه ساخت یک قالب تازه.

عدد این پست

ده صنعت، چهارده گردش‌کار عامل، چهار حوزه پلتفرمی — هرکدام یک صفحه زنده که همین حالا می‌توانید ببینید، نه یک ماکاپ. این معیار هر چیزی است که اینجا منتشر می‌شود: اگر روی سایت است، واقعی است و کار می‌کند.

این را بردارید و استفاده کنید

چک‌لیست دقیقی که برای مهاجرت یک اپلیکیشن تک‌صفحه‌ای ری‌اکت به صفحات رندرشده روی سرور با سئوی واقعی استفاده کردیم، به ترتیب:

  • پیش از دست‌زدن به سئو، مطمئن شوید حالت SSR فریم‌ورک شما واقعاً هر مسیر را روی سرور رندر می‌کند — با view-source بررسی کنید، نه ابزار توسعه‌دهنده مرورگر (که DOM هیدرات‌شده را نشان می‌دهد و درباره آنچه خزنده واقعاً می‌بیند، دروغ می‌گوید).
  • یک تابع کمکی مثل buildMeta() بسازید — عنوان، توضیحات، لینک کنونیکال، hreflang، Open Graph — که هر مسیر از طریق meta() خودش آن را صدا بزند. نوشتن دستی متا برای هر صفحه، دقیقاً همان دلیلی است که نیمی از آن‌ها شش ماه بعد قدیمی و نادرست می‌مانند.
  • هرگز عددی منتشر نکنید که نمی‌توانید در کد خودتان پیدایش کنید. اگر عددی از داده واقعی محاسبه نشده، آن عدد نیست، یک حدس با لباس مبدل است.
  • توکن‌های ضدهرزنامه را سمت سرور بررسی کنید، نه فقط سمت کاربر. بررسی فقط سمت کاربر، یک پیشنهاد است، نه یک دروازه واقعی.
  • sitemap.xml و robots.txt را همراه همان مرحله SSR منتشر کنید — وقتی رندر روی سرور کار می‌کند، این دو تقریباً رایگان هستند و دلیلی ندارد صفحات قابل‌ایندکس را بدون آن‌ها منتشر کنید.
  • امتیازدهی سرنخ یا مشترک را از یک تابع واحد عبور دهید، نه محاسبات پراکنده داخل هر هندلر فرم. قوانین امتیازدهی، پیش از هر چیز دیگری در این فهرست تغییر خواهد کرد.

بعدش چه می‌شود

پست‌های تازه تقریباً هفتگی اینجا منتشر می‌شوند — عددهای واقعی، تصمیم‌های معماری واقعی، و گاهی «این خراب شد و این‌طور درستش کردیم». اگر بین یک ساخت قالب‌محور و چیزی کاملاً مهندسی‌شده برای بار کاری واقعی خودتان مردد هستید، ببینید چطور به ساخت SaaS و پلتفرم‌های اختصاصی نگاه می‌کنیم — و اگر پیش از هر تعهدی می‌خواهید نسخه فشرده طرز فکرمان درباره پلتفرم‌های خودگردان را داشته باشید، راهنمای پلتفرم خودگردان را دریافت کنید.

چک‌لیستی برای پروژه خودتان می‌خواهید؟

بگویید روی چه چیزی کار می‌کنید — ظرف ۴۸ ساعت با یک طرح اولیه معماری پاسخ می‌دهیم.

پست بعدی: چطور یک فروشگاه وردپرسی را بدون از دست دادن رتبه گوگل بازطراحی کنیم