CDN و سئو؛ تنظیم کش، هدرها و خطاهای Edge

CDN می‌تواند زمان پاسخ را کم کند، فشار سرور مبدا را پایین بیاورد و دسترسی کاربران مناطق مختلف را پایدارتر کند. همین لایه اگر نادرست تنظیم شود، نسخه قدیمی صفحه، کد وضعیت اشتباه، چالش امنیتی یا هدر حذف‌شده را به گوگل تحویل می‌دهد. در این حالت مشکل از محتوای صفحه نیست؛ پاسخ Edge مانع خزش یا برداشت درست موتور جست‌وجو شده است.

این راهنما روی تصمیم‌های فنی CDN تمرکز دارد: چه چیزی کش شود، TTL هر نوع فایل چقدر باشد، Cache-Control و ETag چگونه تنظیم شوند، Cache Key چه اجزایی داشته باشد و WAF در زمان محدودسازی ربات چه پاسخی برگرداند. هدف، ساخت تنظیماتی است که هم سرعت و پایداری بدهد و هم نسخه قابل ایندکس صفحه را تغییر ندهد.

CDN در مسیر خزش و ایندکس چه نقشی دارد؟

شبکه توزیع محتوا میان درخواست‌کننده و سرور مبدا قرار می‌گیرد. درخواست گوگل نیز ابتدا به Edge می‌رسد و همان‌جا ممکن است از کش پاسخ بگیرد، به مبدا فرستاده شود یا با قانون امنیتی متوقف شود. بنابراین موتور جست‌وجو رفتار CDN را به‌عنوان رفتار واقعی سایت می‌بیند، نه یک واسطه نامرئی.

CDN خودش عامل رتبه‌بندی مستقل نیست. اثر آن از دسترسی پایدار، زمان پاسخ، تحویل منابع لازم و جلوگیری از خطای موقت می‌آید. اگر Edge پاسخ کامل و یکسان با مبدا بدهد، به تجربه کاربر و کارایی کمک می‌کند. اگر HTML یا هدرهای مهم را عوض کند، همان بهینه‌سازی سرعت می‌تواند مسئله ایندکس بسازد.

برای تشخیص اینکه مشکل در مبدا، Edge یا مرورگر رخ می‌دهد، یک بررسی سئو سایت باید پاسخ هر سه لایه را جدا ببیند. مقایسه فقط با بازکردن صفحه در مرورگر کافی نیست؛ هدرها، کد وضعیت، بدنه HTML و نتیجه درخواست از چند موقعیت باید ثبت شوند.

مرز این مقاله با راهنمای سرعت روشن است. اینجا درباره اندازه تصویر، CSS بحرانی یا کاهش جاوااسکریپت بحث اصلی نداریم. تمرکز روی سیاست تحویل است: نسخه صحیح محتوا به چه درخواست‌هایی داده می‌شود، چه مدت معتبر می‌ماند، چه رویدادی آن را تازه می‌کند و زمان خطا چه پاسخی از Edge خارج می‌شود.

سه لایه کش را از یکدیگر جدا کنید

کش مرورگر، کش CDN و کش سرور مبدا یک تنظیم مشترک نیستند. هر لایه مخاطب، زمان نگهداری و روش پاک‌سازی خودش را دارد. ممکن است CDN نسخه تازه را داشته باشد اما مرورگر کاربر هنوز فایل قدیمی را نمایش دهد؛ یا Edge نسخه منقضی را نگه دارد، در حالی که مبدا صفحه درست را ساخته است.

Browser Cache با max-age برای یک کاربر کار می‌کند و purge در CDN معمولاً آن را پاک نمی‌کند. Edge Cache پاسخ مشترک را نزدیک کاربر نگه می‌دارد و می‌تواند با s-maxage یا قانون CDN زمان متفاوتی داشته باشد. Origin Cache نیز خروجی CMS، دیتابیس یا رندر را ذخیره می‌کند و باید هنگام ویرایش محتوا بی‌اعتبار شود.

