سفارش تبلیغ
صبا ویژن

سئو- استفاده از همه شگردها برای بالابردن ترافیک سایت

چرا کسانی که مطالب ما را کپی می کنند بالاتر قرار می گیرند

پاسخ به چند سوال مطرح شده از سوی کاربران

حتما برای شما هم این سوال  پیش آمده که چرا کسانی که مطالب ما را کپی می کنند بالاتر قرار می گیرند

من در پست الگوریتم پاندا گوگل پاسخ ان را داده ام

مثلا کاربر در سایت شما با دیدن مطلب رغبتی به خواندنش نشان ندهد (مثلا انتخاب فونت بد یا قالب افتضاح سایت و یا ...) اما در سایت رقیب همه چیز مهیا شده که کاربر در کنار خواندن مطلبی که با جستجویش وارد سایت شده، مطالب دیگری را هم بخواند و همین یعنی امتیاز در الگوریتم پاندا گوگل  پس چاره کار در این است که به گوگل بفهمانیم که مطلب متعلق به شماست اینطور کاربران همه سایت شما را می بینند و زرق وبرق سایت متخلف در کپی از سایت شما جایگاهی پیدا نمی کند با این مقدمه سوال دوست عزیز را مطرح می کنم

سوال سلام و عرض ادب خدمت شما آقای شیبانی چندی پیش سایت منو از بلاک در آورده بودید که لازمه تو هر ایمیلم ازتون سپاسگذاری کنم .
میخواستم یک موضوع رو باهاتون در میون بذارم.
الان سایت من بخوبی مطالبش ایندکس میشه و دامین تولز سئوی سایتمو 100% نشون میده همچنین بخوبی سایتو آپدیت میکنم اما میخوام دلیل اینو بدونم که چرا مطالبم توی گوگل خیلی پایینتر از مطالب سایت رقبا میاد چطور میتونم این مشکلو حل کنم آیا تغییر قالب تاثیر آنچنانی دارد ؟
ضمنا من موقع بلاک شدن لینکستان سایت رو برداشتم و دیگر هیچ لینکی به سایت دوستانم ندادم خب  دوستان هم لینک منو از سایت هاشون برداشتن آیا ممکنه مشکل فوق بخاطر همین عمل من باشه ؟ 
با تشکر
جواب:سلام
از لطف حضرت عالی کمال تشکر را دارم
من نمی دونم که شما تولید محتوا می کنید و یا کپی
و این خیلی مهم است
اگر کپی از سایت دیگری دارید حتما یک لینک به آن سایت بدهید
لینکی که هیچ شرط و شروطی نداشته باشد مثل (rel=nofollow) و این به گوگل می فهماند که شما حقوق ناشرین را رعایت کرده اید ضمن اینکه اگر کسی از شما به گوگل شاکی شد کاری پیش نمی برد و دردسری برایتان ندارد
اما اگر مطالبتان از خودتان است به هرکس که از شما کپی کرده بدون اینکه به شما لینک سالم داده باشد دوستانه هشدار بدهید که لینک به شما را فراموش کرده
و همینکه او به شما لینک بدهد کافیست (هرچند در این مورد احتمالا گوگل جایگاه شما را برنگرداند چرا که  همینکه چند روز بالاتر از شما بوده باعث شده محبوبیت کسب کند  اما در موارد بعدی باعث می شود که جایگاه خودتان را داشته باشید)
ولی اگر راضی به اینکار نشد با اینکه گفتنش برایم جالب نیست اما چاره ای جز شکایت از او به گوگل ندارید
البته بهتر است سعی کنید او را قانع کنید چرا که با اقدامات گوگل ممکن است  لطمات مادی زیادی از قطع ورودی های گوگل  به متخلف برسد تا ان حد که تصورش را نکند برای اینکار من توضیحاتی در
لینک شکایت کپی مطالب گوگل دادم
شاید به ظاهر وقت گیر باشد ولی با چند روز استمرار بر این کار متخلف خودش می فهمد که ادامه این کار او را همیشه از صحنه جستجوی گوگل خارج می کند

چطور مقادیر فرم با POST را کش کنیم

کمتر پیش میاید که بخواهیم مقادیر ایجاد شده از یک فرم را کش کنیم چرا که معمولا مقادیر فرم دل بخواه تغییر می کند و اکثرا اطلاعات شخصی و محرمانه است

اما گاه پیش میاید که می خواهیم مقادیر کش شود چرا که نه محرمانه است و نه شخصی

