会社情報
採用情報
お問い合わせ
Article

SSL化 SEOとは?初心者にもわかりやすく解説【2025年版】

高田晃太郎
SSL化 SEOとは?初心者にもわかりやすく解説【2025年版】

Chrome UX Reportの最新データでは、主要地域で90%超のページロードがHTTPS化されています2。Googleは2014年からHTTPSをランキングシグナル化し1、2023年には錠前アイコンを段階的に廃止する一方、HTTPページの「保護されていません」などの警告表示は継続しています3。つまり、SSL化は「やるべきか」ではなく「どう実装・運用して検索成果と品質を最大化するか」の課題に変化しています。本稿では、TLS1.3、HSTS、HTTP/2/3を前提に、技術設計・移行手順・コード・ベンチマーク・ROIまで、CTO/エンジニアリーダーが意思決定に使える粒度で整理します。

SSL化とSEOの関係：課題、指標、ビジネス効果

検索評価におけるHTTPSはシグナル単体での影響は限定的ですが、実務では複合効果が重要です。まず、HTTP→HTTPSの恒久的リダイレクトによりURL正規化が強化され、重複URLのクロール負荷が低下します。次に、TLS1.3 + HTTP/2/3は初期接続の往復回数削減と多重化でネットワーク遅延を圧縮し5、TTFBとLCPを安定させます。さらに、HSTSにより混在コンテンツの偶発的発生やダウングレードを防止し4、インデックス品質のブレを抑えます。これらは結果としてクロール効率、Core Web Vitals、ユーザーの信頼（安全性表示）に効き、コンバージョンにも波及します3。

技術側で追うべき指標は、TLSハンドシェイク時間、TTFB、p95レイテンシ、失敗率（4xx/5xx、CERTエラー）、CWV（LCP/FID/CLS）、リダイレクトチェーン長です。SEO側では、インデックスカバレッジ、正規URLの一貫性、クリック数・CTR、混在コンテンツ検出件数、レンダリング失敗（Mobile‑Friendly/Indexing）を定点観測します。ビジネス効果の目安として、実務での導入後3–6か月の中央値は、自然検索クリック+3–8%、CVR+2–5%、離脱率-2–4%が観測レンジです（社内横断集計の参考値であり、公的・学術的な公開研究の値ではありません）。改修規模により差は出ますが、ネットワーク最適化と品質安定化が複合的に効いています。

推奨アーキテクチャと技術仕様（2025年版）

外部CDN/ALBのマネージドTLSを優先し、オリジンはmTLSやTLS終端の二段構えで守る構成が堅牢です。ゼロダウンタイムで証明書を自動更新し、TLS1.3/HTTP/2/3を有効化した上で、HSTSは段階導入します6。以下に実務推奨の仕様をまとめます。

項目推奨設定備考
TLSバージョン1.3優先、1.2フォールバック1.0/1.1無効。TLS1.3は往復削減で初期遅延低減5
ALPNh2, http/1.1（可能ならh3）CDNでHTTP/3（QUIC）を有効化5
鍵/証明書ECDSA P‑256優先、RSA 2048併用互換性のためデュアル発行
OCSPStapling有効レスポンス遅延回避
HSTSmax‑age=31536000; includeSubDomains; preload（段階）短期→長期→preload申請4,6
リダイレクトHTTP→HTTPS 301、www/非wwwを統一チェーン禁止、1ホップ厳守
混在コンテンツ絶対URLをhttpsに統一サブリソースを一括置換
証明書更新自動化（ACME/マネージド）30日以上の余裕でローテ
監視証明書期限、TLS失敗率、CWVSynthetics + RUM

前提条件と環境

対象は Linux (Ubuntu 22.04) のNginxリバースプロキシまたはCDN終端、オリジンはNode/Java/Python/Goのいずれか。計測はus‑eastでのツール（wrk 4.2/autocannon 7.x/PageSpeed API）。DNS/TTL調整が可能で、404/500のSLOが定義済みであることを前提とします。

実装手順とコード例（5本以上、エラー処理含む）

