صفحه اصلی با HTTPS باز میشود و کنار آدرس هم هشدار قرمز نمیبینید؛ اما فرم ورود هنوز Cookie بدون Secure میسازد، فایل JavaScript از HTTP میآید، بعضی URLهای قدیمی دو بار Redirect میشوند و گواهی Origin پشت CDN سه روز دیگر منقضی است. چنین سایتی «SSL دارد»، ولی هنوز یک سامانه HTTPS سالم ندارد.
پاسخ کوتاه: HTTPS یعنی HTTP روی TLS؛ ارتباط Browser یا Client تا Endpoint را رمزگذاری میکند، یکپارچگی داده در مسیر را حفظ میکند و هویت Endpoint را با Certificate میسنجد. نتیجه زمانی قابل اتکاست که همه صفحهها و APIها HTTPS باشند، Certificate و Chain درست و قابل تمدید باشند، HTTP مستقیم به URL معادل Redirect شود، Mixed Content وجود نداشته باشد و Canonical، Sitemap، Cookie، HSTS و Monitoring هم هماهنگ شوند.
این راهنما برای مدیر سایت، تیم فنی، DevOps و سئو نوشته شده است تا مهاجرت HTTP به HTTPS را نه بهعنوان نصب یک فایل، بلکه بهعنوان یک تغییر امنیتی و URLمحور با معیار پذیرش، پایش و Rollback مدیریت کنند.
HTTPS چیست و SSL چه نسبتی با TLS دارد؟
HTTPS همان HTTP است که داخل یک کانال TLS منتقل میشود. SSL نام نسل قدیمی این خانواده است؛ SSL ۲ و SSL ۳ ضعفهای جدی دارند و نباید فعال باشند. بااینحال در بازار هنوز عبارتهایی مثل «خرید SSL» یا «نصب SSL» برای Certificate و TLS امروزی استفاده میشود.
| اصطلاح | نقش | برداشت نادرست رایج |
|---|---|---|
| HTTPS | HTTP روی کانال TLS | نام یک نوع Certificate نیست |
| TLS | محرمانگی، یکپارچگی و احراز Endpoint در انتقال | کل امنیت Application را تأمین نمیکند |
| Certificate | پیوند Public key به نامهای مجاز و زنجیره اعتماد | محتوای سایت یا اخلاق کسبوکار را تأیید نمیکند |
| Private key | Secret متناظر با Certificate | نباید برای CA، تیکت یا Git ارسال شود |
| CA | مرجع صدور مورد اعتماد Clientها | مالکیت Domain را با کیفیت محصول یکی نمیکند |
در یک TLS handshake مدرن، Client و Server درباره نسخه و الگوریتمهای سازگار توافق میکنند، Server Certificate و اثبات مالکیت Private key را ارائه میدهد و طرفین کلیدهای Session را بهدست میآورند. جزئیات با TLS version، Cipher suite، Resumption و Client متفاوت است؛ بنابراین توضیح قدیمی «Browser یک کلید متقارن میسازد و با RSA میفرستد» مدل عمومی و دقیقی برای TLS امروزی نیست.
HTTPS دقیقاً از چه چیزی محافظت میکند؟
OWASP سه منفعت اصلی TLS درستپیکربندیشده را Confidentiality، Integrity و Authentication میداند:
- محرمانگی: ناظر مسیر شبکه نباید محتوای Request و Response را بهسادگی بخواند؛
- یکپارچگی: دستکاری Response، تزریق Script یا تغییر داده در مسیر باید آشکار یا ناممکن شود؛
- احراز Server: Client بررسی میکند Certificate برای نام مقصد معتبر و در زنجیرهای مورد اعتماد صادر شده است.
این حفاظت برای فرم ورود، پنل مدیریت، صفحه مقاله، فایل Static و API لازم است. اگر فقط Checkout امن باشد، صفحه HTTP میتواند Session، Redirect یا Script آلودهای بسازد که کاربر را پیش از رسیدن به Checkout هدف بگیرد.
HTTPS چه چیزی را حل نمیکند؟
- آسیبپذیری XSS، SQL injection، Broken access control یا افزونه آلوده؛
- Phishing روی دامنهای دیگر که Certificate معتبر خودش را دارد؛
- سرقت Private key یا Credential از Server و CI/CD؛
- بدافزار روی Device کاربر یا مرورگر/Extension مخرب؛
- افشای داده در Log، Backup، Analytics یا طرف ثالث؛
- کنترل دسترسی، احراز هویت، Rate limit و Fraud detection؛
- صحت ادعای کسبوکار، مجوز، قیمت، ضمانت یا کیفیت محصول.
پس HTTPS یک Control پایه و ضروری است، نه مهر «این سایت امن و قابل اعتماد است». برای لایههای مکمل، راهنمای سیاست امنیتی محتوا و CSP و نقشه راه بودجه امنیت سایت را ببینید.
آیکون قفل، DV، OV و EV چه چیزی را ثابت میکنند؟
Chrome آیکون قفل را با نشان خنثی تنظیمات جایگزین کرد، چون بسیاری از کاربران آن را با «قابل اعتماد بودن سایت» اشتباه میگرفتند. HTTPS فقط امنبودن کانال تا Origin مورد تأیید را نشان میدهد؛ یک سایت فیشینگ هم میتواند برای دامنه خودش Certificate معتبر بگیرد.
| Validation | چه چیزی بررسی میشود؟ | چه چیزی بهتر نمیشود؟ |
|---|---|---|
| DV | کنترل Domain | قدرت Encryption نسبت به Certificate پولی الزاماً کمتر نیست |
| OV | کنترل Domain و اطلاعات Organization طبق فرایند CA | Application از Bug و Fraud مصون نمیشود |
| EV | اعتبارسنجی سازمانی گستردهتر | نوار سبز عمومی یا «بالاترین امنیت» تضمین نمیشود |
انتخاب Validation، Single-domain، SAN یا Wildcard یک تصمیم Scope، عملیات و نیاز سازمانی است. این مقاله روی مهاجرت پروتکل تمرکز دارد؛ جزئیات انتخاب، ACME، Chain، Edge/Origin و تمدید در راهنمای انتخاب و نصب گواهی SSL/TLS آمده است.
تأثیر HTTPS بر سئو؛ سیگنال سبک، Requirement سنگین
Google در سال ۲۰۱۴ HTTPS را یک Ranking signal بسیار سبک معرفی کرد. از این گزاره نباید وعده «با نصب SSL رتبه جهش میکند» ساخت. دلیل عملی مهمتر این است که HTTPS استاندارد پایه Web، امنیت کاربر و پیشنیاز یک زیرساخت URL سالم است.
مهاجرت HTTP→HTTPS یک Site move با تغییر URL محسوب میشود. اگر Redirect، Canonical، Internal link و Sitemap ناسازگار باشند، Google باید چند نسخه را پردازش کند و کاربر با Chain یا خطا روبهرو میشود. ارزش سئویی پروژه بیشتر از یکپارچگی مهاجرت میآید، نه خرید یک برند خاص Certificate.
سه ادعای نادرست را کنار بگذارید
- HTTPS بهتنهایی کیفیت محتوا، Relevance یا Authority را ایجاد نمیکند.
- کاهش Bounce rate یا افزایش Dwell time پس از HTTPS را نباید سیگنال قطعی رتبه فرض کرد؛ ابتدا تعریف Metric، تغییر همزمان و داده خودتان را بررسی کنید.
- DV رایگان و DV پولی میتوانند Encryption همسطحی داشته باشند؛ قیمت، پشتیبانی، Validation، Warranty یا عملیات با قدرت رمزنگاری یکی نیست.
قبل از مهاجرت: Endpoint و URL inventory بسازید
اگر ندانید TLS کجا Terminate میشود، Certificate چه نامهایی را پوشش میدهد و کدام Clientها به کدام Endpoint میرسند، تست Homepage کافی نیست. Inventory حداقل این ستونها را داشته باشد:
| فیلد | نمونه | Owner/Evidence |
|---|---|---|
| Hostname | www، Apex، API، Admin، Media | DNS/Platform owner |
| Endpoint | CDN Edge، Load balancer، Reverse proxy، Origin | Architecture diagram |
| Audience | Browser، App، Partner، Webhook، Bot | Client inventory |
| Certificate scope | SAN، Wildcard، Issuer، Expiry | Certificate inventory |
| Protocol policy | TLS version/Cipher/ALPN | Config و Scan |
| URL variant | HTTP/HTTPS، www/non-www، Slash، Case | Crawl و URL map |
| Dependency | Font، Analytics، Map، Payment، Captcha | Network log/CSP report |
| Renewal path | ACME HTTP-۰۱/DNS-۰۱ یا Provider managed | Runbook و Synthetic test |
برای DNS، CAA، Ownership و تغییر امن رکوردها به راهنمای مدیریت DNS دامنه مراجعه کنید. DNS-۰۱ برای Wildcard مناسب است، اما API token با Scope گسترده روی همان Web server میتواند Blast radius رخداد را زیاد کند.
قرارداد پذیرش HTTPS را قبل از تغییر بنویسید
| Lane | Acceptance نمونه | Evidence |
|---|---|---|
| Transport | Endpointهای Public فقط Protocolهای مجاز و Chain کامل دارند | Scan از چند Client/Region |
| Routing | هر HTTP URL یک Hop به HTTPS معادل میرود | Redirect matrix |
| Content | هیچ Active mixed content یا Form action ناامن نیست | Browser console و Crawl |
| Session | Cookie حساس Secure، HttpOnly و SameSite مناسب دارد | Header test و Journey |
| SEO | Canonical، Hreflang، Sitemap و Internal link همگی HTTPS هستند | Source/Render/Crawl |
| Application | Login، Search، Upload، Checkout، Callback و Webhook سالماند | E2E test |
| Operations | Expiry، Handshake failure و Error budget Alert دارند | Alert drill |
| Recovery | Config rollback بدون بازگشت داده حساس به HTTP آماده است | Rehearsal |
نقشه مهاجرت HTTP به HTTPS
۱. Baseline و Backup قابل بازیابی
URLهای مهم، Status code، Canonical، Sitemap، Robot directives، Templateها، Conversion و Error rate را ثبت کنید. از Config، Database و Certificate metadata نسخه پشتیبان بگیرید و روش بازگردانی را بدانید. Backup بدون Restore test، Plan بازگشت محسوب نمیشود.
۲. TLS را در همه Hopهای لازم فعال کنید
معماری ممکن است Browser→CDN و CDN→Origin دو اتصال جدا داشته باشد. «Flexible» یا ارتباط HTTP پشت CDN میتواند تهدید و خطای Redirect ایجاد کند. Policy Edge→Origin را صریح کنید، نام و Chain Certificate Origin را هم بسنجید و Trust را به شبکه داخلی فرض نکنید.
۳. نسخه HTTPS را پیش از Redirect Smoke test کنید
- Homepage، Article، Category، Login، Admin، Search و ۴۰۴؛
- فرم تماس، OTP، Upload، Payment و Callback؛
- API، Webhook و Clientهای قدیمی؛
- تصویر، Font، CSS، JS، Video و Download؛
- Certificate نام دامنه، Chain، Expiry و Clock؛
- Cache، CDN، WAF، Rate limit و Session affinity.
۴. Redirect معادل و مستقیم بسازید
هر URL قدیمی باید به معادل HTTPS خودش برود، نه همه مسیرها به Homepage. Destination نهایی را در یک Hop هدف بگیرید:
http://example.com/a?ref=x
→ 301 https://example.com/a?ref=xاگر همزمان www، Slash یا Slug را تغییر دهید، احتمال Chain و خطای Mapping بیشتر میشود. Google توصیه میکند تغییرهای بزرگ را در صورت امکان جدا کنید و Server-side permanent redirect به مقصد نهایی بسازید. طراحی Map، تست Query و مدیریت چرخهها در راهنمای ریدایرکت ۳۰۱ و مهاجرت URL آمده است.
۵. مرجعهای داخلی را به HTTPS تبدیل کنید
Redirect برای Backward compatibility است، نه برای Navigation روزمره سایت. این موارد را مستقیم به HTTPS تغییر دهید:
- Linkهای Content، Menu، Breadcrumb، Pagination و Feed؛
srcوsrcsetتصویر، Script، Stylesheet، Font و iframe؛- Form action، API base URL، AJAX و WebSocket؛
- Open Graph، Structured data، Manifest و Email template؛
- Redirect URIهای OAuth، Callback درگاه، Webhook و App deep link؛
- لینکهای QR، پیامک و کمپین پرترافیک در کنترل شما.
Mixed Content؛ صفحه امن با Dependency ناامن
Mixed Content زمانی رخ میدهد که Context امن HTTPS منبعی را با HTTP درخواست کند. Browser ممکن است بعضی Requestها را Upgrade و بعضی Active contentها را Block کند؛ روی رفتار خودکار Browser بهعنوان Fix تکیه نکنید.
| منبع | ریسک/نشانه | اصلاح |
|---|---|---|
| Script/CSS/iframe | Block، شکست Layout یا امکان دستکاری | HTTPS معتبر یا حذف/جایگزینی Provider |
| Image/Audio/Video | Upgrade/Warning/Failure وابسته به Browser | URL و Host امن، Crawl Asset |
| Font | Fallback، CORS یا Layout shift | HTTPS، CORS و Cache policy صحیح |
| Form action | ارسال داده به HTTP | Endpoint HTTPS و E2E test |
| Download | Insecure download یا هشدار | Asset HTTPS و Content integrity |
| Third party | Provider قدیمی یا Redirect پنهان | قرارداد، جایگزین و Failure mode |
Browser Console فقط صفحه بازشده را نشان میدهد. Crawl در سطح Template، جستوجوی Database/Theme و مشاهده Network روی Stateهای Login/Error/Checkout را نیز انجام دهید. برای مهاجرت تدریجی میتوان CSP Report-Only یا upgrade-insecure-requests را ارزیابی کرد، اما آنها جای اصلاح Source و Dependency را نمیگیرند.
Canonical، Sitemap و سیگنالهای SEO پس از مهاجرت
همه سیگنالها باید روی نسخه HTTPS نهایی همجهت شوند:
- هر صفحه HTTPS یک Self-canonical درست دارد؛
- Hreflang و Alternate به URLهای HTTPS و Reciprocal اشاره میکنند؛
- XML Sitemap فقط URL نهایی ۲۰۰ دارد و مجدد Submit میشود؛
- robots.txt روی Host امن در دسترس است و URLهای جدید را ناخواسته Block نمیکند؛
- Meta robots یا Header از Staging،
noindexباقی نگذاشته است؛ - Structured data، OG URL و Asset URL با نسخه نهایی منطبقاند؛
- Internal link مستقیم است و از Redirect عبور نمیکند؛
- HTTP URL نباید همزمان ۲۰۰، Canonical متناقض یا Sitemap entry داشته باشد.
در Search Console هر Property لازم را Verify، Sitemap جدید را Submit و Indexing، Crawl و Queryهای URL جدید را پایش کنید. نوسان موقت در Site move ممکن است رخ دهد؛ Error، Redirect اشتباه و Capacity را از «نوسان طبیعی» جدا تشخیص دهید. Gate کامل انتشار در چکلیست سئو طراحی سایت تعریف شده است.
HSTS؛ بعد از اثبات HTTPS، نه قبل از آن
Header زیر به Browser میگوید تا مدت تعیینشده فقط HTTPS استفاده کند:
Strict-Transport-Security: max-age=86400HSTS میتواند Downgrade به HTTP و عبور کاربر از Certificate warning را محدود کند، اما Config اشتباه نیز دسترسی را قطع میکند. Rollout ایمن:
- ابتدا HTTPS، Renewal و Subdomainها را بدون HSTS پایدار کنید؛
- با
max-ageکوتاه روی Scope کنترلشده شروع کنید؛ - Error و Certificate rotation را چند چرخه مشاهده کنید؛
- مدت را مرحلهای افزایش دهید؛
includeSubDomainsرا فقط وقتی همه Subdomainهای فعلی و آینده HTTPS هستند اضافه کنید؛- Preload را تصمیمی بلندمدت با Owner، Inventory و Recovery بدانید؛ نوشتن Directive بهتنهایی Submission نیست.
اگر Subdomain قدیمی، سرویس Vendor یا Certificate آینده آماده نیست، includeSubDomains و Preload میتوانند Failure وسیع بسازند. HSTS درمان Expiry یا Chain خراب نیست؛ در آن حالت Browser راه دورزدن هشدار را هم از کاربر میگیرد.
Cookie و Session را پس از HTTPS بازبینی کنید
TLS کانال را رمزگذاری میکند، اما Cookie policy باید مستقل درست باشد:
Secureبرای جلوگیری از ارسال Cookie روی HTTP؛HttpOnlyبرای Cookieهایی که JavaScript نباید بخواند؛SameSiteمتناسب با Login، Payment و Embed واقعی؛- Scope محدود
DomainوPath؛ - Session rotation پس از Login و رویداد حساس؛
- عدم ثبت Token و داده حساس در URL، Log یا Analytics؛
- تست Logout، Expiry، چند Tab، Back button و Retry.
نامناسببودن SameSite میتواند Callback درگاه یا Login خارجی را بشکند؛ خاموشکردن آن برای همه Cookieها راهحل نیست. Journey و Threat model تعیینکنندهاند.
HTTPS برای API، Webhook و درگاه پرداخت
برای API، Redirect از HTTP ممکن است امن یا قابل پشتیبانی نباشد: برخی Clientها Method یا Body را متفاوت مدیریت میکنند و ارسال Secret پیش از Redirect خودش Failure است. Endpoint ناامن API را Fail کنید و Client configuration را مستقیم روی HTTPS قرار دهید.
| Journey | تست ضروری | Failure رایج |
|---|---|---|
| Payment redirect | Return URL، Cookie، State و مبلغ | Loop، Session گمشده یا Host اشتباه |
| Webhook | TLS، Signature، Replay و Retry | Redirect پشتیبانینشده یا Certificate chain ناقص |
| Mobile app | Trust store و نسخههای تحت پشتیبانی | Client قدیمی یا Pin منقضی |
| Partner API | SNI، mTLS در صورت نیاز و Rotation | Certificate/CA جدید در Allowlist نیست |
| WebSocket | wss://، Proxy و Timeout | Upgrade header یا Mixed Content |
Certificate معتبر جای Signature، Idempotency، Authorization و Reconciliation درگاه را نمیگیرد. مسیر پرداخت را روی Sandbox و سپس تراکنش کنترلشده واقعی آزمایش کنید.
WordPress و WooCommerce؛ دامهای رایج HTTPS
homeوsiteurlرا با معماری نهایی هماهنگ کنید؛ تغییر اشتباه میتواند Admin را از دسترس خارج کند.- اگر TLS پشت Proxy/CDN خاتمه مییابد، Scheme واقعی را با Header مورد اعتماد و تنظیم Server تشخیص دهید؛ اعتماد کور به Header قابل جعل نکنید.
- Theme، Page builder، Custom field، Widget، Menu و Serialized data را برای HTTP hardcode بررسی کنید؛ Search/replace خام میتواند Serialization را خراب کند.
- Cache صفحه، Object cache، CDN cache و Browser cache را با ترتیب مشخص Purge کنید.
- REST API،
admin-ajax، Cron، Login، Preview و Media upload را تست کنید. - WooCommerce: Cart، Checkout، My Account، Payment callback، Email و Webhook را جدا Smoke test کنید.
- Plugin «Force SSL» را جای Config صحیح Server، CDN و URLهای داخلی نگذارید؛ Loop و Masking ممکن است ایجاد شود.
ملاحظات عملی برای سایتهای ایرانی
امنیت استاندارد تغییر نمیکند، اما مسیر شبکه و Integrationها روی Failure اثر دارند:
- Handshake و Certificate chain را از چند شبکه و اپراتور داخل ایران و در صورت داشتن مخاطب خارجی، بیرون ایران تست کنید؛
- CDN داخلی/خارجی، WAF و Origin را جدا ببینید؛ سالمبودن Edge، Expiry Origin را پنهان نکند؛
- درگاه، پیامک، نقشه، Captcha، Font و Analytics را برای HTTPS، Timeout و Fallback واقعی بسنجید؛
- Clock/NTP Server درست باشد؛ اختلاف زمان میتواند اعتبار Certificate، Token و Log correlation را خراب کند؛
- اگر ACME یا Provider از یک مسیر شبکه موقتاً قابل دسترس نیست، Renewal باید زودتر، خودکار، Retryدار و Alertدار باشد؛
- DNS API token، پنل Registrar و حساب CDN را با MFA، حداقل دسترسی و Recovery code محافظت کنید؛
- نسخه Clientهای واقعاً پشتیبانیشده را از Log و Analytics بسنجید؛ Protocol ضعیف را فقط با حدس «کاربر قدیمی» نگه ندارید.
آیا HTTPS سایت را کند میکند؟
TLS هزینه Handshake و رمزنگاری دارد، اما نتیجه واقعی به Connection reuse، TLS version، HTTP/۲ یا HTTP/۳، Session resumption، فاصله شبکه، CDN و Application بستگی دارد. از ادعای عمومی «SSL سرعت را کم/زیاد میکند» پرهیز کنید.
Baseline را با Cache سرد و گرم، موبایل میانرده، شبکههای هدف و Journey واقعی بگیرید. Redirect اولیه HTTP→HTTPS یک Round trip اضافه میکند؛ Internal link مستقیم و HSTS بعد از Rollout میتوانند آن مسیر اضافی را برای مراجعههای بعدی کم کنند. Certificate chain اضافی، OCSP behavior یا Edge دور نیز قابل اندازهگیریاند. روش Budget و Field/Lab در راهنمای سرعت سایت، UX و سئو آمده است.
مانیتورینگ Certificate و HTTPS
داشتن Auto-renew کافی نیست؛ باید ثابت کنید Renewal و Deployment کار میکنند. Dashboard/Alert حداقل این موارد را پوشش دهد:
| Signal | پرسش عملیاتی | Alert/Action |
|---|---|---|
| Days to expiry | Edge و Origin هرکدام چقدر فرصت دارند؟ | چند آستانه با Escalation |
| Renewal job | آخرین اجرا/صدور موفق چه زمانی بود؟ | Failure و عدم اجرای Job |
| Deployed fingerprint | Certificate جدید واقعاً روی همه Nodeهاست؟ | اختلاف Region/Node |
| Handshake error | Client، SNI، Chain یا Protocol مشکل دارد؟ | Spike بر Host/Region/Client |
| HTTP leakage | چه URLهایی هنوز ۲۰۰ HTTP یا Link ناامن دارند؟ | Crawl دورهای |
| Mixed content/CSP report | Dependency جدید ناامن اضافه شده؟ | Template/Release owner |
| Redirect quality | Chain، Loop یا مقصد نامرتبط داریم؟ | Regression test |
| Critical journey | Login/Payment/API از دید کاربر سالم است؟ | Synthetic + Outcome |
Alert را به Runbook، Owner و مسیر Escalation متصل کنید. فقط ایمیل عمومی که تعطیلات خوانده نمیشود Control نیست. طراحی Probe و SLO در راهنمای مانیتورینگ آپتایم توضیح داده شده است.
Runbook خطای HTTPS
| نشانه | بررسی سریع | اقدام کمریسک |
|---|---|---|
| Certificate expired | Edge یا Origin؟ Renewal یا Deploy؟ | صدور/استقرار از Runbook و بررسی همه Nodeها |
| Name mismatch | SNI، SAN و DNS مقصد | اصلاح Routing/Certificate؛ نه خاموشکردن Validation |
| Unknown issuer | Intermediate chain و Trust store Client | ارائه Chain صحیح و تست Clientهای هدف |
| Redirect loop | Proxy scheme header و Ruleهای چندلایه | یک Owner برای Redirect و حذف Rule متعارض |
| Mixed content | Console، Network و Source | اصلاح URL/Provider و Purge cache |
| فقط برخی کاربران | Region، ISP، IPv4/IPv6، Client و CDN node | Segment evidence پیش از Rollback |
| Payment callback fail | Allowlist، Chain، Redirect، Method و Cookie | Failover/Provider escalation و Reconciliation |
با HSTS فعال، بازگشت عمومی به HTTP راه Recovery نیست و امنیت کاربر را هم تضعیف میکند. Rollback معمولاً باید Config، Certificate deployment، CDN route یا Release Application را اصلاح کند و HTTPS را حفظ کند.
ماتریس QA مهاجرت HTTPS
| محور | نمونه تست |
|---|---|
| URL | HTTP/HTTPS × www/non-www × Slash × Query × Unicode path |
| Template | Home، Article، Archive، Search، ۴۰۴، Login، Checkout |
| State | Anonymous، Authenticated، Error، Retry، Cached، Logged-out |
| Client | Browser اصلی، Mobile app، Bot، Partner، Webhook |
| Network | اپراتورهای هدف، CDN region، IPv4/IPv6، Slow/unstable |
| Transport | TLS version، SNI، Chain، Hostname، Expiry، Resumption |
| Security | HSTS، Cookie، Mixed content، CSP، Redirect downgrade |
| SEO | ۲۰۰/۳۰۱، Canonical، Hreflang، Sitemap، Robots، Internal link |
| Business | Lead، Login، Payment، Callback، Email، Webhook |
همه ترکیبها را Exhaustive اجرا نکنید؛ براساس ریسک، سهم ترافیک و Journey حیاتی Pairwise/Representative انتخاب کنید. اما URL variant و Payment/Login را صرفاً با نگاهکردن به Homepage تأیید نکنید.
برنامه ۳۰روزه اجرای HTTPS
| بازه | کار | خروجی |
|---|---|---|
| روز ۱ تا ۵ | Inventory دامنه/Endpoint/Client/Dependency و Baseline | Scope، Owner، Risk و URL map |
| روز ۶ تا ۱۰ | Certificate/Chain، Edge-Origin و HTTPS staging | Transport acceptance evidence |
| روز ۱۱ تا ۱۵ | رفع Mixed Content، URL داخلی، Cookie و Integration | Release candidate بدون Leakage |
| روز ۱۶ تا ۲۰ | Redirect، Canonical/Sitemap/Robots و Pilot | Redirect/SEO matrix پاسشده |
| روز ۲۱ تا ۲۵ | Rollout، Smoke/E2E، Search Console و پایش | Evidence و Incident watch |
| روز ۲۶ تا ۳۰ | HSTS تدریجی، Renewal drill و Retrospective | Runbook، Alerts و Backlog |
چکلیست نهایی HTTPS
- همه Hostnameها، Endpointها، Clientها و Dependencyها Owner دارند.
- SSL قدیمی غیرفعال و TLS/Cipher policy با Clientهای هدف آزموده شده است.
- Certificate نام درست، Chain کامل، Private key محافظتشده و Renewal خودکار دارد.
- Edge و Origin هر دو طبق Threat model رمزگذاری و پایش میشوند.
- هر HTTP URL در یک Hop به HTTPS معادل میرود و Query لازم حفظ میشود.
- Internal link، Asset، Form action، API، WebSocket و Third party مستقیم HTTPS هستند.
- Mixed Content روی Template و Stateهای حیاتی صفر است.
- Canonical، Hreflang، Sitemap، Robots، Schema و OG روی URL نهایی همجهتاند.
- Cookieهای Session ویژگیهای Secure/HttpOnly/SameSite و Scope مناسب دارند.
- HSTS مرحلهای و پس از آمادگی Subdomain/Renewal فعال شده است.
- WordPress cache، Proxy scheme، REST/Admin و WooCommerce Journey تست شدهاند.
- Expiry، Renewal، Fingerprint، Handshake، Redirect و Journey Alert دارند.
- Runbook برای Expiry، Chain، Name mismatch، Loop و Payment failure تمرین شده است.
- Search Console و Logها برای URL قدیم/جدید، Crawl error و Indexing پایش میشوند.
پرسشهای متداول SSL و HTTPS
آیا SSL رایگان برای سایت و فروشگاه امن است؟
Certificate DV رایگان میتواند همان TLS و قدرت رمزنگاری یک DV پولی را فراهم کند. تفاوت را در Validation، Support، Warranty، Automation و نیاز سازمانی بسنجید. امنیت فروشگاه بیشتر به Config، Renewal، Application، Access control، Payment و Monitoring وابسته است تا رایگان یا پولیبودن نام Certificate.
آیا HTTPS باعث افزایش رتبه گوگل میشود؟
Google HTTPS را یک Ranking signal سبک معرفی کرده است، اما نصب Certificate جای محتوا، Relevance، Internal linking و کیفیت فنی را نمیگیرد. هدف اصلی امنیت و یکپارچگی URL است؛ مهاجرت ناقص با Redirect/Canonical اشتباه میتواند بیش از سیگنال سبک HTTPS مشکل بسازد.
بعد از نصب SSL چرا سایت هنوز Not Secure یا خراب است؟
Certificate ممکن است Expired، برای Host دیگری یا با Chain ناقص باشد؛ صفحه نیز شاید Mixed Content، Form action ناامن یا Redirect loop داشته باشد. Security panel/Console، Certificate details، Response header و Network را روی همان Host و Journey بررسی کنید.
آیا باید HSTS و Preload را فوراً فعال کنیم؟
خیر. ابتدا همه Subdomainها، Renewal، Edge/Origin و Recovery را پایدار کنید؛ سپس با max-age کوتاه شروع و مرحلهای افزایش دهید. includeSubDomains و Preload دامنه اثر گسترده و بلندمدت دارند و بدون Inventory میتوانند سرویس را غیرقابل دسترس کنند.
ریدایرکت HTTP به HTTPS باید ۳۰۱ باشد یا ۳۰۸؟
هر دو Permanent هستند و Google Redirect دائمی Server-side را توصیه میکند. انتخاب به Server و حفظ Method در Clientها بستگی دارد؛ مهمتر این است که مقصد دقیق، مستقیم و بدون Loop باشد. برای API بهتر است Client از ابتدا HTTPS را صدا بزند و Secret را به HTTP نفرستد.
منابع رسمی برای پیادهسازی و ممیزی
- OWASP: Transport Layer Security Cheat Sheet
- OWASP: استقرار و ریسکهای HSTS
- MDN: Mixed Content و رفتار Browser
- Google Search Central: Site move و مهاجرت HTTP به HTTPS
- Google Search Central: HTTPS بهعنوان Ranking signal سبک
- Let’s Encrypt: HTTP-۰۱، DNS-۰۱ و Automation
- Let’s Encrypt: طول عمر Certificate و ضرورت Automation
- Chromium: چرا Lock icon نشانه Trust سایت نیست
پروژه HTTPS وقتی تمام میشود که نهفقط Browser یک صفحه، بلکه تمام URLها، Sessionها، Integrationها، Botها و مسیر Renewal نتیجه درست بدهند. Certificate شروع کار است؛ Evidence عملیاتی، چیزی است که امنیت و سئو را پایدار نگه میدارد.
