Mobile-first indexing, HTTPS and security headers

0:00 Mobile-first, HTTPS and security

Google predominantly indexes the mobile version of your site. So if your mobile pages show less content, fewer links or different tags than desktop, that's what Google sees. In this lecture you'll learn how mobile-first indexing works in practice, the parity checklist, what to do about interstitials, the HTTPS essentials, a sensible baseline of security headers, and how to monitor for hacked content, because a compromised site suffers badly in search.

0:31 Mobile-first indexing

Mobile-first indexing means Google uses the mobile version of content, crawled by the smartphone Googlebot, for indexing and ranking. For responsive sites, where the same HTML serves every device, this is mostly a non-issue. Problems appear when the mobile experience differs. Think of it like a shop window. If your street-facing window shows only half your stock, passers-by assume that's all you sell, even if the back room is full.

1:01 Parity checklist

The parity checklist. Primary content should be the same. Hiding content in tabs or accordions is fine if it's in the HTML; removing it from mobile removes it from Google. Metadata should match: titles, descriptions and robots meta, and a mobile template that accidentally outputs noindex affects your whole index. Structured data should match. Internal links should match, because a slimmed mobile menu that drops category links reduces discovery. And images and lazy-loaded content should load without swipes or clicks.

1:36 Separate mobile sites

Legacy separate mobile sites, like m dot example dot com, need rel alternate from desktop to mobile and rel canonical from mobile to desktop, plus equivalent content. Honestly, migrating to responsive design removes a whole class of errors, and it's what most sites should do. To check parity, use URL Inspection, which uses the smartphone crawler, and crawl with a mobile user agent, comparing content, links and directives with a desktop crawl.

2:07 Interstitials

Intrusive interstitials. Full-screen pop-ups that block content right after someone arrives from search make a poor experience. Legally required interstitials, like cookie consent or age verification, are acceptable, but design them to be small and dismissible, and keep the underlying content in the HTML so it can still be crawled. A consent banner that covers the whole screen and pushes content around can also hurt CLS.

2:36 HTTPS essentials

HTTPS essentials. It's a lightweight ranking signal and a baseline of trust. Have a valid certificate covering all hosts. Redirect HTTP to HTTPS sitewide in a single hop. Make canonicals, hreflang, sitemaps and internal links all use HTTPS. Eliminate mixed content, meaning HTTP images, scripts or iframes on HTTPS pages. And use a modern TLS configuration, at least TLS one point two, preferably one point three.

3:05 Security header baseline

Security headers aren't ranking factors in their own right, but a hacked site suffers severely, with spam injections, malware warnings and manual actions. A sensible baseline: Strict-Transport-Security to force HTTPS, starting with a short max-age before increasing, and adding preload only when you're certain. A Content Security Policy, deployed first in report-only mode, because tag managers and widgets often need allow-listing. X-Content-Type-Options nosniff. A Referrer-Policy like strict-origin-when-cross-origin. And frame-ancestors in CSP to prevent clickjacking.

3:37 Hands-on: parity + header check

Hands-on. The lesson text includes a Python parity and header check. It fetches a URL with a mobile and a desktop user agent, and compares status, number of links, word count, JSON-LD blocks, robots meta and canonical. For the mobile response it also prints the key security headers or flags them as missing. It checks raw HTML only, so for JavaScript sites compare rendered output too.

4:06 Example 1: mixed content after a CDN change

Worked example one, simple. A Leeds charity moved images to a new CDN domain, but some templates still reference the old HTTP image URLs. Browsers block or warn on mixed content, and some images disappear on mobile. A crawl for HTTP resources on HTTPS pages finds them in minutes. The fix is updating templates to the HTTPS CDN URLs and adding an upgrade-insecure-requests directive as a safety net.

4:36 Example 2: slimmed mobile menu (illustrative)

Worked example two, with illustrative details. A Karachi electronics retailer launched a cleaner mobile menu showing only six top categories, while desktop linked to forty subcategories. Because Google indexes the mobile version, subcategory pages lost most of their internal links, and their crawl frequency fell in the logs. The fix kept the clean look, but rendered all the subcategory links inside an accessible, collapsible menu present in the HTML. Parity checks were added to the release checklist.

5:09 Monitoring and mistakes

Hacked-site monitoring and common mistakes. Watch Search Console's Security issues and Manual actions reports with email alerts on. Occasionally search your site for spam terms, and look for unfamiliar URLs or queries in languages you don't publish in. Keep your CMS and plugins patched and enforce multi-factor authentication. Common mistakes: a mobile template with fewer links or missing structured data, mixed content after a domain change, setting HSTS with include subdomains before a legacy subdomain supports HTTPS, and believing security headers lift rankings.

5:45 Watch me do it: parity + headers

Watch me do it. I'll run a mobile parity and header check on three templates. Step one: I run the parity script for the home page, a category and a product. The home page matches. The category page shows mobile links forty-two, desktop one hundred and eighteen. The product page shows mobile JSON-LD blocks zero, desktop two. Step two: I open the category on a phone-sized viewport in DevTools and inspect the menu. The mobile menu only includes top-level categories. Subcategory links aren't in the HTML at all. Step three: for the product, I view the mobile source. The structured data include lives in a desktop-only template partial. Step four: headers. The script shows Strict-Transport-Security present with a one-year max-age and include subdomains. Content-Security-Policy is missing. X-Content-Type-Options is present. Referrer-Policy is missing. Step five: I check whether every subdomain supports HTTPS, because include subdomains is already on. The old careers subdomain doesn't. That's urgent. Step six: tickets. Render full subcategory links in an accessible collapsible mobile menu. Move the JSON-LD include into the shared template. Fix HTTPS on the careers subdomain. And roll out CSP in report-only mode first.

7:07 The HSTS trap

Let's talk about the HSTS trap in a bit more detail, because it catches experienced teams. Strict-Transport-Security tells browsers to use HTTPS for your domain for a period of time. Add include subdomains, and every subdomain must support HTTPS too. If you have an old subdomain, maybe a legacy blog or an internal tool, that only works on HTTP, returning visitors suddenly can't reach it at all. And if you've submitted your domain to the browser preload list, undoing that is slow. So roll out in stages: short max-age, confirm every subdomain, then increase, and add preload only when you're certain.

7:51 Recap and try this now

Recap. Google indexes your mobile version, so make it equal in content, metadata, structured data and links. Keep interstitials small, HTTPS clean, and security headers sensible, and monitor for hacks. Try this now. Run the parity script on one URL from each main template, and fix any template where mobile has noticeably fewer links, words or JSON-LD blocks than desktop.