در نظر بگیرید پیش بینی آب و هوا را

خوب وقتی آب و هوای امروز تهران 10 درجه بالای صفر اعلام شده اگر  کاربر یکساعت دیگر  هم  در فرم پیش بینی آب و هوا  تهران را انتخاب کرد باز نتیجه همان 10 درجه بالای صفر خواهد بود

همانطور که قبلا گفته شد پروتکل HTTP  طوری نوشته شده که تنها مرورگرها اجازه کش کردن متد GET را دارند

در مواردی که فرم ما با متد post نوشته شده  به روش جاوا اسکریپتی می توان بصورت GET با آن برخورد کرد تا مقادیر را به درستی کش کند

کافیست با استفاده از  پلاگین جیکوئری jquery و ترفند های جاوا اسکریپتی (قرار دادن onsubmit و فرارخوانی کد زیر) فرم را بصورت Post ارسال کنیم

$.get(
    "form.php",
    {param1 : 1, paramX : "abc"},
    function(data) {
       alert("page content: " + data);
    }
);

کدخط بالا  از لینک مقابل برداشته شده است در صورتیکه نیاز به استفاده از این ترفند برای کش کردن فرم با متد POST در صفحات دارید حتما لینک مقابل را ببینید

HTTP GET request in Java


بررسی دقیق Cache-Control در کش شرطی

کلا ما دو روش منطقی برای افزایش سرعت یک صفحه اینترنتی داریم
1- کم کردن تعداد درخواستها از سرور (مثلا با کم کردن عکس ها و کدهای الحاقی جاوا اسکریپت و css ها و...)
2- کم کردن حجم داده هایی که باید از سرور به مرورگر منتقل شود (مثل فشردهسازی محتوا با gzip یا کامپرس کردن عکس ها)
با کش استاتیک یا cache static  ما به هر دو خواسته می رسیم و با کش شرطی  با ETAGS  خواسته دوم  حاصل میشود

اهدافی که ما از  کش کردن محتوا داریم عبارتند از

1- پایین  نگهداشتن لود سرور
2-لود شبکه
3- زمان تاخیر کاربر
به عنوان مثال مرورگر اینترنت اکسپلور برای تاعمل کش با سرور به صورت زیر ارسال هدر دارد
Pragma: no-cache
با این هدر مرورگر به سرور می فهماند که تمایلی به استفاده از کش موجود ندارد و ترجیح می دهد از نسخه سرور استفاده کند (این هدر با ctrl+F5 ایجاد می شود)
If-Modified-Since: datetime
مرورگر منتظر پاسخ سرور است که آیا از این تاریخ فایل تغییر داشته است یا خیر
If-None-Match: etagvalue
مرورگر به سرور اعلام می کند مشخصه فایل(ETAG) که من در اختیار دارم به صورت زیر است اگر نسخه جدیدتری داری اطلاع بده 
هر دو هدر If-Modified-Since یا  If-None-Match حالت کش شرطی را به وجود می آورند 

در حالت کش استاتیک ارسال هدر از هیچ نوع را نداریم 

در حالت شرطی سرور یا مجددا فایل را با کد 200 ارسال می کند و یا تنها هدر 304 را بصورت زیر می فرستد
HTTP/304 Not Modified
حال با این مقدمه برویم سر اصل مبحث یعنی
بررسی دقیق   Cache-Control در کش شرطی
در حالت شرطی ما هدری داریم به نام  Cache-Control
که انتخاب های (یکی یا برخی ) ‌زیر را برای آن داریم
no-store, no-cache, must-revalidate, pre-check, post-check
حالت no-store به معنی این است که مرورگر کش نمی کند
 no-cache به معنی این است که مرورگر کش می کند ولی تغییرات را با  هربار  رفرش جویاست 
