Skip to content
Oday Bakkour
Back to Knowledge Hub

Daily SEO Note — August 11, 2026: SvelteKit 3 Makes Cross-Page Form Actions Navigate

Oday Bakkour profile photo
Oday Bakkour
7 min read
Share
Daily SEO Note — August 11, 2026: SvelteKit 3 Makes Cross-Page Form Actions Navigate

1. SEO for Content Writers

The writer track produced no verified change in the last 24 hours: Google logged nothing to its ranking, spam, policy, or SERP-appearance surfaces, and no writer-facing documentation page was revised inside the window. Today's only confirmed movement is on the engineering side, in Section 2.

No Verified Editorial Change in the Last 24 Hours

What changed: nothing. The Search Status Dashboard reports no incidents across Crawling, Indexing, Ranking, and Serving as of 10 August 2026, 23:06 PDT (11 August 06:06 UTC). There is no open core update, spam update, or Discover incident. Rollout status: nothing in flight.

The Search Central Blog has still published nothing in August 2026 — its newest posts are from July. The documentation changelog's most recent entry remains 29 July 2026. Spot-checking the writer-facing guidance directly confirms it: Search Essentials and the AI features guide both still carry a last-updated stamp of 10 December 2025, and the spam policies 15 May 2026. None fall inside today's window.

Three items surfaced during detection and were rejected on date or sourcing. Gemini 3.5 Flash-Lite reaching Google Search was announced 21 July 2026; the Search Console generative-AI performance report began rolling out 3 June 2026 and platform properties on 7 July 2026 — all three are ongoing rollouts already covered in this series, with no status change today. A widely repeated claim that Google-NotebookLM has been renamed to Gemini Notebook with the old user agent retired in August 2026 does not appear anywhere in Google's crawler documentation, which was last updated 14 July 2026. Treat it as unconfirmed.

Apply to Your Next Brief

  • No brief changes today. Carry forward the current guidance — there is no new ranking, policy, or SERP-feature signal to write against.
  • If your site runs SvelteKit, flag every form-driven page to engineering before the next publish cycle. The URL a reader lands on after submitting a form is changing, which affects the page they can bookmark, share, and be linked from.
  • Verify any crawler or AI-surface instruction in a brief against Google's crawler documentation before it ships. Several user-agent rename claims circulating this week are not reflected there.

2. SEO for Developers

The consequential change today is SvelteKit 3.0.0-next.17, which makes enhanced cross-page form submissions navigate to the action page on both success and failure. It is a breaking change to which URL the browser ends up on, so it belongs to anyone who cares about canonical URLs and shareable result pages. A second SvelteKit prerelease and a Next.js canary fix round out the window.

Breaking: SvelteKit 3 Navigates to the Action Page on Cross-Page Form Submissions

Version and date: @sveltejs/[email protected], published to the npm next tag on 10 August 2026 at 08:56 UTC. The change lands via PR #16684, merged 7 August 2026. Rollout status: prerelease on the 3.0 line, not yet stable.

Breaking. Previously an enhanced form submitting to a different page applied the result in place and left the URL alone. Now it navigates to the action page on success and on failure, matching native browser form behavior. Named-action parameters are stripped from the destination URL, and successful submissions refresh data by default while failed ones do not. The symptom if you ignore it: after upgrading, users submitting a cross-page form land on a different URL than before, so any canonical tag, analytics rule, or internal link that assumed the origin URL is now pointing at the wrong page — and the action page becomes a real, linkable destination that you may never have audited for indexability.

What to change: audit every route with a cross-page action attribute. Where the old in-place behavior is what you want, both update and applyAction now accept navigate: false. Where the navigation is correct, make sure the action page is a page you are willing to have indexed and linked.

src/routes/contact/+page.svelte
<script>
  import { enhance } from '$app/forms';
</script>

<!-- Cross-page action: in next.17 this now NAVIGATES to /contact/submit -->
<form method="POST" action="/contact/submit" use:enhance={() => {
  return async ({ update }) => {
    // Opt back into the pre-3.0 behaviour: apply the result, stay put.
    await update({ navigate: false });
  };
}}>
  <input name="email" type="email" required />
  <button>Subscribe</button>
</form>

SvelteKit 3.0.0-next.18 Makes Adapter Vite Plugin pre and post Individually Optional