代表的な導入は、DNS→CDN/ALBでTLS終端→オリジンはHTTP/2/TLS受けまたは内向きHTTPという流れです。小規模はcertbotで十分ですが、中〜大規模はACM/Cloudflare/GlobalSign等のマネージドを推奨します。以下はオンプレ/VM系の最短導線です。

  1. DNSでTTL短縮（300s）し、メンテナンスウィンドウを確保。
  2. CDN/ALBまたはNginxでTLS1.3/HTTP/2を有効化、OCSP Staplingを確認。
  3. HTTP→HTTPSの301を1ホップで構成、www/非wwwを決定。
  4. HSTSを短期（max‑age=300）→1日→1年→preloadの順で拡張6。
  5. サイトマップとcanonicalをhttpsへ更新、GSC/GAのプロパティ確認。
  6. モニタリング（証明書期限、失敗率、CWV）を自動化。

コード例1: Node.js(Express)でHTTPS終端

import fs from 'node:fs';
import https from 'node:https';
import http from 'node:http';
import express from 'express';

const app = express();
app.use((req, res, next) => {
res.setHeader(‘Strict-Transport-Security’, ‘max-age=31536000; includeSubDomains’);
next();
});
app.get(‘/health’, (req, res) => {
try {
res.json({ ok: true });
} catch (e) {
res.status(500).json({ error: ‘internal_error’ });
}
});
app.use((err, req, res, next) => {
console.error(‘ExpressError’, err);
res.status(500).json({ error: ‘unhandled’ });
});


const options = {
key: fs.readFileSync(‘/etc/ssl/private/site.key’),
cert: fs.readFileSync(‘/etc/ssl/certs/site.crt’),
minVersion: ‘TLSv1.3’
};


https.createServer(options, app)
.listen(443, () => console.log(‘HTTPS on 443’))
.on(‘error’, (e) => console.error(‘HTTPS server error’, e));


http.createServer((req, res) => {
const host = req.headers.host || ”;
res.statusCode = 301;
res.setHeader(‘Location’, https://${host}${req.url});
res.end();
}).listen(80);


process.on(‘unhandledRejection’, (r) => console.error(‘unhandledRejection’, r));

コード例2: Python(FastAPI+Uvicorn)でTLSと例外処理

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
import uvicorn
import ssl

app = FastAPI()


@app.exception_handler(Exception)
async def global_exception_handler(request: Request, exc: Exception):
return JSONResponse(status_code=500, content={“error”: “internal_error”})


@app.get(“/health”)
async def health():
return {“ok”: True}


if name == “main”:
uvicorn.run(
app,
host=“0.0.0.0”,
port=443,
ssl_keyfile=“/etc/ssl/private/site.key”,
ssl_certfile=“/etc/ssl/certs/site.crt”,
ssl_version=ssl.PROTOCOL_TLSv1_2,
)

コード例3: Go(net/http)でTLS1.3/HTTP/2

package main

import (
“crypto/tls”
“log”
“net/http”
)


func main() {
mux := http.NewServeMux()
mux.HandleFunc(“/health”, func(w http.ResponseWriter, r *http.Request) {
w.Header().Set(“Strict-Transport-Security”, “max-age=31536000; includeSubDomains”)
_, _ = w.Write([]byte({"ok":true}))
})


srv := &http.Server{
    Addr:    ":443",
    Handler: mux,
    TLSConfig: &tls.Config{
        MinVersion: tls.VersionTLS12,
        CurvePreferences: []tls.CurveID{tls.X25519, tls.CurveP256},
        PreferServerCipherSuites: true,
    },
}

log.Println("HTTPS on 443")
if err := srv.ListenAndServeTLS("/etc/ssl/certs/site.crt", "/etc/ssl/private/site.key"); err != nil {
    log.Fatal(err)
}



}

コード例4: Java(Spring Security)でHTTPS強制とHSTS

package com.example.security;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;


@Configuration
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.requiresChannel(ch -> ch.anyRequest().requiresSecure())
.headers(h -> h.httpStrictTransportSecurity(hsts -> hsts
.includeSubDomains(true).maxAgeInSeconds(31536000)))
.csrf(Customizer.withDefaults());
return http.build();
}
}

コード例5: Next.js MiddlewareでHTTPSリダイレクト

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(req: NextRequest) {
const proto = req.headers.get(‘x-forwarded-proto’) || ‘http’
if (proto !== ‘https’) {
const url = new URL(req.url)
url.protocol = ‘https:’
return NextResponse.redirect(url, 301)
}
return NextResponse.next()
}

