This test fails when the raw HTML document weighs significantly more than necessary, even before counting images, CSS, or JavaScript. Bloated HTML increases time to first byte, slows parsing, and stalls rendering on mobile networks and lower-powered devices. Fixing this issue means trimming inline data, removing legacy markup, and keeping the document focused on what the user needs.

Where to make the change

• Application code or templates: identify which sections produce the most bytes (often a large inline JSON blob, an inline base64 image, or a giant comment block) and refactor them to load externally or be removed.
• WordPress: check for plugins or page builders that emit large inline configurations. Disable unused plugins and prefer themes that ship clean markup.
• Shopify: theme code may inline large product or section JSON. Move heavy data to a fetch-on-demand endpoint when possible.
• Headless or framework sites: review the rendered output for serialized state (for example __NEXT_DATA__ in Next.js) and trim what is sent on first paint by streaming or lazy-loading non-critical chunks.

Common causes and how to resolve them

• Inline base64 images or fonts: move them to external files so the browser can cache them across requests.
• Excessive inline CSS or JavaScript: link to external stylesheets and scripts so they cache. Inline only the truly critical CSS for above-the-fold content.
• Large server-side JSON payloads: ship only the data needed for first render. Fetch the rest on demand.
• Repeating boilerplate or commented-out code: strip comments and dead code in the production build.
• HTML compression disabled: Gzip or Brotli compression often shrinks the response by half or more. Confirm the server sends the appropriate Content-Encoding header.

Best practices

• Aim for under 100 KB of HTML: most pages can comfortably stay under this. Anything beyond a few hundred KB usually indicates structural bloat worth refactoring.
• Enable compression: Gzip is the safe minimum, Brotli is even better for HTML and other text formats.
• Defer non-critical content: rendering only what is needed for the initial viewport keeps both bytes and parse time down.
• Audit periodically: add HTML size to your performance budget so regressions get caught in CI.

This test fails when the page exposes one or more email addresses in plain text. Spam-harvesting bots scrape pages for plaintext addresses and add them to bulk mailing lists. Fixing this issue means obfuscating contact addresses, using a contact form, or rendering them via JavaScript so simple scrapers cannot read them.

Where to make the change

• Application code or templates: replace plain contact@example.com text with one of the obfuscation techniques below.
• WordPress: a contact form plugin handles email submissions without exposing the address. Some SEO and security plugins also offer email obfuscation.
• Shopify, Wix, Squarespace: use the platform's built-in contact form blocks rather than displaying the email address directly.

Common causes and how to resolve them

• Plain text address in a paragraph or footer: replace with a contact form, an obfuscated rendering (HTML entities, CSS reversal), or a JavaScript-built mailto link.
• Mailto link with the address visible: the visible text is what bots read. Make the visible text a label like "Email us" while the href still works.
• Address baked into images is fine for SEO but bad for accessibility: screen readers cannot read it. Pair an image with a contact form instead.

Best practices

• Prefer contact forms: they reduce spam and make analytics easier.
• Use HTML entity encoding: writing co... for the address defeats the simplest scrapers, though sophisticated ones decode it.
• Render via JavaScript: building the mailto link client-side blocks scrapers that only read static HTML.
• Consider a Cloudflare-style email obfuscation: some CDNs automatically rewrite plaintext emails to obfuscated equivalents.

This test fails when external links opened in a new tab (with target="_blank") lack the rel="noopener" or rel="noreferrer" attributes. Modern browsers (Chrome 88+, Firefox 79+, Safari 12.1+) apply noopener implicitly, so this is largely a defense for older browsers and a way to keep the destination page from running in the same browser process as the original tab. Fixing this issue means adding the attributes explicitly to every external target="_blank" link.

Example

<a href="https://example.com" target="_blank" rel="noopener noreferrer">
  External link
</a>

Where to make the change

• Application code or templates: search for target="_blank" and add rel="noopener noreferrer" to each match. A simple find-and-replace handles most cases.
• WordPress: the block editor adds rel="noopener" automatically on every external link opened in a new tab. Older content may need a one-time bulk update.
• Shopify, Wix, Squarespace: editor-generated links typically include the rel attributes. Manual HTML embeds need them added.
• Headless or framework sites: wrap external links in a component that always sets the correct rel attributes.

Common causes and how to resolve them

• Hand-written external links missing the attribute: add rel="noopener noreferrer" to each one.
• Old content from before the editor added it automatically: a one-time bulk update through the database or CMS export covers it.
• Markdown-rendered content: configure the renderer to add the attributes to every external link by default.

Best practices

• Use noopener noreferrer together: noopener handles the security concern, noreferrer additionally hides the referring URL. Both are safe defaults for most external links.
• Reserve target="_blank" for genuinely external links: internal links should open in the same tab so users can use the back button naturally.
• Add a lint rule: ESLint plugins for React and similar frameworks can enforce the rel attribute automatically.