Version and date: @sveltejs/[email protected], published 10 August 2026 at 19:13 UTC, via PR #16711, merged the same day. Rollout status: prerelease on the 3.0 line.

Listed as breaking in the changelog, though in practice it corrects a type-versus-runtime mismatch: the TypeScript types demanded both pre and post plugin arrays while the runtime already treated them as optional. Both are now individually optional. This matters for SEO because build-time artifacts — sitemaps, prerendered HTML, generated hreflang maps — are frequently emitted by exactly these adapter plugins, and the pre versus post slot decides whether your generator runs before or after SvelteKit writes its output. The symptom if you ignore it: a custom adapter that previously shipped an empty array to satisfy the types keeps working, but authors who now omit a slot entirely should confirm their sitemap step still fires in the right order.

adapters/my-adapter/index.js
/** @returns {import('@sveltejs/kit').Adapter} */
export default function adapter() {
  return {
    name: 'my-adapter',
    // next.18: declare only the slot you need — no empty-array filler.
    plugins: {
      post: [emitSitemap()] // runs AFTER SvelteKit writes its build output
    },
    async adapt(builder) {
      builder.writePrerendered('build/prerendered');
    }
  };
}

Next.js 16.3.1-canary.11 Encodes the unstable_cache Item Name for Non-ASCII URLs

Version and date: [email protected], published 11 August 2026 at 00:03 UTC. The fix is PR #96937, merged 10 August 2026, with a supporting rename of encodeCacheTag to encodeHeaderSafe in PR #96936. Rollout status: canary only — not in a stable release.

Non-breaking, and backward compatible: names that were already representable are unchanged. The bug it fixes is one that disproportionately hits multilingual and international sites. Cache metadata travels through HTTP headers, which are limited to Latin-1, so a non-ASCII character in the request URL or the callback name could cause unstable_cache to fail silently. Localized routes with accented or non-Latin query parameters were the reported trigger. The item name is a diagnostic label rather than the cache key itself, so the practical symptom was a caching operation that errored instead of caching — which on a localized route means uncached, slower responses on exactly the pages you localized.

What to change: nothing yet, because it is canary. Track it, and if you run localized routes through unstable_cache today, give the cache a stable explicit key array rather than relying on an inferred name — that is good practice regardless of this fix.

app/[locale]/products/page.tsx
import { unstable_cache } from 'next/cache';

// Pass an explicit ASCII key array. Do not rely on an inferred
// name derived from a URL that may contain non-ASCII characters.
const getProducts = unstable_cache(
  async (locale: string) => fetchProducts(locale),
  ['products-by-locale'],          // explicit, ASCII-safe key parts
  { revalidate: 3600, tags: ['products'] }
);

export default async function Page({
  params
}: {
  params: Promise<{ locale: string }>;
}) {
  const { locale } = await params;
  const products = await getProducts(locale);
  return <ProductGrid products={products} />;
}

Checked, No Action

Lighthouse produced only a nightly build, 13.4.1-dev.20260810, on 11 August at 05:31 UTC; there is no new stable release and no audit change to act on. Schema.org remains at version 30.0 from 19 March 2026. Cloudflare's only 10 August post was an Agents Week recap containing no new crawler or robots.txt control — the AI-bot default change on 15 September 2026 is unchanged and already covered in this series. Next.js shipped no stable release, and no new CVE or GHSA advisory landed against an SEO package inside the window; the Yoast and Rank Math advisories circulating in search results date from March and June 2026.

Ship Today

  1. If you are on the SvelteKit 3 prerelease line, audit every cross-page form action and decide per form whether to accept the new navigation or opt out with navigate: false.
  2. For each cross-page action page that will now receive real navigations, confirm it returns an indexable, canonical-correct response — or a deliberate noindex if it should never be a landing page.
  3. If you ship a custom SvelteKit adapter, pin to next.18 and declare only the plugin slot you use, then verify your sitemap or prerender step still runs in the intended order.
  4. Replace inferred unstable_cache names with explicit ASCII key arrays on any localized route, ahead of the canary fix reaching stable.
  5. No Google-side action. Nothing shipped to a ranking, policy, or crawler surface inside the window.
Add Oday Bakkour as a preferred source on Google

Comments

Share your thoughts and join the conversation

Leave a Comment

Loading comments...
RELATED