اگر هدف اصلی کاهش زمان بارگذاری است، مقاله افزایش سرعت سایت مسیر فایل‌های سنگین و Core Web Vitals را پوشش می‌دهد. در تنظیم CDN برای سئو، اول مشخص کنید هر پاسخ عمومی است یا شخصی، نسخه‌های آن با چه کلیدی جدا می‌شوند و چه سیگنالی کش را تازه می‌کند.

نقشه کش را برای نوع منبع بنویسید. HTML عمومی، صفحه ورود، API شخصی، تصویر نسخه‌دار، CSS، فایل PDF و robots.txt نباید یک قاعده داشته باشند. کنار هر مورد، قابلیت ذخیره، TTL مرورگر، TTL Edge، روش revalidation و رویداد purge را ثبت کنید تا تنظیم در داشبورد CDN به حدس وابسته نباشد.

Cache-Control را بر اساس نوع پاسخ بنویسید

Cache-Control باید روشن کند پاسخ کجا ذخیره شود، چه مدت تازه بماند و پس از انقضا چگونه اعتبارسنجی شود. یک هدر عمومی برای همه مسیرها خطرناک است. HTML عمومی می‌تواند در CDN کش شود، اما صفحه دارای اطلاعات حساب نباید وارد کش مشترک شود. تفاوت public، private و no-store را در مبدا مشخص کنید.

max-age عمر نسخه در مرورگر را تعیین می‌کند و s-maxage می‌تواند عمر کش مشترک را جدا کند. no-cache به معنای ممنوعیت ذخیره نیست؛ پاسخ می‌تواند ذخیره شود ولی پیش از استفاده دوباره باید اعتبارسنجی شود. no-store برای داده‌ای است که هیچ کشی نباید آن را نگه دارد. این دو دستور را جای هم استفاده نکنید.

stale-while-revalidate اجازه می‌دهد Edge برای مدتی پاسخ قدیمی را بدهد و نسخه تازه را در پس‌زمینه بگیرد. stale-if-error نیز می‌تواند هنگام خطای مبدا نسخه قبلی را حفظ کند. این رفتار برای صفحه عمومی مفید است، ولی زمان آن باید محدود و با حساسیت محتوا هماهنگ باشد؛ قیمت، موجودی یا هشدار قانونی تحمل نسخه قدیمی کمتری دارند.

همیشه پاسخ نهایی CDN را بررسی کنید، زیرا Cache Rule می‌تواند هدر مبدا را تغییر دهد. وجود Cache-Control در برنامه تضمین نمی‌کند همان مقدار به کاربر می‌رسد. مسیر تست باید هدر مبدا و Edge را کنار هم بگذارد و برای درخواست ناشناس، واردشده و دارای cookie نتیجه جدا ثبت کند.

ETag و Last-Modified را برای خزش شرطی فعال کنید

اعتبارسنج‌های HTTP کمک می‌کنند خزنده برای محتوای تغییرنکرده بدنه کامل را دوباره نگیرد. سرور ETag یا Last-Modified می‌دهد و درخواست بعدی می‌تواند If-None-Match یا If-Modified-Since داشته باشد. اگر نسخه همان است، پاسخ ۳۰۴ بدون بدنه کافی است و منابع سرور و پهنای باند کمتر مصرف می‌شوند.

گوگل پشتیبانی از ETag و Last-Modified را مستند کرده و ETag را به دلیل خطای کمتر توصیه می‌کند. مقدار ETag باید نماینده نسخه واقعی همان خروجی باشد. اگر به‌صورت تصادفی در هر درخواست عوض شود، revalidation هیچ‌گاه ۳۰۴ نمی‌دهد. اگر پس از تغییر محتوا ثابت بماند، نسخه قدیمی ممکن است معتبر فرض شود.

برای درک رابطه این پاسخ‌ها با ایندکس و خطا، راهنمای کدهای وضعیت HTTP در سئو را کنار تنظیم CDN بخوانید. کد ۳۰۴ پاسخ شکست‌خورده نیست؛ فقط زمانی معتبر است که درخواست شرطی قبلی و نسخه قابل استفاده در کش وجود داشته باشد.