This test fails when the page's stylesheets do not use CSS media queries to adapt the layout to different screen sizes. Media queries are the primary mechanism for responsive design, allowing typography, spacing, and component arrangement to adjust gracefully across devices. Because Google now indexes the web mobile-first, the responsive mobile layout is effectively the version search engines crawl, evaluate, and rank.

Example

/* Mobile-first base styles */
.card { padding: 16px; font-size: 16px; }

/* Tablet and up */
@media (min-width: 768px) {
  .card { padding: 24px; font-size: 18px; }
}

/* Desktop */
@media (min-width: 1024px) {
  .card { padding: 32px; font-size: 20px; }
}

Where to make the change

• Stylesheets: add @media blocks for the breakpoints your design needs. Start with mobile-first base styles and layer larger screens on top.
• WordPress: most modern themes are responsive. If yours is not, switch to a current theme or add custom CSS for breakpoints.
• Shopify, Wix, Squarespace: all platforms ship responsive themes by default; failures usually point at custom CSS that hard-codes desktop widths.
• Headless or framework sites: CSS frameworks like Tailwind, Bootstrap, and CSS Modules all include responsive utilities; ensure you are using them.

Common causes and how to resolve them

• No media queries at all: add a few breakpoints based on your design. Common choices are 480, 768, 1024, and 1280 pixels.
• Fixed pixel widths everywhere: replace with relative units (rem, %, vw) and let media queries handle major layout shifts.
• Desktop-first styles overriding mobile: reorder so mobile styles are the base and larger breakpoints add desktop refinements.
• Modern layout primitives missing: CSS Grid and Flexbox often eliminate the need for many media queries by responding naturally to available space.

Best practices

• Mobile-first: base styles target mobile; min-width media queries layer enhancements for larger screens.
• Use container queries where supported: they let components respond to their container's size rather than the viewport, which is often more useful.
• Test on real devices: emulator views miss real-world issues such as touch target size and font rendering. Test on actual phones too.

This test fails when the site does not serve a branded, helpful page for missing URLs. A custom 404 keeps users on the site by offering navigation, search, and suggested links rather than dropping them at the browser's generic error screen. Fixing this issue means designing a 404 template, ensuring it returns the correct HTTP 404 status, and pointing your server at it.

Where to make the change

• Server configuration: point your web server at a custom 404 page. In Nginx, use error_page 404 /404.html;. In Apache, use ErrorDocument 404 /404.html.
• WordPress: create a 404.php template in your theme. WordPress invokes it automatically for missing URLs.
• Shopify: edit the 404.liquid template in the theme code editor.
• Wix or Squarespace: use the platform's built-in 404 page editor in site settings.
• Headless or framework sites: Next.js uses not-found.js, Astro uses 404.astro, and similar frameworks all have a convention for the missing-route page.

Common causes and how to resolve them

• No custom 404 at all: create one. The minimum is the site header, navigation, a clear "page not found" message, and links to popular sections.
• 404 page returns HTTP 200: a "soft 404" confuses search engines. Verify the response status with DevTools or curl, and configure the server to return 404 for missing routes.
• 404 page redirects to homepage: redirecting users to the homepage hides broken URLs from analytics and search engines. Show a real 404 instead.
• Generic browser error visible: the server is not invoking the custom template. Check the configuration directive.

Best practices

• Keep the site chrome: show the header, footer, and navigation so users do not feel lost.
• Offer next steps: a search box, popular links, or category navigation help users get back on track.
• Track 404s: log missing-URL hits in analytics so you can spot broken inbound links worth fixing or redirecting.
• Be clear about the error: "Sorry, that page does not exist" is better than vague messaging that confuses users.

This test reports on whether the page applies a nofollow directive that tells search engines not to follow outbound links. The nofollow attribute (and the related sponsored and ugc values) controls how link equity flows from your page. Fixing this issue means using the right rel value on each external link based on its purpose so signals are passed only where you intend.

Where to make the change

• Raw HTML: add rel="nofollow", rel="sponsored", or rel="ugc" to specific outbound links rather than blanket-applying them site-wide.
• WordPress: the block editor offers a "mark as nofollow" option per link, and SEO plugins can auto-tag external links by domain.
• Shopify, Wix, Squarespace: editor-generated links allow rel attribute toggles; manual HTML embeds need them set explicitly.
• Headless or framework sites: wrap external links in a component that decides the rel based on the link's classification.

Common causes and how to resolve them

• Site-wide nofollow on every external link: overly aggressive. Reserve nofollow for sponsored, untrusted, or user-generated content.
• Sponsored content not labeled: use rel="sponsored" on paid placements and affiliate links to comply with Google's link spam policy.
• User-generated content unmarked: comments, forum posts, and review user submissions should use rel="ugc".
• Trusted editorial links nofollowed: these should pass equity. Remove the nofollow.

Best practices

• Use the most specific value: sponsored for paid links, ugc for user content, nofollow for everything else you want to disclaim. They can be combined: rel="sponsored noopener".
• Do not nofollow internal links: "PageRank sculpting" with internal nofollow no longer works and just wastes crawl signal.
• Audit periodically: as content ages, sponsored relationships change. Review affiliate and partner links once a year.