Service workers can make a website feel faster, support offline experiences, and give a progressive web app more control over how requests are answered. They can also create difficult debugging cases when an old HTML document, script, stylesheet, or API response continues to appear after the origin has changed. For technical SEO, the key issue is not that service workers are inherently harmful. The issue is whether the public URL continues to return the correct, current, crawlable document and whether a browser-only cache makes the experience differ from the response available to a search crawler or a first-time visitor.
This guide explains service workers in practical terms for WordPress owners, developers, and SEO specialists. It covers cache strategies, lifecycle behavior, update deployment, JavaScript rendering, stale content, redirects, robots directives, troubleshooting, and safe release procedures. It does not assume that every WordPress website needs a service worker. Many small business websites are better served by ordinary HTTP caching and a well-configured CDN. Use service workers when the product needs offline or app-like behavior, then test their effect rather than installing one solely because it appears in a performance checklist. For related context, see My Advisers’ JavaScript hydration SEO guide and HTTP caching guide.
What a service worker is
A service worker is a browser-managed script that runs separately from a page’s main JavaScript thread and can respond to certain events, including fetch events for requests within its scope. It can return a network response, a response from the Cache API, a synthesized response, or an error. That flexibility supports offline pages, resilient navigation, cached assets, background synchronization and progressive web app patterns. It does not have unrestricted access to the document DOM, and it is not the same thing as a server-side cache, a WordPress page-cache plugin, or a CDN cache.
Service workers are normally restricted to secure contexts such as HTTPS, with localhost treated as a development exception. A registration has a scope, usually limited by the location of the worker script unless permitted configuration broadens it. The worker may be installed and active even when no page is currently using it, but it does not run as a permanently running server. Browsers start and stop it as needed. MDN’s Using Service Workers guide explains the lifecycle and request interception model. Understanding those boundaries helps teams avoid treating a service worker as a universal fix for slow server responses or indexing problems.
Service workers are not a direct SEO ranking switch
A service worker is a delivery and application architecture feature, not a direct ranking switch. Google Search generally discovers URLs through links and sitemaps, requests resources, processes the response, and may render JavaScript when needed. A browser service worker can affect requests made by a browser profile that has registered it, but it should not be assumed to control how Googlebot fetches every public URL. Search systems may not share a returning visitor’s service-worker installation or local cache state. That difference is precisely why the origin’s normal HTTP response and rendered output must remain correct.
The SEO objective is therefore to preserve crawlability, indexable content and predictable responses while delivering the app experience users need. Do not promise that adding a service worker will improve rankings, and do not blame a service worker for every indexing delay. When a page is missing from search, first inspect the URL response, robots rules, canonical, internal links, rendered content, server logs and Search Console evidence. Then investigate whether a service worker is producing a stale or broken browser experience. Google’s JavaScript SEO basics is a useful baseline for ensuring that content and links are accessible to search systems.
Service worker cache versus HTTP cache and CDN cache
The browser’s HTTP cache, the Cache API used by service workers, a WordPress full-page cache, an object cache, and a CDN edge cache are separate mechanisms. They may store related responses, but their keys, expiration rules, invalidation behavior and control points differ. A service worker can intercept a request before the browser uses its ordinary network path and can return an application-managed cached response. A CDN cache usually acts between the visitor and the origin. A WordPress page cache may store generated HTML before it reaches the CDN. Clearing one layer does not necessarily clear the others.
This distinction explains why a page can appear updated in a command-line request but old in one browser, or why clearing a WordPress plugin’s cache does not resolve a stale app shell. A reliable troubleshooting plan identifies each layer and tests it independently. Keep HTTP cache headers appropriate for the resource, define service-worker cache versioning, and document CDN purge behavior. Do not use the phrase ‘clear the cache’ without naming which cache. For a broader explanation of browser and intermediary behavior, review the My Advisers guide to ETag, Last-Modified, Cache-Control and 304 responses.
How the service worker lifecycle works
A service worker typically moves through registration, installation, waiting, activation and event handling. During installation, the script can populate a named cache with required resources. When installation succeeds, the new worker may wait until pages controlled by the old worker are closed before it activates. During activation, code often removes obsolete cache versions and prepares the worker to control clients. Later, fetch events can be intercepted for requests in the worker’s scope. The browser manages this lifecycle; developers should not assume that saving a new worker file means every open tab is instantly using it.
Lifecycle choices matter for SEO-related debugging because a visitor may have a page controlled by an older worker while a new worker is waiting. An immediate activation strategy can reduce update delay but may cause the new worker to control pages whose HTML was loaded under the previous version. If assets, routes or cache formats changed incompatibly, that transition can create broken pages. Use a coordinated release strategy: keep new code compatible with the previous app shell where possible, version caches deliberately, and test upgrade paths with an existing installation rather than only a fresh browser profile.
The fetch event and response selection
The fetch event is the main mechanism through which a service worker can intercept requests for navigation documents and subresources within its scope. A handler can inspect the request URL, method, destination, mode, credentials and other properties, then choose a response strategy. If the handler does not call respondWith for a request, the browser can continue with its normal fetch behavior. A handler that responds to every request without careful routing can unintentionally intercept forms, API calls, cross-origin assets, redirects, or responses that should not be cached.
MDN’s fetch event reference explains the request interception model and examples. For production code, keep the routing rules explicit. Treat navigation documents differently from static assets and data requests. Do not cache non-GET requests by default, and avoid storing personalized responses in a shared app cache. Make the network fallback intentional, define behavior when both cache and network fail, and ensure errors are handled in a way that does not silently turn a legitimate page into an empty or misleading document.
Choose a cache strategy by resource type
Common strategies include cache-first, network-first, stale-while-revalidate, network-only and cache-only. Cache-first is useful for immutable, versioned assets that rarely change at the same URL. Network-first can suit navigation or data that should normally be current, with a carefully designed fallback for offline use. Stale-while-revalidate can display a cached response quickly while fetching an update in the background, but it deliberately permits a period of stale content. Network-only is appropriate when freshness or security requires a live request, while cache-only should be reserved for resources whose availability in cache is guaranteed.
Do not choose one strategy for every request. A static logo, a hashed JavaScript bundle, a public article, a logged-in account page, and a search API have different freshness and privacy requirements. An offline fallback may be acceptable for a generic help page but misleading for a page that displays live prices, availability or account status. Write down the reason each resource is cached, its maximum acceptable age, the invalidation trigger and the behavior when the network is unavailable. That policy is more important than the name of the strategy.
Cache-first: best for immutable assets
In a cache-first strategy, the service worker looks for a matching cached response and returns it when available. If the response is absent, it fetches from the network and may store a successful result. This can make repeat visits fast and reduce network requests for stable assets. It works best when the URL changes whenever the content changes, such as a hashed file name generated by a build pipeline. If the file changes but the URL remains the same, a cache-first strategy may keep serving the old version until an explicit update or expiration occurs.
WordPress sites often use plugin-generated CSS and JavaScript URLs that are not content-hashed in the same way as modern application bundles. Some plugins append version parameters, but the service-worker cache logic must still treat changes correctly. Avoid assuming that a WordPress update will automatically invalidate every service-worker cache. If the URL remains constant, use a controlled cache version, update the entry when a new response is received, or choose a network-aware strategy. Test after changing themes, plugins, menus and critical page templates.
Network-first: prefer current navigation content
Network-first attempts a live request and falls back to a cached response if the network request fails or meets a defined timeout. It can be useful for navigation documents that should usually reflect the latest content while still providing a degraded offline experience. The timeout must be selected carefully: an extremely short timeout can cause unnecessary cache fallbacks on slow networks, while a very long timeout can make the page feel broken before fallback occurs. The cached fallback should be clearly identified as potentially old when freshness matters.
For a public content site, stale navigation can create SEO-adjacent problems if the browser continues to show removed content, old canonical annotations, outdated structured data or links that no longer exist on the server. That does not automatically mean the stale response is indexed by a search engine, but it can confuse users, support staff and QA teams. Make sure a network-first failure path does not fabricate a 200 response for content that has genuinely been removed. Where the server has a clear 404 or 410 response, do not overwrite it with a generic cached article without a deliberate user-experience reason.
Stale-while-revalidate: speed with a freshness trade-off
Stale-while-revalidate can return a cached response immediately and update the cache from the network in parallel. It is useful when a small delay in freshness is acceptable and speed is important. The cost is that the first response after a content change may still be old. For marketing pages, product details, legal notices or time-sensitive announcements, that trade-off should be evaluated explicitly. A stale-while-revalidate label is not a guarantee that the response will refresh in the current visit; the network update may fail or the new cache entry may not be used until a later request.
Define which data can safely be stale and for how long. A static icon can be cached for a long period when its URL is versioned. A public article may tolerate a short stale window if the origin remains authoritative and changes are not urgent. Account balances, payment status, stock availability and personalized information should not be handled as generic stale public content. Add monitoring for cache age, update failures and worker version. Provide a controlled cache invalidation mechanism for urgent edits, and test that a newly published page, a changed canonical, and a removed URL behave as intended.
Navigation requests and offline fallback pages
Navigation requests usually ask the browser for a document. Treat them differently from images, fonts and scripts. An offline fallback can tell a visitor that the network is unavailable, show cached help information, or offer links to previously saved content. It should not masquerade as the requested article or service page with a misleading title and body. If a navigation fails, a clear offline state is often better than returning unrelated cached HTML with a successful status. This protects the user from confusing content and makes debugging more transparent.
For a content website, consider whether offline functionality is actually required. A simple WordPress business site may not benefit enough to justify the complexity of a custom navigation cache. If a progressive web app is required, define a small, explicit offline page and ensure it is not treated as the canonical content for every route. Never rewrite the origin’s SEO status codes or canonical tags to suit an offline experience. Keep the real server response authoritative, and test online navigation, offline navigation, restoration after reconnecting, and the experience when the requested URL has been removed.
How stale content can affect users and SEO workflows
Stale content can create a mismatch between what a user sees and what the server currently publishes. A cached page might show an old phone number, an expired offer, an outdated product price, a retired service, a removed internal link or a previous version of a privacy notice. For SEO teams, it can also make audits inconsistent: a tester may report an old title or canonical while a fresh command-line request returns the updated page. The first step is to determine whether the stale response comes from the service worker, HTTP cache, CDN or origin page cache.
Keep a clear boundary between browser cache behavior and search indexing. A crawler may request the public URL without sharing the user’s service-worker installation or local cache, so a stale browser view does not by itself prove that Google indexed stale HTML. Conversely, a broken origin response or stale CDN cache can affect many clients and should be treated as a delivery issue. Capture the request URL, response body, response headers, worker controller state, cache name and timestamp. That evidence helps isolate the layer and avoids incorrect conclusions about indexing.
Service workers and JavaScript rendering
Search systems need access to the content and links that define a page. Service workers may influence a user’s browser rendering by returning cached HTML or scripts, but they should not be used as a substitute for server-delivered, crawlable content. A page that only reveals important text after a user interaction, relies on a cache that exists only after app installation, or hides links behind unsupported client-side behavior can create accessibility and discovery problems independent of the service worker. Public content should remain reachable through normal URLs and ordinary navigation.
Use server-rendered HTML or progressive enhancement where practical for important content. Ensure that internal links are actual anchor elements with valid href attributes, that navigation does not require a click handler alone, and that the initial response includes meaningful titles and metadata. Test the rendered page in a clean browser profile with no existing service-worker registration, then test an installed profile. Compare the two. Google’s JavaScript SEO documentation and My Advisers’ hydration troubleshooting guide provide complementary checks for rendered content and links.
Canonical tags, robots directives and structured data
The service worker should not become an alternate source of truth for canonical tags, robots directives, titles, descriptions or structured data. Those signals should be generated consistently for the requested URL and updated when the server content changes. If a cached HTML document contains a previous canonical URL, it may confuse a human QA test or a browser-based audit. The correct fix is to align cache invalidation and response strategy with the publication lifecycle, not to add random JavaScript overrides that conceal stale markup.
When a page changes from indexable to noindex, when a canonical target changes, or when structured data is corrected, include those changes in release testing. Inspect the server response and the rendered DOM. Verify that the robots meta tag is not unintentionally overridden by a stale app shell and that the page’s canonical points to the intended URL. A browser’s local cache should not be treated as proof of the public source. For related diagnostics, use the My Advisers guides to robots meta tags, canonicalisation, and structured-data validation.
Redirects, deleted pages and HTTP status codes
A service worker can return a cached response without making a new request to the origin, so a user may not immediately observe a new redirect or a removed page. The server’s status code remains important for crawlers and clients that reach the network. Do not use the worker to convert every failed request into a generic successful page, because that can hide genuine 404s, 410s or server errors from users and diagnostic tools. If an offline fallback is shown, make it a clearly identified user-experience fallback rather than pretending that the requested resource still exists.
When a URL is permanently moved, configure the appropriate server-side redirect and update internal links. When content is deleted, return the intended status from the origin and update sitemaps and links. Then test in a clean browser and in a profile with the service worker already installed. Verify both the network response and the visible page. A cached old document should not prevent the worker from eventually using the new redirect or status. This is especially important after URL migrations, site redesigns and WordPress permalink changes.
WordPress plugins that register service workers
Some progressive web app plugins, offline plugins, push-notification tools and custom themes can register a service worker. Before installing or updating such a plugin, check whether another component already registers a worker and what scope it controls. Two competing service workers at different paths may coexist, but overlapping scopes and unexpected registration behavior can make debugging difficult. Inventory the registration script, scope, cache names, update strategy and plugin owner. If a plugin provides no clear way to inspect or remove its worker, consider whether the feature is worth the operational risk.
After a plugin update, inspect the browser’s Application panel and service-worker registrations. Confirm the script URL and scope, identify active and waiting versions, and review Cache Storage entries. Do not delete all browser storage for every visitor as a first response to a production bug. Instead, fix the cache versioning or update logic so clients migrate safely. If the worker is no longer needed, unregister it through the supported plugin or application process and ensure the site no longer serves a registration script that immediately recreates it. Test this in staging before broad rollout.
Cache versioning and safe invalidation
Use explicit, meaningful cache names or versions so a new release can distinguish current assets from obsolete ones. During activation, remove only caches owned by the application and known to be outdated. Do not delete unrelated Cache Storage entries that belong to other features. When a cache entry is updated, make sure the URL or version key actually identifies the new content. A cache name change alone is not sufficient if the worker continues to match a broad old cache or if multiple versions are used inconsistently.
Plan cache invalidation around the content release process. A WordPress content edit may not require purging an immutable JavaScript bundle, but it may require the browser to fetch new HTML or an updated API response. A theme release may change styles and scripts together, so the deployment should avoid mixing an old HTML shell with incompatible new assets. Use versioned filenames where possible, keep backwards compatibility for transitions, and define how urgent changes invalidate caches. Test a first visit, a repeat visit, a worker update, and a recovery after network interruption.
Testing with a clean browser profile
A clean browser profile is essential because an existing profile may have a registered worker and cached responses from an earlier version. Open the target URL in a profile that has not visited the site, inspect the network response, and note the page content. Then test in a profile with the service worker installed and activated. Compare the initial HTML, response status, canonical, robots directives, internal links, script versions and visible content. If the results differ, inspect whether the worker is intercepting navigation or subresource requests and which cache entry it returns.
Chrome DevTools provides an Application panel for service workers and storage, and the Network panel helps identify whether requests reach the network or are served from a service worker. Browser labels and capabilities may vary, so use the current browser documentation for your test environment. Clear storage only in the test profile when isolating a case, and record what was cleared. Avoid treating an incognito test as a universal representation of all browsers, because private browsing, storage policies and extensions can change behavior. The goal is reproducibility across the relevant user journeys.
A debugging sequence for stale pages
When a page looks stale, preserve evidence before clearing everything. Record the exact URL, timestamp, browser version, visible text, active worker script URL, controller state, cache names and response headers. First load the URL in a fresh profile and compare it with the affected profile. If only the affected profile is stale, inspect service-worker Cache Storage and the ordinary browser cache. If both profiles are stale, inspect the CDN, WordPress page cache and origin. If only a specific geographic region is affected, compare CDN edge behavior and cache status.
Next, inspect the worker’s routing logic for navigation requests and the cache key used for the response. Check whether query parameters, locale, logged-in state or content variants are accidentally ignored. Confirm that a network update is stored and that the next request can use it. Test a known changed page and a known deleted page. Finally, verify that the worker update path is exercised when a new script is deployed. Document the root cause, then add a regression test so a future plugin or theme update does not reintroduce the same stale-content behavior.
Personalized content and privacy
Do not place private account pages, order histories, payment states, user-specific dashboards or other personalized responses into a general public cache. A service worker cache is scoped to the browser origin, but that does not automatically make every cached response safe to reuse for every account or session. Incorrect cache matching can expose information on a shared device or after a user signs out. Even where a browser keeps storage isolated per profile, the application still needs a clear policy for authentication, logout, token changes and cache cleanup.
For personalized routes, prefer a network-only strategy or a carefully designed authenticated cache with explicit privacy review and deletion behavior. Check how requests are keyed, whether credentials are included, and whether a response can be reused after a session changes. Do not assume that the server’s Cache-Control header alone prevents a custom service worker from storing a response; the worker’s code must also respect the intended policy. Treat logout and account switching as test cases. If offline access is required for private data, define the threat model and minimize what is stored locally.
Service workers, APIs and dynamic data
API responses often have different freshness and caching needs from static assets. A public, slowly changing taxonomy or help index may be cacheable with an explicit policy, while live availability, prices, inventory, payment status or user-specific data may need a fresh request. Avoid applying a cache-first rule to every URL under /api/ without examining the endpoints. A broad rule can return stale data, cache error responses, or reuse one query’s response for another request if the cache key is incomplete.
Use request method, URL, query parameters, response status and relevant headers to define safe API caching behavior. Do not cache failed responses as if they were valid content. If a response depends on locale, authorization, cookies or request headers, ensure the key and privacy policy reflect that dependency. For important public data, document the acceptable staleness window and how invalidation occurs after an update. Test offline and reconnect behavior so the interface distinguishes cached data from live data rather than silently presenting old values as current.
Performance: service workers are not a universal speed fix
A service worker can improve repeat-visit performance by serving resources locally and can make an application more resilient when the network is unavailable. It can also add script work, installation complexity, cache maintenance and debugging overhead. A first-time visitor may not benefit from a cache that has not yet been populated. If the worker delays navigation while it performs unnecessary cache lookups or blocks on a network strategy with a poor timeout, the experience can worsen. Evaluate the first visit and repeat visits separately.
For many WordPress sites, standard browser caching, efficient server caching, a well-configured CDN, smaller assets and optimized rendering provide most of the practical value without a custom worker. If a service worker is justified by offline requirements, measure its effect on navigation timing, LCP, INP and error rates. Compare performance with and without the worker in a controlled test. Use the My Advisers guides to INP optimization, CLS optimization, and TTFB diagnostics to identify the real bottleneck.
Offline behavior and search engine access
Offline behavior should be designed for the person who has no network connection, not used to replace the public site’s normal server behavior. A worker may show cached content while a visitor is offline, but search crawlers and fresh visitors must still be able to request the canonical public URL from the origin or CDN. Do not assume that a successful offline display proves that the page is available or indexable online. Likewise, an offline fallback does not mean the server should return a 200 status for every unknown route.
Keep the public site’s robots.txt, canonical tags, sitemap entries and HTTP status codes controlled by the normal delivery system. Test crawlability from a clean environment and inspect the actual HTTP response. If a service worker is used by a single-page application, ensure that deep links can load directly from the server rather than only after navigating from the homepage. A server fallback may be necessary for client-side routes, but it should return the intended application shell only for valid app routes and should not mask genuine missing URLs. This is a routing and status-code design task, not simply a cache setting.
Avoid caching robots.txt, sitemaps and critical control files incorrectly
Robots.txt and XML sitemaps influence how crawlers discover and request URLs, so they should not be trapped behind a stale application cache. These files are normally served from the origin or CDN with an appropriate freshness policy. A service worker that intercepts every navigation or same-origin request could inadvertently return an HTML offline page when a client requests a sitemap or robots.txt, especially if routing is based only on a broad URL pattern. Keep crawler-control resources outside generic app-shell fallback logic.
After deploying a worker, request robots.txt and the sitemap directly in a clean browser and from the command line. Confirm the status code, content type, body and freshness headers. Test after changing robots rules or publishing new sitemap entries. The service worker is not needed to make these files available offline, so the safest policy is generally to let their normal network request proceed. For deeper checks, consult the My Advisers guides to XML sitemaps and Google Search Console URL Inspection.
Release checklist for a WordPress site using a worker
- Identify the plugin, theme or custom code that registers the worker.
- Record the script URL, scope, active version, waiting version and cache names.
- Test navigation, CSS, JavaScript, images, APIs and error responses separately.
- Compare clean-profile behavior with a profile that has an existing worker.
- Ensure canonical tags, robots directives, titles and structured data are current.
- Confirm that redirects, 404s and 410s from the origin are not hidden by a generic fallback.
- Exclude private or personalized responses from public caches.
- Version cache names and remove only obsolete caches owned by the application.
- Test first visit, repeat visit, update, offline, reconnect and rollback paths.
- Document how to unregister the worker and restore normal network behavior if needed.
Competitor-informed implementation principles
Practical progressive web app tutorials often emphasize precaching a small application shell, selecting a caching strategy by resource type, and using a service-worker library to reduce implementation errors. Those are useful foundations, but a production SEO workflow also needs to test the public HTTP response, deep links, removed URLs, canonical and robots changes, cache version transitions, and differences between clean and returning browser profiles. The service worker should improve a defined user journey rather than become a hidden layer that makes the site difficult to audit.
MDN’s service-worker documentation focuses on browser lifecycle, request interception and the Cache API; web.dev and Workbox material often emphasizes common performance patterns and safe caching strategies. Use these resources to understand the mechanisms, then adapt them to the actual WordPress architecture. A plugin that works for a static app shell may be unsuitable for dynamic marketing content or authenticated account pages. Keep the implementation small, make its policy explicit, and use the origin as the source of truth for public content and HTTP status.
Troubleshooting decision table
- If only one existing browser shows old content, inspect that profile’s worker registration and Cache Storage first.
- If clean profiles and command-line requests are also stale, inspect WordPress page cache, CDN cache and origin content.
- If deep links fail on first load, verify server routing and the worker’s navigation handling.
- If removed pages still appear offline, check cached document rules and make the offline state explicit.
- If a canonical or robots directive is outdated only in the browser, compare cached HTML with the current origin response.
- If private data appears after account switching, stop the affected cache strategy and review logout, cache keys and stored responses.
- If the worker update never takes effect, inspect script caching, lifecycle state and whether an old page still controls the worker.
- If robots.txt or the sitemap returns HTML, remove those paths from generic app-shell fallback handling.
Frequently asked questions
Does Googlebot use my service worker cache?
Do not assume Googlebot shares a returning visitor’s installed service worker or browser cache. Keep public content accessible through normal URLs and verify the server response, rendered output, links and indexing signals directly.
Should every WordPress website have a service worker?
No. A conventional business site may be better served by ordinary HTTP caching and a CDN. Add a service worker when there is a clear requirement, such as offline support, and when the team can maintain and test its lifecycle.
Can a service worker cause stale content?
Yes. Cache-first and stale-while-revalidate strategies can deliberately serve cached responses. Version caches, define freshness requirements and test updates so changed pages, scripts and metadata do not remain stale longer than intended.
Can I cache HTML for SEO?
HTML can be cached, but the strategy must preserve freshness, status codes, personalization boundaries and URL-specific metadata. For many content sites, server or CDN caching is easier to operate than a custom browser-level HTML cache.
How do I clear a service worker cache?
Use browser developer tools for diagnosis or update the worker’s own versioned cache cleanup logic. Do not rely on asking every visitor to clear browser data; production code should migrate safely and remove only caches owned by the application.
Authoritative references and further reading
Start with MDN’s Using Service Workers, the fetch event reference, and its documentation on the Cache API. For SEO, review Google’s JavaScript SEO basics and lazy-loading guidance. These sources describe distinct parts of the system; no single one replaces testing the actual website.
For implementation context, consult web.dev’s progressive web app learning resources and Workbox caching strategies. Compare their common app-shell and caching patterns with the requirements of your WordPress site, especially where pages are frequently edited or include personalized data. Relevant My Advisers resources include the JavaScript hydration guide, robots meta tag guide, and XML sitemap guide.
Final recommendations
Treat a service worker as application infrastructure that needs an explicit policy, owner and regression tests. Choose caching strategies by resource type, avoid caching personalized responses indiscriminately, and make cache invalidation part of the release process. Preserve normal HTTP status codes and ensure that every important public URL can be requested directly without a previous browser installation. A service worker should not be required for search engines or first-time visitors to discover the core content of a public website.
When troubleshooting, compare a clean browser profile, an existing installed profile, the public network response and the origin or CDN evidence that is available to you. Keep canonical tags, robots directives, sitemaps and redirects authoritative at the server layer. Use service workers for the user benefits they can genuinely provide, and use measured performance and crawlability evidence to decide whether the complexity is justified. That approach protects the user experience while keeping technical SEO predictable and maintainable.