Daily SEO Note — August 27, 2026: Next.js Re-Enables AVIF as the libheif Fix Lands

1. SEO for Content Writers

The editorial track produced no verified change in the last 24 hours. Google's Search Central Blog has published nothing since July, the documentation changelog still ends at the 20 August preferred-sources entry, and the Search Status Dashboard lists no update running — the August 2026 spam update finished on 21 August and nothing has replaced it. No ranking system, spam policy, rich result type or Discover requirement moved today.

Post-spam-update volatility continues (unconfirmed)

Community trackers and forum chatter continue to report ranking movement in the days after the August 2026 spam update completed on 21 August. This is unconfirmed: Google has announced nothing, the status dashboard shows no active update, and third-party volatility sensors are not a primary source. It is recorded here as an observation, not a finding, and it is deliberately kept out of the checklist below.

The editorial response to unconfirmed volatility is to do nothing structural. Rewriting pages against a movement no one has confirmed is how teams damage content that was ranking fine. If you saw a genuine drop, wait for the ranking data to settle and then look at the pages individually rather than at the site as a whole.

Apply to your next brief

• No brief changes today. Nothing in Google's ranking, policy or rich-result surfaces moved in the last 24 hours.
• Carry forward yesterday's still-active items: no GEO or AEO-specific deliverables, and flag headlines, FAQ answers and bylines containing an ampersand or special character for a rich-result spot check.
• If you are commissioning image-led articles this week, expect hero images to ship as WebP rather than AVIF for a few more days. Page weight is slightly higher; brief for fewer, better images rather than more of them.
• Do not rewrite pages in response to unconfirmed post-spam-update volatility. Wait for confirmation, then review individual pages.

2. SEO for Developers

The AVIF remote code execution flaw that forced Next.js to switch off image optimization on 25 August now has a complete fix chain, and it closed inside this reporting window. libheif shipped the patch, sharp picked it up, and Next.js re-enabled AVIF in canary at 00:53 UTC today. Nothing stable ships it yet — so today's engineering job is to upgrade the layers that are ready and leave your image format pinned until it is.

Next.js re-enables AVIF optimization — in canary only

Next.js 16.4.0-canary.9, published 27 August at 00:53 UTC, lists "Re-enable AVIF image optimization" (PR #97931) under its miscellaneous changes. That reverses the mitigation added on 25 August, when GHSA-2xp9-vwfh-vxw4 (CVSS 9.5) forced AVIF optimization off because a crafted AVIF file could reach unauthenticated remote code execution through libheif.

Rollout status: canary, not stable. The August 2026 security release still reads that "the patched releases disable AVIF optimization until an upstream fix is propagated," and 16.3.3 and 15.5.24 continue to disable it. Vercel's managed Image Optimization service also still serves WebP in place of AVIF.

Non-breaking, and the symptom of acting too early is self-inflicted: if you re-enable AVIF in your config against a stable release, nothing happens, because the framework disables it below the config layer. Leave the format pinned and delete the pin when AVIF lands in a stable tag. Keep watching your LCP field data in the meantime, because WebP is the larger transfer.

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  images: {
    // 2026-08-27: AVIF is re-enabled in 16.4.0-canary.9 only.
    // 16.3.3 and 15.5.24 still disable it below the config layer,
    // and Vercel's managed Image Optimization still serves WebP.
    // Keep this pinned until AVIF ships in a stable tag, then
    // delete the line rather than adding 'image/avif' back here.
    formats: ['image/webp'],
  },
}

export default nextConfig

libheif 1.23.2 closes a 9.8, and sharp 0.35.4 already carries it

libheif 1.23.2 shipped on 25 August as a security and bugfix release fixing seven vulnerabilities, two of them critical. The one that matters here is GHSA-g89c-p67h-r497 — CVSS 9.8, a heap buffer overflow in scale_nearest_neighbor() triggered by crafted HEIC, HEIF or AVIF files with nested identity-derivation and duplicate alpha planes. It affects every application calling heif_decode_image(), needs no special API usage, and the advisory confirms researchers achieved remote code execution.