must-revalidate به معنی لازم اجرا دانستن سوال از  سرور برای کش است
و اما دو حالت دیگر یعنی  pre-check, post-check ویژه اینترنت اکسپلور هست
post-check یعنی تا این زمان نیازی به استعلام برای تغییر کش نیست
pre-check یعنی تا قبل از این زمان حتما از تغییر نکردن کش مطمئن شو
مثلا اینطور می شود گفت که با کد زیر 
Control: post-check=10; pre-check=120
مکالمه مرورگر با سرور اینگونه است که 
تا ثانیه 10 ام که هیچ مکالمه ای انجام نمی شود و مانند کش استاتیک برخورد می شود
از ثانیه 10 تا 120 برای کش سوال میشود
بعد از ثانیه 120 کش منقضی است و مرورگر وجود آن را نادید می گیرد
با این توضیحات معلوم میشود که pre-check شباهت بسیاری به max-age دارد
با این تفاوت که ie تا زمانیکه به زمان post-check نرسیده باشد از هدر استفاده نمی کند (کش استاتیک)
این دو حتما باید با هم مقدار دهی شوند و در صورتیکه یکی از آنها مقدار دهی نشود خطا می باشد
مقدار داده شده عدد و به معنای ثانیه است مثلا عدد 60 یعنی یک دقیقه
اگر هر دو صفر باشند هیچکدام در نظر گرفته نمی شوند
post-check همیشه باید کوچکتر یا مساوی با  pre-check باشد در غیر اینصورت خطا است
اگر post-check صفر باشد و pre-check  عددی بزرگتر از صفر باشد تنها اتفاقی که می افتد محتوای صفحه دوبار دانلود می شود 
پس اگر می خواهید بدون دلیل صفحه اتان دو بار در مرورگر بار گذاری شود از کد زیر استفاده نمایید
Control: post-check=0; pre-check=1
اما حالت منطقی این است که همیشه به post-check عددی بدهید که موجب دانلود بی دلیل صفحه در هربار نشود مثلا می توانید 10 بدهید

مطلب برداشت آزادی بود از مطلب:

 Internet Explorer"s Cache-Control Extensions


چه وقتهایی نباید محتوای یک صفحه را کش کرد

گفتیم که کش کردن محتوا نقش زیادی در بالا بردن سرعت بارگذاری صفحه دارد اما مواردی هم هست که نباید محتوا را کش کرد

به عبارتی به برخی دلایل و صلاحدیدهای امنیتی نباید خیلی اصرا به کش محتوا داد و در مواردی با تمهیدات لازم را دید(علی الخصوص در مواردی که از CDN استفاده شده است)

به طور خلاصه هر محتوایی ک وابسته به تغییرات زمان است یا وابسته به شرایطی است که در هدرهای HTTP پیش بینی نشده است مانند آی پی درخواست کننده در این موارد نباید محتوا را کش کرد
که شامل
1-اگر محتوای مطالب شما هر 5 دقیقه به روز می شود کلا قید کش را بزنید
 2-  اگر طراحی سایت بگونه ای است که محتوا متناسب با آی پی  شخص درخواست کننده  تغییر می کند محتوا را نباید کش کرد
3- در صورتیکه شرایط خاص در هدر سایت پیش بینی شده است می توان صفحات وابسته به زبان یا agent یا کدینگ فونت را نیز کش کرد  که در اینصورت باید 
Vary: negotiate,accept-language,accept-charset
را داشته باشیم تا بتوان بر اساس زبان یا انکدینگ انتخابی زبان  یا سایر انتخاب های محلی درخواست  کش را به مرورگر داد
چرا که مرورگر ها قادرند بر حسب vary کش را مدیریت کنند
 نکته: Vary: negotiate به معنای وضعیت مذاکره است مثلا ارسال فرم  و امثالهم که مرورگر باید از کش صفحه بپرهیزد

شرایط کش شدن یک صفحه سایت

شاید برایتان پیش آمده باشد که همه تنظیمات را در کش سرور و مرورگر اعمال کرده اید اما آخر هم به یک کش پایدار و مطمئن نرسیده اید

این از اون مواردی است که بقولی به آن فوت کوزه گری می گویند من  ده مورد از آنها را در زیر می اورم و پیدا کردن الباقی را به خودتان وا می گذارم

1- هدر های expire (تاریخ انقضا) و  max-age (طول عمر) modify (زمان آخرین تغییر) توسط سرور ارسال شود