Last-Modified باید تاریخ واقعی آخرین تغییر محتوای قابل مشاهده باشد، نه زمان اجرای هر درخواست یا زمان پاک‌شدن کش. اگر هر بار اکنون را برگرداند، خزنده تصور می‌کند صفحه دائماً تغییر می‌کند. در سایت پویا، بهتر است نسخه محتوا یا زمان ویرایش رکورد اصلی مبنا باشد و CDN این هدر را حذف نکند.

Cache Key را کوچک، پایدار و امن طراحی کنید

Cache Key تعیین می‌کند کدام درخواست‌ها یک پاسخ مشترک می‌گیرند. URL کامل معمولاً پایه آن است، اما query string، cookie، زبان، دستگاه یا header نیز ممکن است نسخه جدا بسازند. کلید بسیار گسترده Hit Rate را کم می‌کند و کلید بیش‌ازحد ساده می‌تواند پاسخ اشتباه را میان کاربران یا نسخه‌های محتوا مشترک کند.

پارامترهای بازاریابی مانند UTM معمولاً نباید نسخه HTML جدا بسازند، مگر برنامه واقعاً محتوا را بر اساس آن تغییر دهد. در مقابل، پارامتری که محصول، زبان یا صفحه‌بندی را عوض می‌کند نباید بی‌دلیل حذف شود. تصمیم هر پارامتر باید با رفتار canonical و ایندکس همان URL هماهنگ باشد.

برای تعیین اینکه کدام URL پارامتردار ارزش ایندکس دارد، راهنمای پارامترهای URL در سئو را بررسی کنید. Cache Key و canonical دو ابزار متفاوت‌اند، اما تناقضشان مشکل می‌سازد: CDN نباید چند محتوای متفاوت را زیر کلیدی یکی کند که صفحه‌ها canonical مستقل دارند.

cookie کاربر، authorization و headerهای با تنوع بالا را با احتیاط وارد کلید کنید. اگر پاسخ شخصی است، bypass کش مشترک معمولاً امن‌تر است. اگر زبان یا دستگاه واقعاً خروجی متفاوت دارد، Vary و کلید CDN باید همان تفاوت را بشناسند. هر نسخه اضافه، هزینه ذخیره و احتمال باقی‌ماندن نسخه قدیمی را بالا می‌برد.

برای HTML و فایل‌های نسخه‌دار TTL متفاوت بگذارید

فایل دارای hash در نام را می‌توان مدت طولانی نگه داشت، زیرا تغییر محتوا URL تازه می‌سازد. HTML چنین تضمینی ندارد و ویرایش عنوان، canonical یا متن باید در همان نشانی دیده شود. TTL طولانی HTML بدون webhook یا purge دقیق، مهم‌ترین علت نمایش نسخه قدیمی پس از انتشار است.

برای HTML عمومی TTL کوتاه‌تر و revalidation در نظر بگیرید. هنگام انتشار، فقط URLهای اثرپذیر را purge کنید: خود صفحه، صفحه دسته، صفحه اصلی یا sitemap در صورت تغییر. پاک‌کردن کل کش بعد از هر ویرایش آسان است، اما موج درخواست به مبدا می‌سازد و خطای هم‌زمان را بیشتر می‌کند.

در معماری جداشده، مقاله سئو Headless CMS نشان می‌دهد انتشار چگونه به بازتولید صفحه و API وصل می‌شود. CDN باید آخرین حلقه همان زنجیره باشد؛ موفقیت CMS به تنهایی ثابت نمی‌کند صفحه جدید در همه نقاط Edge در دسترس قرار گرفته است.

پس از purge، درخواست واقعی بفرستید و header وضعیت کش را ببینید. موفقیت API پاک‌سازی فقط دریافت دستور را تأیید می‌کند. باید مطمئن شوید نسخه قبلی دیگر HIT نیست و سپس نسخه تازه با کد، هدر و HTML درست وارد کش می‌شود. برای Cache Key سفارشی، تمام اجزای کلید در عملیات purge لحاظ شوند.