The propagation chain completed inside this window, and the timestamps are worth recording. libheif 1.23.2 landed 25 August. sharp-libvips 1.3.3 — which bundles libheif 1.23.2 — published to npm on 26 August at 08:33 UTC. sharp 0.35.4 followed at 09:42 UTC the same day, and it requires sharp-libvips 1.3.3 across every platform binary.

One correction worth making explicitly, because it is easy to get backwards: sharp 0.35.4's own changelog lists no security fix. Its entries are resize and composite coordinate bounds, palette bit depth rounding, a TIFF subifd option fix and stream handling. The patched libheif arrives through the bundled sharp-libvips binary, not through sharp's own code. Upgrading sharp is still the right move — that is how the fix reaches you — but do not read the changelog and conclude nothing security-relevant happened.

Ship today if you call sharp directly in a build step, an image pipeline or a self-hosted optimizer. Next.js users get this through a framework upgrade instead and should not hand-pin sharp underneath it.

# Is the patched libheif already in your tree?
# sharp >= 0.35.4 requires @img/sharp-libvips 1.3.3, which bundles libheif 1.23.2.
npm ls sharp @img/sharp-libvips-linux-x64

# Upgrade only if you call sharp directly, not through Next.js
npm install sharp@^0.35.4

# Confirm the linked library versions at runtime, not from the lockfile
node -e "console.log(require('sharp').versions)"

web-vitals 6.2.1 fixes negative inputDelay in INP attribution