2- پاسخ کد وضعیت HTTP یکی از کدهای  200 ، 203 ، 300 ، 301 و یا 410 را داشته باشد.
3- نوع درخواست باید HTTP GET باشد (و نه PUT یا POST)
4- اگر در درخواست هدرهای مربوط به مجوز یا Authorization وجود داشته باشد پاسخ  کش نخواهد شد
5- اگر در پاسخ سرور هدرهای مربوط به مجوز یا Authorization وجود داشته باشد پاسخ   به شرطی کش خواهد شد که هدر 
Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا  "public"  آورده شود
6- اگر یو-آر-ال  یا URL دارای query string یا پرامترهای متد GET از صفحه HTML باشد  معمولا کش انجام نخواهد شد مگر اینکه علاوه بر هدر Expires  مانند بند  5 هدر Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا  "public"  آورده شود (طبق رفرنس RFC2616  و بخش 13.9 و 13.2.1)
7- اگر پاسخ سرور با کد 200 باشد حداقل یکی از هدرهای  "Etag" یا  "Last-Modified"  یا "Expires" و یا مانند بند  5 هدر Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا  "public"  آورده شود تا عمل کش کردن پاسخ سرور در مروگر انجام شود
8- اگر هدر Cache-Control ارسال شود و یکی از انتخاب ها در آن  "private" باشد کش انجام نخواهد شد مگر بصورت کش استاتیک (که ارزش امنیتی خیلی پایینی دارد و برای داده های مهم اصلا توصیه نمی شود)
9- به همین نرتیب اگر یکی از انتخاب های ما  no-store در     Cache-Control باش کش صورت نخواهد گرفت
10- بالاخره اینکه اگر در هدر Vary پاسخ ارسالی match-all "*" باشد کش صورت نمی گیرد (معمولا User-Agent است که بهتر است Accept-Encoding,User-Agent باشد تا همیشه کش موفقی داشته باشیم)

 


 


چگونه امنیت سایت را بالا ببریم


تصورش را بکنید یک روز وقتی وارد ftp سایتتون می شوید متوجه تغییراتی در ساختار فایلها می شوید 
مثلا فایلی ناخواسته به لیست فایلهایتان اضافه شده و یا تاریخ modify یکی از پوشه ها تون تغییر کرده و خیلی موارد دیگر
خلاصه متوجه حضور ناخوانده در سایتتان می شوید
البته به شکلهای دیگر هم می توان حضور ناخوانده را فهمید مثلا تغییر محتوای صفحات یا ریدایرکت های ناخواسته صفحات، هدرهای ارسالی مشکوک و خیلی موارد دیگر(از جمله جارو جنجالی که بعد پیش خواهد آمد)
شما فقط مشکوک شده اید و اینکه بتوانید تغییر را بیابید شاید روزها طول بکشد 
چرا که ما هم هکر داریم  هم جوجه هکر 
جوجه هکر به کسی می گویند که تا سایتی را هک کرد تو بوق و کرنا می کند که آی من چنین کردم و چنان
اما هکر واقعی مدتها در داخل یک سایت پرسه می زند بدون اینکه کسی از وجودش خبردار شود
فقط ممکن است مرتکب یکی از اشتباهات شمرده شده در بالا شود که بتوان به وجودش پی برد
پس قبول دارید اگر با یک هکر واقعی طرف شوید روزها طول خواهد کشید تا مچش را بگیرید
و در این مدت اگر هکر با شما خصومت داشته باشد از نظر سئو  هر ضربه ای که هکر بخواهد به شما می تواند وارد کند  و اگر در پی منافع مادی باشد می تواند تا مدتها مثل زالو به بدنه سایت شما بچسبد
برای مورد اول
مثلا تغییر هویت صفحات(= کپی رایت )‌و یا انتقال ارزش صفحات با ارزش  به صفحه خودش و... 
و برای مورد دوم:
تغییر فاکتورها، شارژ حساب، دسترسی به اطلاعات مالی کاربران و  بالاخره تغییر موجودی حسابها بصورت جابجا کردن به حساب خودش 
و اینجاست که یک  بک آپ سالم به دردتان می خورد تا ظرف چند ثانیه همه چیز را به حالت اول برگردانید
اما قبل از هر چیز برای گرفتن چنین بک آپی باید مطمئن شوید که فایلهایتان سالم است 
و اینجاست که متدی برای چک مرتب سلامت سیستم  فایلها و دیتابیس نیاز است
بهترین روش از نظر من ثبت etag فایلها  است و  همیشه با بررسی etag فایلها  مثل روغن موتور  از اصل کار مطمئن شوید چرا که  اگر هکر در کار خودش هر چقدر هم مهارت داشته باشد یعنی تا آن حد که حتی اگر قادر باشد با روش هایی (که غیر ممکن نیست) تاریخ تغییر فایلها را به قبل برگرداند تا تغییراتش مشخص نشود اما حریف مقدار etag که توسط اپاچی ساخته می شود و یک کد 128 بیتی هش شده است که براساس سایز،تاریخ،نام فایل و بالاخره شماره اینود فایل ساخته می شود نمی شود 
کافیست شما هرازگاهی مثل مروگر به چک ایتگ ازقبل ذخیره شده با مقدار فعلی بنمایید همین و بس
البته برای این کار یک پکیج براساس  php  باید نوشته شود که etag ها را در دیتابیس ذخیره کند و هر چند وقت مثل چک روغن ماشین ایتگ ها هم چک شود