کد وضعیت Edge باید وضعیت واقعی را نشان دهد

CDN ممکن است هنگام قطع مبدا، محدودیت نرخ، خطای DNS یا زمان انتظار پاسخی متفاوت از برنامه بسازد. موتور جست‌وجو همان کد و بدنه Edge را می‌بیند. خطای موقت باید با ۵۰۳ یا ۴۲۹ روشن اعلام شود، نه صفحه چالش یا متن خطا با کد ۲۰۰ که می‌تواند soft error یا محتوای تکراری بسازد.

۵۰۳ همراه Retry-After برای نگهداری یا اختلال کوتاه مناسب است. ۴۲۹ محدودیت موقت نرخ را نشان می‌دهد. ۴۰۳ برای ممنوعیت واقعی است و استفاده از آن برای کنترل بار گوگل پیام اشتباهی می‌دهد. timeout شبکه نیز از پاسخ ۵۰۳ خطرناک‌تر است، زیرا هیچ نشانه‌ای درباره موقتی‌بودن وضعیت تحویل نمی‌دهد.

اگر صفحه خطا با کد موفق برمی‌گردد، روش تشخیص و اصلاح در مقاله خطای Soft 404 توضیح داده شده است. در CDN نمونه HTML خطا را نیز پایش کنید؛ بعضی سرویس‌ها کد را درست می‌دهند اما صفحه عمومی همه URLها را یکسان می‌کنند و تشخیص دامنه مشکل سخت می‌شود.

نسخه stale می‌تواند در قطعی کوتاه از حذف محتوا جلوگیری کند، اما باید بدانید چه کدهایی آن را فعال می‌کنند و چه مدت ادامه دارد. برای صفحه حساس، ارائه نسخه قدیمی ممکن است بدتر از خطای روشن باشد. سیاست باید با نوع محتوا، الزامات کسب‌وکار و امکان بازیابی مبدا تنظیم شود.

WAF نباید خزنده معتبر را پشت چالش انسانی نگه دارد

قانون امنیتی می‌تواند Googlebot را به دلیل نرخ درخواست، IP مشترک یا رفتار خودکار مسدود کند. اگر Edge صفحه «انسان بودن را تأیید کنید» نشان دهد، خزنده محتوای اصلی را نمی‌بیند. بدتر آنکه برخی چالش‌ها با ۲۰۰ پاسخ می‌دهند و ممکن است همان صفحه میان URLهای زیاد ایندکس یا تکراری تشخیص داده شود.

Googlebot را فقط از روی User-Agent مجاز نکنید، چون قابل جعل است. گوگل روش بررسی IP و reverse DNS را منتشر کرده است و بسیاری از CDNها مجموعه IPهای معتبر را مدیریت می‌کنند. allowlist باید محدود، قابل بازبینی و همراه با لاگ باشد؛ حذف کامل کنترل امنیتی برای هر درخواست با نام Googlebot تصمیم امنی نیست.

تحلیل درخواست‌های واقعی را با آنالیز لاگ سرور برای سئو ادامه دهید. لاگ باید IP، User-Agent، مسیر، نقطه Edge، قانون WAF، کد پاسخ، زمان و cache status را نگه دارد. بدون این داده، افت خزش به حدس میان مبدا و CDN تبدیل می‌شود.

برای محدودسازی اضطراری، ۵۰۳ یا ۴۲۹ موقت و قابل بازگشت بهتر از ۴۰۳، ۴۰۴ یا timeout است. مدت محدودیت را پایش کنید و پس از کاهش بار قاعده را بردارید. ادامه چندروزه پاسخ‌های عدم دسترسی می‌تواند نرخ خزش و حضور URLها در نتایج را تحت تأثیر قرار دهد.

هدرهای سئو و نوع محتوا را در Edge حفظ کنید

