Security & HTML Quality: the trust and clean-markup layer engines won't overlook

HTTPS encrypts the connection between the visitor and your server, so nobody in between can read or tamper with the page. Google made it a lightweight ranking signal back in 2014, and browsers have steadily raised the stakes: a page on plain HTTP now shows a "Not secure" warning in the address bar that visibly erodes trust and conversions.

A green padlock isn't automatic — the certificate has to be valid: issued by a trusted Certificate Authority, matching the exact hostname, not self-signed, and not expired. An expired or mismatched certificate is arguably worse than no HTTPS at all, because browsers throw a full-page interstitial that blocks the user (and crawlers) before they ever see the content.

Two adjacent best practices belong here. First, every HTTP URL should 301-redirect to its HTTPS equivalent, so there's a single secure canonical version. Second, add an HSTS (Strict-Transport-Security) header so browsers force HTTPS on future visits and never even attempt the insecure version. For AI and answer engines, a secure, trustworthy origin is part of the credibility they weigh before citing you.

"Mixed content" is what happens when a secure HTTPS page pulls in resources over insecure HTTP. The browser treats this as a hole in the page's security and responds in one of two ways. Active mixed content — scripts, stylesheets, iframes, XHR/fetch — is blocked outright, because an attacker who tampered with it could take over the whole page. Passive mixed content — images, audio, video — is usually loaded but downgrades the lock icon and shows a "not fully secure" warning.

The practical damage is that blocked active content can break your page: a stylesheet that doesn't load leaves the page unstyled, a blocked script disables interactivity. From a crawler's perspective, a half-rendered or broken page is harder to parse and judge, which feeds back into ranking and AI extractability.

The fix is almost always to update sub-resource URLs to https:// (or protocol-relative / relative URLs). The Content-Security-Policy: upgrade-insecure-requests header is a useful safety net that auto-upgrades stragglers, but the durable fix is correcting the references at the source.

Accessibility and machine-readability are two sides of the same coin. The signals a screen reader relies on — a declared lang attribute, descriptive alt text, properly associated form labels, a logical heading order, and adequate colour contrast — are the exact same signals search engines and AI crawlers use to understand what a page is and what each part means.

This check is a baseline roll-up of the most impactful accessibility fundamentals: is the page's language declared, do meaningful images carry alt text, are interactive controls labelled, and is the markup structured with real landmarks rather than anonymous <div>s? Each of these has a dedicated deeper check (alt text in G4, semantic HTML in G5, language in the International category), but together they form a fast read on whether the page is parseable.

Beyond the SEO/GEO benefit, accessibility is a legal requirement in many jurisdictions (ADA, EN 301 549, the European Accessibility Act). Treat WCAG 2.2 AA as the target; the basics here get you most of the way and remove the cheapest, most common failures.

The alt attribute is an image's text equivalent. Screen readers announce it, Google Images ranks on it, and AI crawlers — which can't reliably "see" a picture — use it to understand visual content and the topical context it adds to the page. An image with no alt text is, to a machine, a blank space.

Good alt text is concise and descriptive: it conveys the content and function of the image, not a keyword-stuffed caption. "Bar chart showing 2026 revenue up 30% year over year" is useful; "image1.jpg" or "revenue revenue chart seo best" is not. If the same information is already in nearby text, keep the alt short to avoid redundancy.

There is one important exception: purely decorative images (spacers, background flourishes) should use an empty alt="" so assistive tech skips them — an empty alt is correct, a missing alt is not. This check flags meaningful images that lack alt text; decorative images with an explicit empty alt are treated as correct.

Browsers are forgiving of malformed HTML, but parsers aren't equally lucky. Search-engine and AI crawlers build a model of the page from its structure; broken nesting, unclosed tags or a soup of anonymous <div>s makes that model less reliable, which can cause the wrong text to be associated with the page — or the right text to be missed.

Semantic landmarks are the high-value win. Wrapping the primary content in <main> or <article>, navigation in <nav>, and chrome in <header>/<footer> tells a parser exactly which block is the content it should read and quote — the same content structure and quality signal that makes a passage extractable. This is increasingly important for GEO: AI engines extract short passages, so they need to know which block is the article and which is the menu.

This check looks for two things: that the markup is valid (no major parse errors) and that the page uses semantic structure rather than generic containers. The fix is rarely a rewrite — it's usually swapping a handful of structural <div>s for the matching semantic element and closing any stray tags.

Content hidden with display:none or tucked behind interactive widgets (tabs, accordions) is treated cautiously by some engines: it may carry less weight than visible content, on the assumption it's secondary. For your most important text, prefer visible-by-default layouts so there's no ambiguity about its prominence.

Putting the main content inside an `<iframe>` is a bigger problem. An iframe embeds a separate document, so search and AI crawlers struggle to attribute that content to the host page — it may be indexed (if at all) as belonging to the iframe's own URL. Keep primary content in the main document; reserve iframes for genuinely third-party embeds.

This is an extended check: in many designs hidden/tabbed content is perfectly fine, so it's flagged for review rather than treated as an automatic failure.

Every page is bytes that have to be interpreted as characters, and the character encoding tells the browser how. UTF-8 is the universal standard — it covers every language and symbol. If the encoding is wrong or undeclared, the browser guesses, and the result is mojibake: curly quotes, accented letters, em-dashes and emoji turning into strings like ’ or é.

Garbled text isn't just ugly — it actively harms comprehension for both readers and machines. An AI engine trying to quote a passage riddled with corrupted characters will produce a broken citation, and a search snippet full of ? symbols kills click-through.

The fix is one line: <meta charset="utf-8"> placed as the first child of the `<head>`, before any text content. Position matters — declaring it late can cause the browser to re-parse, and the spec wants it within the first 1024 bytes. Make sure the file is actually saved as UTF-8 too, not just declared.

The favicon is referenced with <link rel="icon"> (or served as /favicon.ico). It shows up in the browser tab, the bookmarks bar, mobile home-screen shortcuts — and, increasingly, next to your result in Google's SERP and in AI answer cards, where a recognisable icon improves trust and click-through.

Google has specific requirements: the favicon should be a multiple of 48×48px, on a stable URL, and in a supported format. A missing or broken favicon means a generic placeholder appears beside your listing, which looks unfinished next to competitors who have one.

This is an extended polish check — it won't make or break visibility, but it's a five-minute fix that improves how your brand appears everywhere your URL is shown.