چگونگی هدرهای شرطی در سیستم کش و پاسخ دهی به آن

اگر فایلهای کش شده مبتنی بر شناسایی بر اساس ETAG باشند هدر شرط برای بررسی کش "If-None-Match" می باشد

اما اگر ما ETAG را غیر فعال کرده باشیم شرط بررسی کش از هدر ارسال شده توسط مرورگر "If-Modified-Since" می باشد

بسته به اینکه کدام هدر از مرورگر ارسال شده باشد پاسخ دریافتی از سرور نیز باید متفاوت باشد

اگر با شرط "If-Modified-Since" کش مرورگر شناخته شد به عبارتی در حالت فعال بودن ETAG در پاسخ آن سرور  اگر کش معتبر باشد هدر 304 یا "304 Not Modified" را می فرستد بدون محتوا (یعنی هیچ خروجی متنی در کار نخواهد بود.) اما اگر مشخص شد که کش ملغی شده در پاسخ هدر 200 با محتوای کامل درخواستی ارسال میشود

ولی با خاموش کردن etag اگر ما بتوانیم ماهیت کش استاتیک را ایجاد کنیم (ارسال هدر expire  مثلا با مود expire در آپاچی ) دیگر مرورگر تا زمان اکسپایر شدن درخواست به مرورگر نمی فرستد

هدرهای شرطی یا مبتنی بر ETAG دو مزیت دارد

1- با تغییر مشخصه فایل خودبخود فایل جدید به مرورگر ارسال می شود

2- پهنای باندی مصرف نمی شود

اما هدرهای استاتیک تنها مزیت دوم را دارند و اگر به هردلیلی فایل تغییر کند نمی توان به مرورگر این را فهماند

ضمنا این موارد را از طریق  تست با ابزار فایرباگ یا کروم  نمی توان بررسی کرد و تنها http://www.webpagetest.org آزمون مطمئنی برای کش و بررسی تفاوتهای گفته شده بین کش شرطی و استاتیک خواهد بود

در مبحث بعدی به این موضوع خواهیم پرداخت که چه چیزهایی را نمی توان کش کرد


سئو در یک کلام

من در این وبلاگ چندین بار سئو را تعریف کردم و یک جورهایی کاربران این وبلاگ به این عادت کرده اند

یادم میاید واحد ترجمه تخصصی داشتم بچه هایی که از ترم قبل اومده بودند(موفق به پاس درس در ترم قبل نشده بودند )  شاکی بودند که چطوره که استاد و رفرنس همونه اما ترجمه آن 180 درجه تغییر کده ما هم به شوخی می گفتیم

خوب علم پیشرفت داره

اما برای من تنها دلیل اینکه هربار سئو را دوباره و با عبارتی متفاوت تعریف می کنم نه به دلیل تغییر تعاربف سئو است بلکه دلیل اصلیش در تجارب کسب شده این جانب در مسیر یادگیری سئو است
با این توضیحات تعریف زیر آخرین تجارب من از سئو است یعنی اگر بخواهم سئو را در یک کلام تعریف کنم 13 دستورالعمل زیر را می آورم
13 دستورالعمل سئو برای بهینه سازی هر سایت
  1. کم کردن تعداد  درخواست از سرور 
  2. استفاده از هاست خوب  و  یک CDN در کنار آن
  3. افزودن هدر های expire برای کش استاتیک
  4. استفاده از کامپوننت فشرده سازی GZIP 
  5. قرار دادن CSS در بالاترین نقطه (داخل تگ HEAD)
  6. انتقال جاوا اسکریپت ها به انتهای کد ها (قبل از بسته شدن BODY) البته خیلی هم روی این قضیه اصرار نکنید مخصوصا برای  جی کوئری
  7. اجتناب از متغییرهای css
  8. استفاده از css و جاوا اسکریپت  بصورت فایل ملحق شده 
  9. پایین آوردن dns lookup
  10. فشرده سازی فایلهای js (حذف کامنت ها، فضاها و خط های خالی و...)
  11. اجتناب از ریدایرکت بی مورد
  12. حذف مطالب و اسکریپت های تکراری
  13. پیکرندی صحیح برای استفاده درست از etags طوریکه مطمئن شویم هر آدرس فایلی یک ایتگ مجزا دارد