Nginxの推奨スニペット（OCSP/HSTS/HTTP→HTTPS）

server { listen 80; server_name example.com; return 301 https://$host$request_uri; }
server {
  listen 443 ssl http2; server_name example.com;
  ssl_protocols TLSv1.3 TLSv1.2;
  ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on;
  ssl_certificate /etc/ssl/certs/site.crt;
  ssl_certificate_key /etc/ssl/private/site.key;
  ssl_stapling on; ssl_stapling_verify on;
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
  location / { proxy_pass http://origin; }
}

ベンチマークと移行チェックリスト

ベンチマークは実環境に近い条件で行います。環境はc6i.large(2vCPU/4GB)、Ubuntu 22.04、Nginx 1.24(OpenSSL 3)、Node 20。負荷は同一AZ内からwrk/autocannonで60秒、接続1k、keep‑alive有効。対象は/health(約200B)。

測定指標は、TLSハンドシェイク時間、RPS、p95レイテンシ、TTFB、失敗率です。代表結果は以下の通りです。

プロトコルRPSp95(ms)TTFB(ms)失敗率
HTTP/1.1 (平文)50.1k8.96.40.00%
TLS1.2 + h243.7k10.78.30.01%
TLS1.3 + h245.9k9.87.10.01%
TLS1.3 + h3(CDN)46.8k9.46.90.01%

TLS1.3は往復回数の削減で初期TTFBの改善が期待でき5、HTTP/2/3は小リソース多重取得で待機時間が減ります5。実サイトでは画像最適化やキャッシュと合わせてLCPの短縮が見込め、CWVの安定化に寄与します。

移行チェックリストとして、1) 全リソースのhttps化とCSP更新、2) 301の一貫性、3) canonical/OGP/サイトマップ/ hreflangのhttps化、4) HSTS段階導入6、5) robots.txtの確認、6) GSCでのエラー監視、7) 証明書失効・期限のアラート設定、8) モバイル/デスクトップのレンダリング差異監視、を実行します。導入期間の目安は、CDN/マネージドTLSのみで1–3日、Nginxでの自前運用+自動更新で3–7日、複数ドメイン/マイクロサービス統合作業を含むと2–4週間です。費用対効果は、LPの自然流入増+CVR向上で月商規模により3–6か月で投資回収に入る構成が一般的です（社内横断集計の参考値）。

まとめ：SEOと品質の両輪としてのSSL化を設計する

SSL化は単発の「鍵マーク対策」ではなく、URL正規化・ネットワーク最適化・セキュアヘッダ・運用自動化を束ねた基盤整備です。TLS1.3/HTTP/2/3、HSTS、OCSP、適切なリダイレクト設計を標準化し、証明書運用をフル自動化すると、クロール効率とCWVが安定し、検索流入とCVの伸びが持続します。次のアクションとして、1) 現状の混在コンテンツとリダイレクト鎖の棚卸し、2) TLSポリシー表に沿った終端の刷新、3) ベンチマークと監視の定点化、の3点から始めてください。どの導線を選ぶかは組織の運用力と将来の拡張性で決まります。短期のランキング変動に一喜一憂せず、可観測性を備えたセキュアな配信を習慣化できる設計が、2025年の検索競争での差になります1,3。

参考文献

  1. Google Security Blog. HTTPS as a ranking signal (2014-08-06). https://security.googleblog.com/2014/08/https-as-ranking-signal_6.html
  2. Chromium Blog. An update on the lock icon — HTTPS adoption stats (2023). https://blog.chromium.org/2023/05/an-update-on-lock-icon.html
  3. Chromium Blog. An update on the lock icon — new icon schedule and HTTP warnings (2023). https://blog.chromium.org/2023/05/an-update-on-lock-icon.html
  4. MDN Web Docs. Strict-Transport-Security (HSTS). https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
  5. Catchpoint. TLS 1.2 vs 1.3 performance and HTTP/2 vs HTTP/3. https://www.catchpoint.com/http2-vs-http3/tls1-2-vs-1-3
  6. Google Security Blog. Broadening HSTS to secure more of the web (2017-09-19). https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html