CDN علاوه بر بدنه می‌تواند header پاسخ را تغییر دهد. X-Robots-Tag، Content-Type، Location، Vary، Link و سیاست cache باید پس از Ruleهای Edge همان معنای مبدا را حفظ کنند. حذف یا افزودن ناخواسته noindex در header دیده نمی‌شود، اما می‌تواند صفحه را از نتایج خارج کند.

redirect باید Location کامل و کد صحیح داشته باشد. robots.txt باید text/plain و sitemap XML باید نوع محتوای قابل قبول برگرداند. فایل CSS یا JS با HTML صفحه خطا و کد ۲۰۰ می‌تواند رندر را خراب کند. برای هر نوع منبع، Content-Type و نمونه بدنه را در تست خودکار بررسی کنید.

برای ممیزی robots، sitemap، canonical و هدرها از چک‌لیست سئو تکنیکال استفاده کنید. تفاوت CDN این است که هر کنترل باید از بیرون شبکه و روی پاسخ Edge انجام شود؛ نتیجه درخواست مستقیم به IP مبدا فقط برای مقایسه و تشخیص علت کاربرد دارد.

Vary را فقط برای headerهایی بگذارید که واقعاً خروجی را عوض می‌کنند. Vary بسیار گسترده کش را خرد می‌کند و مقدار اشتباه می‌تواند نسخه زبان یا فشرده‌سازی ناسازگار بدهد. اگر HTML موبایل و دسکتاپ یکی است، دستگاه را بی‌دلیل وارد Cache Key نکنید؛ طراحی واکنش‌گرا یک نسخه مشترک می‌خواهد.

تنظیمات CDN را از چند موقعیت و با چند نوع درخواست بیازمایید

یک تست از لپ‌تاپ دفتر فقط یک نقطه Edge، یک شبکه و یک وضعیت cookie را می‌سنجد. خطا ممکن است منطقه‌ای باشد یا فقط درخواست ناشناس و ربات را درگیر کند. آزمون باید از چند موقعیت، با DNS عمومی، IPv4 و در صورت استفاده IPv6 و با User-Agentهای مشخص اجرا شود.

برای هر URL نمونه، دو درخواست پیاپی و یک درخواست پس از purge ثبت کنید. status، Age، Cache-Control، ETag، Last-Modified، Vary، Content-Type، Location و header اختصاصی cache status را ذخیره کنید. بدنه HTML را نیز hash کنید تا پاسخ HIT و MISS از نظر محتوا برابر باشند.

رابطه این آزمون‌ها با ظرفیت خزش در مقاله بودجه خزش توضیح داده شده است. هدف افزایش مصنوعی درخواست گوگل نیست؛ باید پاسخ‌های غیرضروری و خطا کم شوند تا خزنده روی URLهای قابل ایندکس، پاسخ سریع و معتبر دریافت کند.

URL Inspection در Search Console برای مشاهده پاسخ و رندر گوگل مفید است، اما پایش روزانه را جایگزین نمی‌کند. هشدارهای خودکار باید رشد ۵xx، timeout، challenge، کاهش HIT Rate و اختلاف نسخه میان Edgeها را ببینند. نمونه URL و شناسه قانون CDN را داخل هشدار بگذارید تا بررسی مستقیم شروع شود.

تغییر CDN را با rollout و امکان بازگشت اجرا کنید

تغییر DNS، پروکسی، Cache Rule یا WAF می‌تواند کل سایت را هم‌زمان درگیر کند. ابتدا دامنه آزمایشی یا گروه محدودی از مسیرها را وارد CDN کنید و پاسخ را با مبدا مقایسه کنید. سپس درصد یا دامنه پوشش را بالا ببرید. هر مرحله باید معیار توقف و روش rollback روشن داشته باشد.

پیش از جابه‌جایی، TTL رکورد DNS را کاهش دهید و گواهی TLS، redirectهای دامنه، HTTP/2 یا HTTP/3 و اتصال مبدا را آزمایش کنید. IP مبدا را عمومی رها نکنید و health check واقعی بسازید. تغییر CDN نباید هم‌زمان با مهاجرت URL، بازطراحی و تغییر CMS انجام شود؛ تفکیک تغییرها تشخیص خطا را آسان می‌کند.