و منابع زیر  برای خواندن  توصیه میشود(همه از یک سایت انتخاب شده تا دوگانگی در مطالب دیده نشود)

فعال یا غیر فعال کردن etags یا Entity tags

فعال کردن etag

برای فعال کردن etag نیاز به انجام کاری نیست چرا که با توجه به اهمیت بالای آن در سرعت و به جز ایجاد مشکل در موارد خاص (مثل cdn ها)‌بطور پیش فرض در آپاچی فعال ا

غیرفعال کردن etag

Turn ETags Off  یا خاموش کردن etag

ابتدا باید ببینیم که ETAGS فعال است یا غیر فعال

برای اینکار هدرهای ارسالی را چک نمایید باید مشابه هدر زیر را داشته باشید

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195

حال برای غیرفعال کردن etag کافیست

در آپاچی دو خطر زیر را در.htaccess و در صورت دسترسی به تنظیمات آپاچی در httpd.conf قرار دهید و آپاچی را ری استارت نمایید

Header unset ETag
FileETag None
Header unset Pragma


اگر هم از IIS استفاده می کنید به آدرس زیر بروید
غیر فعال سازی ETAG در IIS

و برای سرور های Lighttpd هم کدخط روبرو را قرار بدهید

static-file.etags = "disable"

از رفرنس های زیر برای درج این مطلب استفاده شد

  1. http://httpd.apache.org/docs/2.0/mod/core.html
  2. http://developer.yahoo.net/blog/archives/2007/07/high_performanc_11.html
  3. http://www.webscalingblog.com/performance/caching-http-headers-last-modified-and-etag.html

کش استاتیک و قابل انطباق

بعد از Keep-Alive که در پست قبل به آن پرداختیم یکی دیگر از موارد حیاتی برای سرعت بخشیدن به بارگذاری صفحات Cache Static است

همانطور که می دانید مزیت بزرگ صفحات html به php در  سرعت آن است 

چرا که صفحات html  هیچ پروسه اضافی برای سرور ندارند و سرور بدون نیاز به انجام محاسبات  صفحه  html برای چاپ به مرورگر می فرستد
اما در صفحات php وضعیت فرق می کند
کارهای زیادی به سرور محول می شود مثل استفاده ازدیتابیس (برای انالیز و تحلیل  و ذخیره و دریافت اطلاعت از mysql ) یا محاسات ریاضی و توابعی که هرکدام پروسه ای برای سرور هستند و در صورت استفاده ناصحیح حتی موجب آورلود شدن cpu هم میشوند
ما که ما در کش استاتیک انجام می دهیم این است که با هربار مراجعه  هر کاربر تمم عملیات php را مجددا انجام نمی دهیم بلکه خروجی آماده شده برای ارسال به مرورگر را در یک صفحه html می ریزیم و تا زمانی که تغییری در آن ایجاد نشده است در مراجعات بعدی بدون هیچ محاسبه ای با ارسال هدر انقضا  و کنترل کش آن را به خورد مرورگر می دهیم
آنچه که کش استاتیک را  ممکن می سازد ارسال هدر های cache-control و expire است
البته دقت داشته باشیم که در حالت عادی نمی توان هدر انقضا (expire) را برای فایلهای غیر اپچپپچ تی ام ال مثل عکس، جاوا اسکریپت، css ، pdf و... ارسال کرد (مگر با استفاده از مود expire در آپاچی)
پارامترهای Cache-Control
max-age=86400
تعیین زمان اعتبار کش که در اینجا 24 ساعت اعلام شده (86400 ثانیه)
public
به معنی تبیعت از وضعیت نرمال کش (البته اگر فایلی در حالت اتوتیکنشن یا دسترسی اعضا  قرار دارد کش نشود)
no-cache
به معنی کش نکردن نمی باشد بلکه به این معنی است که همیشه از سرور اعتبار کش سوال شود و اگر هنوز منقضی نشده بود از کش مرورگ می توان استفاده کرد
must-revalidate
به معنی اطاعت بی چون و چرای مرورگ از سرور برای استفاده یا عدم استفاده از کش (با توجه به هدر ارسال شده از سرور)
proxy-revalidate
همان حالت بالا اما برای ISP ها( هرچند که آی اس پی های ایران از آن تبعیت نمی کنند)