web-vitals 6.2.1 published 26 August at 19:08 UTC with a single entry: "Fix negative inputDelay in INP attribution" (PR #789). Version 6.2.0, two days earlier, fixed a related data-integrity bug — a spurious CLS report of 0 after a bfcache restore — and guarded supportedEntryTypes for older browsers.

Non-breaking, and the symptom if you ignore it is quiet and expensive: your field data was wrong, not your site. A negative inputDelay pulls down the averages you compute from INP attribution, so the input-delay phase looks healthier than it is and you spend your optimization effort on processing duration or presentation delay instead. A spurious CLS of 0 after bfcache restore does the same in the other direction, flattering your layout stability. Neither shows up as an error — only as a number you trusted.

Ship today if you self-report Core Web Vitals to your own analytics. This is a dependency bump with no API change: install 6.2.1 and discard any INP phase breakdown you collected from 6.0.0 onward, since the attribution build has carried this since the v6 line began.

// npm install web-vitals@^6.2.1
import { onINP } from 'web-vitals/attribution'

onINP(({ value, attribution }) => {
  // Before 6.2.1, inputDelay could arrive negative and quietly
  // poison any average or percentile computed from these phases.
  const { inputDelay, processingDuration, presentationDelay } = attribution

  sendToAnalytics({
    metric: 'INP',
    value,
    inputDelay,
    processingDuration,
    presentationDelay,
  })
})

Astro 7.2.8 raises the sharp floor to 0.35.4

Astro 7.2.8 published 26 August at 21:02 UTC. Two patch changes: it raises the minimum supported version of sharp to 0.35.4, and it replaces the internal find-process dependency with a lighter alternative. Non-breaking.

The first entry is the one with security weight, and it is the same chain as above rather than a separate issue: Astro's image optimization runs through sharp, so lifting the floor to 0.35.4 is what pulls the patched libheif into an Astro build. If you run Astro's image endpoint over remote or user-supplied images, take this today. If every image you process is committed to your own repository, the exposure is lower but the upgrade is still a patch release with no migration.

Yesterday's 7.2.7 fix for route selection on normalized request paths is still worth pairing with this bump if you skipped it — re-run a status-code crawl after upgrading and confirm no phantom 404s remain.

npm install [email protected]

# Confirm the resolved sharp version cleared the new 0.35.4 floor
npm ls sharp

# Re-run a status-code crawl: 7.2.7 also changed route selection
npx astro build && npx astro preview

Cloudflare shipped an emergency WAF release for the Next.js flaws

Cloudflare's changelog records an emergency WAF release on 26 August covering both Next.js vulnerabilities: CVE-2026-75604 for Windows-hosted instances and GHSA-2xp9-vwfh-vxw4 for the Image Optimizer. It updates existing detections and adds new rules, all in Block mode. This follows the standard 26 August release that moved four detections from Log to Block, including HTTP/2 request smuggling and several XSS variants.

Two things follow for an SEO engineer, and they pull in opposite directions. First, an edge rule is mitigation, not remediation — it reduces exposure for traffic that passes through Cloudflare, and it does nothing for your origin if that origin is reachable another way. Upgrade the framework regardless.

Second, new Block-mode rules on the image-optimizer path deserve a false-positive check. Crawlers fetch optimized image URLs, and a rule that blocks a crafted request pattern can also catch a legitimate one; the symptom is image URLs returning 403 to Googlebot while rendering fine in your browser, which surfaces later as image indexing loss rather than as an incident. Replay a representative image request with a crawler user agent and watch your WAF events for the rule IDs from this release.

# Replay an image-optimizer request as Googlebot to confirm the new
# Block-mode rules are not catching legitimate crawler fetches.
# Expect 200. A 403 means a WAF rule is blocking crawler image traffic.
curl -s -o /dev/null -w '%{http_code}\n' \
  -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \
  'https://example.com/_next/image?url=%2Fhero.jpg&w=1200&q=75'

# Compare against a browser user agent to isolate a bot-specific block
curl -s -o /dev/null -w '%{http_code}\n' \
  'https://example.com/_next/image?url=%2Fhero.jpg&w=1200&q=75'

Vercel brings routing rules to Python projects

Vercel's changelog of 26 August adds routing rules to Python projects, covering FastAPI, Django and Flask apps. They can now set response headers and rewrite requests to internal paths, evaluated on the CDN before the request reaches the application, and changed without a new deployment. Vercel documents four configuration surfaces: the dashboard, the CLI, the Python SDK and vercel.json.

Non-breaking and additive, but it removes a real constraint. Header-level SEO controls on a Python app previously meant a redeploy or middleware inside the framework: X-Robots-Tag on a staging path, a Link canonical header on a non-HTML response, a rewrite that retires a legacy URL structure without a redirect hop. Moving those to the edge takes them off the application's critical path and out of the deploy cycle.

Worth a same-day change only if you already had a header or rewrite waiting on a deploy. Otherwise classify it as watch and pick it up the next time you touch routing. One caution: rules that live at the CDN are invisible in the application repository, so record them somewhere your team reviews — an edge rewrite nobody remembers is the origin of a great many canonical mysteries.

{
  "rewrites": [
    { "source": "/legacy-docs/:path*", "destination": "/docs/:path*" }
  ],
  "headers": [
    {
      "source": "/internal/:path*",
      "headers": [
        { "key": "X-Robots-Tag", "value": "noindex, nofollow" }
      ]
    }
  ]
}

Ship today

1. Upgrade sharp to 0.35.4 or later anywhere you call it directly — that is how the patched libheif 1.23.2 reaches your build.
2. Upgrade Astro to 7.2.8, which raises the sharp floor for you, and re-run a status-code crawl to catch anything 7.2.7's route-selection fix changed.
3. Bump web-vitals to 6.2.1 and discard INP phase data collected from the v6 line before this patch.
4. Leave images.formats pinned to WebP. AVIF is re-enabled in canary only; delete the pin when it reaches a stable tag.
5. If you sit behind Cloudflare, replay an image-optimizer URL as Googlebot and confirm the new Block-mode rules return 200.
6. Still on Next.js below 16.3.3 or 15.5.24: upgrade now. Both critical advisories remain unpatched below those versions, and the Windows RCE has no workaround.