پس از rollout، چند URL حیاتی، robots.txt و sitemap را از Edgeهای مختلف بررسی کنید. نمودار ۴xx، ۵xx، latency مبدا و تعداد challengeها را با دوره قبل مقایسه کنید. اگر خطا از حد توافق‌شده گذشت، rollback کنید؛ انتظار برای افت Search Console روش کنترل تغییر نیست.

برای هر Rule نام، هدف، مالک و تاریخ بازبینی ثبت کنید. قوانین قدیمی اغلب پس از تغییر CMS یا مسیرها باقی می‌مانند و روی URLهای جدید اثر ناخواسته می‌گذارند. خروجی تنظیمات را نسخه‌بندی کنید تا تغییر قابل مرور باشد و بازگشت فقط به حافظه مدیر پنل وابسته نماند.

چک‌لیست نهایی CDN و سئو را اجرا کنید

نسخه نهایی باید هم سرعت تحویل و هم صحت پاسخ را ثابت کند. بررسی فقط با امتیاز عملکرد یا مشاهده HIT کامل نیست. کد وضعیت، header، نسخه HTML، رفتار خزنده، purge و امنیت باید کنار هم قبول شوند. این چک‌لیست را برای هر محیط و پس از تغییر مهم CDN دوباره اجرا کنید.

• HTML عمومی و پاسخ شخصی قواعد کش جدا دارند.
• TTL مرورگر، Edge و مبدا برای هر نوع منبع ثبت شده است.
• Cache-Control نهایی با مقدار مبدا مقایسه شده است.
• ETag یا Last-Modified با تغییر واقعی محتوا عوض می‌شود.
• Cache Key فقط پارامترها، cookieها و headerهای لازم را شامل می‌شود.
• ویرایش محتوا purge دقیق URLهای اثرپذیر را اجرا می‌کند.
• پاسخ خطای موقت ۵۰۳ یا ۴۲۹ واقعی است و صفحه خطا کد ۲۰۰ ندارد.
• WAF خزنده معتبر را به چالش انسانی نمی‌فرستد.
• X-Robots-Tag، Content-Type، Location و Vary در Edge درست‌اند.
• robots.txt و sitemap با TTL کوتاه و نسخه تازه تحویل می‌شوند.
• آزمون چندمنطقه‌ای تفاوت HIT و MISS را مقایسه می‌کند.
• قانون‌ها نسخه‌بندی، مالک‌گذاری و برای rollback آماده شده‌اند.

پس از اجرا، یک سند عملیاتی کوتاه نگه دارید که مسیر purge، نشانی داشبورد، روش بررسی Googlebot، URLهای آزمون و حد هشدار را مشخص کند. تنظیم درست امروز دائمی نیست؛ تغییر برنامه، cookie، دامنه یا محصول CDN می‌تواند رفتار کش را عوض کند. بازبینی دوره‌ای باید بخشی از انتشار فنی باشد.

جمع‌بندی

CDN زمانی به سئو کمک می‌کند که نسخه درست محتوا را با کد و هدر درست تحویل دهد. HTML، فایل نسخه‌دار و پاسخ شخصی باید سیاست‌های جدا داشته باشند؛ ETag و Last-Modified باید با نسخه واقعی هماهنگ شوند و Cache Key فقط تفاوت‌های ضروری را نگه دارد. WAF نباید خزنده معتبر را پشت challenge ببرد و خطای موقت باید با ۵۰۳ یا ۴۲۹ اعلام شود. پایش چندمنطقه‌ای و purge دقیق، خطای Edge را پیش از افت گسترده خزش آشکار می‌کنند.

سوالات متداول

منابع

• Google Search Central: Crawling December، CDNs and crawling
• Google Search Central: Crawling December، HTTP caching
• Cloudflare Docs: Origin Cache Control