HTTPS Migration Acceptance Template

HTTPS Migration Acceptance Sheet (fill-in)

When to use: Sign off an HTTP to HTTPS move with one row per check: expected result, test, owner, pass/fail and evidence.

HTTPS migration acceptance sheet

Site: [canonical HTTPS origin, e.g. https://www.example.com]. Go-live date: [date]. Sign-off owner: [name].

Fill one row per check. A row passes only when the evidence column links to proof someone else can open.

Open issues

• Issue: [what failed] Action: [fix] Owner: [name] Due: [date]

Completion check

• Every row except HSTS shows Pass with evidence attached.
• Every open issue has an owner and a due date, or is closed.
• Recheck booked for [go-live + 7 days] and [go-live + 30 days].
• Signed off by [SEO owner] and [developer] on [date].

Trace redirect samples with the Redirect Checker: it shows every hop, status code and the final URL, and flags loops.

Verify the SSL/TLS Certificate

When to use: Confirm the certificate is valid, covers every hostname and renews automatically as lifetimes shrink.

Confirm the certificate is valid, trusted and renewing

A broken certificate shows a full-page browser warning. Users leave, and the HTTPS URLs can't be evaluated properly.

• Trust: issued by a recognized CA, with the full intermediate chain installed for [Domain].
• Hostnames: covers every name you serve: [www and non-www] plus any subdomains that serve pages or assets.
• Expiry: record the date ([Expiry date]) and who gets the alert if renewal fails.
• Renewal: automated. Manual renewal does not survive shorter lifetimes.

Certificate lifetimes are getting shorter

• Let's Encrypt certificates are 90 days by default today.
• From 10 February 2027, Let's Encrypt moves the default to 64 days.
• Let's Encrypt plans a 45-day default from 16 February 2028.
• Industry rules cap all public certificates at 47 days from 15 March 2029.

Action: use an ACME client that supports ACME Renewal Information (ARI), or renew at about two thirds of the lifetime. Search scripts for hard-coded 60, 80 or 83 day timers.

Force HTTPS (Redirects, One Canonical Version)

When to use: Redirect every HTTP URL to its HTTPS match in one hop and update canonicals, links and sitemaps.

Send every URL to one secure address

http and https, www and non-www are separate URLs to Google. Pick one canonical origin, such as [https://www.example.com], and force everything to it.

1. Map each HTTP URL to its exact HTTPS match. Never bulk-redirect to the homepage.
2. Use server-side permanent redirects (301 or 308) straight to the final URL, in one hop.
3. Keep the full path and query string.
4. Keep the redirects for at least a year. Google suggests as long as possible.

Update everything that names a URL

• Self-referencing canonical tags on HTTPS URLs.
• Internal links, hreflang annotations, structured data URLs.
• Sitemaps: HTTPS URLs on the canonical host only.
• robots.txt on the HTTPS host, including the Sitemap line.
• Ads, email templates, social profiles and other links you control.

Search Console: don't use the Change of Address tool. Google says it is not needed for HTTP to HTTPS or www to non-www moves on the same domain.

Rebuild the sitemap from your HTTPS URL list with the XML Sitemap Generator. It expects absolute URLs that match your canonicals.

Fix Mixed Content

When to use: Find and fix HTTP resources on HTTPS pages before browsers block them.

Load every resource over HTTPS

Mixed content is an HTTPS page that loads resources over HTTP. Modern browsers handle it in two ways (per MDN):

• Upgradable: plain img src, audio and video. The browser tries the HTTPS version instead. If that fails, the resource breaks.
• Blockable: scripts, stylesheets, iframes, fonts, fetch requests and images using srcset or picture. The browser blocks them.

So a page can look fine while a script, font or embed is silently blocked. Test, don't assume.

1. Open DevTools on each template ([Template list]) and read the console for mixed-content messages.
2. Crawl the site and filter resource URLs that start with http://.
3. Change your own resources to HTTPS or relative URLs, in templates and in the database.
4. Switch third-party embeds to their HTTPS versions; replace any that have none.

Check one page fast with Get Source Code of Webpage: it lists the resources referenced in the raw HTML.

Note: the CSP directive upgrade-insecure-requests upgrades all requests, but fix the source URLs too.

HSTS & Security Headers

When to use: Add HSTS and core security headers safely, and know the preload rules before you commit.

Harden the connection with headers

Add headers at the server or CDN once HTTPS is stable. Test each in staging first.

• Strict-Transport-Security (HSTS): tells browsers to use HTTPS only. Start with a short max-age, then raise it.
• Content-Security-Policy: limits where scripts and styles load from. frame-ancestors controls who can frame you.
• X-Content-Type-Options: nosniff stops MIME-type guessing.
• Referrer-Policy: controls what URL data leaks to other sites.

HSTS preload requirements (hstspreload.org)

• A valid certificate, and HTTP redirects to HTTPS on the same host.
• All subdomains served over HTTPS, including www if it has a DNS record.
• max-age of at least 31536000 (1 year), plus includeSubDomains and preload.

Warning: preloading is hard to undo. Removal takes months to reach Chrome users. Preload only after the acceptance sheet passes.

Confirm headers on [Page URL] with Get Source Code of Webpage, which shows response and security headers.

Crawl Verification & Search Console

When to use: Prove the HTTPS site crawls cleanly and track the switch in Search Console reports.

Prove Google can crawl the HTTPS site

Redirects working in a browser is not enough. Crawl the HTTPS site as a bot would, then watch Search Console.

1. Crawl [https://www.example.com] and confirm indexable pages return 200.
2. Filter for internal links, canonicals and hreflang still using http://.
3. Crawl the old HTTP URL list and confirm each one returns a single permanent redirect.
4. Remove any temporary noindex or robots.txt blocks used during the move.

Search Console checks

• Properties: a Domain property, or both HTTP and HTTPS URL-prefix properties. The HTTPS report appears only in Domain or HTTPS URL-prefix properties.
• Sitemaps report: submit the HTTPS sitemap, then filter the Page indexing report by that sitemap to watch indexed HTTPS URLs rise.
• HTTPS report: look for HTTP marked with canonical tag, HTTPS has invalid certificate, Sitemap points to HTTP, HTTPS has redirect and HTTPS URL is roboted.
• Page indexing report: HTTP URLs should move to page with redirect over time.

Log results in the sheet with dates: [crawl date], [URLs crawled], [issues found].

Hacked-Site & Malware Checks

When to use: Detect injected spam, malware or redirects that HTTPS alone does not prevent.

Catch compromises before Google does

HTTPS protects data in transit. It does not stop a hacked site from serving spam, malware or sneaky redirects.

• Security issues report: check it in Search Console for [Property]. Google lists hacked content, malware and deceptive pages here.
• Site search: search your domain on Google for spam keywords or pages you never published.
• Files and database: look for injected scripts, unknown admin users and changed core files.

1. If flagged, remove the content and close the entry point, such as an outdated plugin or weak password.
2. Update software and rotate credentials for [Accounts].
3. Request a review in the Security issues report once the site is clean.

Tip: make sure Search Console email alerts reach a person who will act on them.

Audit & Monitor

When to use: Recheck certificates, redirects, mixed content and headers on a schedule after sign-off.

Keep HTTPS healthy after sign-off

Certificates expire, new pages ship with http:// assets and server changes drop headers. Recheck on a schedule.

Log each finding with an owner in [Tracker] and retest after the fix.

A free website audit rechecks HTTPS, redirects, robots.txt and sitemaps in one run.

Worked Example (fictional outdoor gear shop)

When to use: See a completed acceptance sheet, including the failures it caught on go-live day.

Worked example: Ridgeline Supply moves to HTTPS

Example only. The company, people, URLs and figures are invented to show what a usable, filled-in version looks like.

Ridgeline Supply, an outdoor gear shop with about 1,200 URLs, switched http://ridgeline-supply.example to https://www.ridgeline-supply.example on 14 Oct.

Why this worked

• Testing every row on go-live day caught three failures before Google recrawled most of the site.
• The sitemap was checked as its own row, so it was fixed the same day instead of sending HTTP URLs for weeks.
• HSTS started short, so a bad redirect could still be rolled back without locking browsers in.

Next step

Run a free website audit on your HTTPS homepage. It checks that the site loads on HTTPS, that http:// redirects to it, and reviews redirects, robots.txt and the sitemap.