IndexNow URL Submitter: Code Examples

IndexNow on WordPress

If you run WordPress, IndexNow usually reaches search engines through the official Microsoft plugin rather than WordPress core. The "IndexNow" plugin by Microsoft (version 1.0.3) from the WordPress.org plugin directory hooks into the transition_post_status event¹ and submits the corresponding URL to api.indexnow.org in the background each time a post is published or moved to trash, without requiring any PHP customization or manual API calls.

Powering around 43% of all websites², WordPress produces the largest share of IndexNow pings that Bing, Yandex, Naver, and other engines receive. Because the plugin triggers on every WordPress post-type lifecycle event, sites with large editorial teams or automated publishing pipelines can generate hundreds of submissions per day. Consequently, understanding the plugin's event triggers, its settings location, and its known edge cases is the fastest way to avoid phantom submissions and keep your IndexNow quality signal clean.

Native vs plugin path

No native IndexNow support exists in WordPress core as of mid-2026³. The official path is the "IndexNow" plugin by Microsoft, version 1.0.3 (WordPress.org)⁴, installed at Plugins → Add New → search "IndexNow" → Install Now → Activate. Settings appear as a top-level IndexNow menu item in the WordPress admin, where you can review the auto-generated key value and verify that the key file is correctly placed at yoursite.com/[key].txt. After activation, the plugin auto-generates a verification key and places a key file at yoursite.com/[key].txt, which satisfies the IndexNow key-file validation step without requiring any manual file upload or server configuration.

Event triggers and noindex filtering

The plugin hooks into the transition_post_status WordPress action¹, submitting the affected URL to api.indexnow.org each time a post is published or moved to trash. If your SEO plugin marks pages as noindex, check the submitter log and deactivate automatic submission before relying on filtered manual pushes. The plugin does not distinguish between a page that should be indexed and one flagged as noindex by Yoast, Rank Math, or AIOSEO⁵, which means it happily sends crawl signals for pages that search engines will ultimately discard, wasting your crawl quota on URLs that will never appear in results.

Real user issues

Submitting noindex pages is the most-documented issue. With automatic submission enabled, the plugin fires on all post types including pages marked as noindex by a SEO plugin such as Yoast or Rank Math (GitHub issue #60 on the microsoft/indexnow-wordpress-plugin repository⁵, active as of 2026). Search engines receiving noindex-tagged URLs via IndexNow may choose to crawl without indexing, which is correct behavior but wastes crawl quota. A second user-reported issue from the WordPress.org support forum involves the plugin's dashboard script (main.6b93cffc.js) loading repeatedly on admin pages, causing measurable back-office slowdown on high-traffic sites. Both issues remain open as of the research date.

When to fall back to a manual tool

Several scenarios make a manual submitter cleaner than the plugin. Bulk URL migration, where hundreds of old URLs need submitting after a permalink restructure, is one; the plugin only fires on individual post lifecycle events and does not cover mass database changes. A second scenario is staging-to-production cutovers, where the plugin may fire against the staging domain unless explicitly disabled. Third, multi-site WordPress networks require separate plugin installations per site, and license management becomes friction. Fourth, the noindex issue described above means any site running a strict noindex policy benefits from manual submission control rather than relying on the plugin's automatic filter.

WordPress Multisite and per-site IndexNow plugin configuration

WordPress Multisite runs multiple sites from a single WordPress installation, with each site operating under its own domain or subdomain. The official IndexNow plugin must be installed and activated per site in a Multisite network; network-level activation does not push the plugin's settings to all subsites automatically. Each site generates its own key file and places it at that site's domain root, satisfying the per-domain verification requirement without sharing keys across the network.

Subdirectory-based Multisite setups (where subsites live at example.com/site1, example.com/site2) create a complication: the key file for site1 must be accessible at example.com/site1/[key].txt, but the IndexNow protocol validates key files at the domain root. Consult the plugin's documentation for subdirectory Multisite before activating, as this configuration may require a custom key file path rewrite rule in the server configuration.

Network-level submission management for Multisite

For large WordPress Multisite networks, managing individual plugin installations per site becomes operationally heavy. A custom network plugin that hooks into WordPress core's publish events network-wide and routes submissions through a centralized IndexNow API call can replace per-site plugin installations. Each submission includes the site's specific domain and key, drawn from a network-level options table, keeping key management centralized while submission logic remains consistent.

Keep the network key table in version control so a plugin update or server migration never silently drops a subsite's credentials. When a subsite's key changes, regenerate the key file at that subsite's root and update the options table entry in the same step, because a mismatched key between the file and the API call triggers silent rejection that the centralized script may not surface as an error. Logging each network-wide submission with its domain and timestamp gives you an audit trail when a particular subsite drops out of the index.

Headless WordPress and IndexNow submission from the frontend build pipeline

Headless WordPress decouples content management from page rendering: editors create content in the WordPress admin, and a separate frontend application (Next.js, Gatsby, Astro) builds or serves the public pages. The official IndexNow plugin fires its submissions when a post is published in WordPress, but the public URL that search engines should crawl belongs to the frontend domain, not the WordPress admin domain. This domain mismatch means the plugin submits the wrong host unless configured to target the frontend URL.

The correct approach for headless setups fires IndexNow submission from the frontend build pipeline, not from the WordPress plugin. When the frontend application builds or deploys after a WordPress content update (triggered via a WordPress webhook to a build service like Vercel or Netlify), a post-build step collects the changed page URLs and POSTs them to the IndexNow endpoint using the frontend domain's key. This ensures the submitted URLs match the canonical URLs that engines will find when they fetch.

WordPress REST API webhooks for real-time headless submission

WordPress 6.x exposes a REST API⁶ that can fire webhook events on post publish. Configure a custom action in functions.php that triggers on publish_post and sends an HTTP POST to your frontend's webhook endpoint, which then calls the IndexNow API with the corresponding frontend canonical URL. This real-time path is faster than waiting for the next scheduled frontend build and ensures new articles reach the IndexNow priority queue within seconds of the WordPress publish event.

When to use this

Use the WordPress IndexNow plugin for the standard publish and update workflow on a single-site install. Use a manual submitter for bulk legacy URL pushes, permalink restructuring, staging-to-production cutovers, or whenever the plugin silently submits pages you want excluded.

Notes

Install the official "IndexNow" plugin by Microsoft (v1.0.4, top-level IndexNow menu), which hooks into the transition_post_status event and auto-generates your key file. The biggest gotcha: the plugin submits noindex-tagged pages, so verify your SEO plugin's noindex settings do not conflict with pages you want to keep out of search crawl queues.

Examples

WP Admin → Plugins → Add New → search "IndexNow"
→ Install Now → Activate
→ IndexNow → paste/generate API key → Save

# Use CapyToolkit's submitter when changing permalink structure:
# 1. Export old URLs from WP CLI: wp post list --format=csv --fields=ID,url
# 2. Paste the list into the submitter
# 3. Then add the new URLs in a second batch

Try in the tool

IndexNow on Shopify

Shopify supports IndexNow natively as of May 2025¹, but the native integration handles submission through Shopify's structured data feed rather than a simple admin toggle, and stores that need granular control over which URLs are submitted, variant filtering, or custom key file placement often still rely on a third-party app. Several apps offer this, including "IndexNow: for Bing and Yandex" available on the Shopify App Store, with plans starting at $5 per month for automated submission.

Shopify powers millions of storefronts globally², and its product catalogue structure generates a uniquely high volume of indexable URLs. Each product variant, such as a different color or size, receives its own canonical URL, which means a store with 500 products and 10 variants each produces 5,000 potential IndexNow submission targets. Consequently, submitting every variant URL on every price or inventory change would overwhelm search engine crawl budgets; understanding which URLs to submit and when is the central IndexNow challenge for Shopify stores.

Native vs plugin path

Shopify integrated IndexNow natively in May 2025¹³, meaning submissions flow through Shopify's structured data feed without requiring a separate app installation. However, the native path offers limited control over which specific URLs are submitted, and stores that need variant filtering, custom key file placement, or granular submission control often still benefit from a Shopify App Store app such as "IndexNow: for Bing and Yandex," which handles key file generation and auto-submits product, collection, and blog post URLs on publish and update events.

Canonical product URL filtering

Installation follows the standard Shopify app flow: navigate to the App Store, install the app, authorize the required permissions, and the app activates IndexNow submission in the background. Before you submit a large import, filter out variant query-string URLs so the app or manual batch contains only canonical product URLs. Because Shopify assigns every product variant its own URL with a unique query parameter, a store with hundreds of SKUs can easily generate thousands of variant addresses that all canonicalize to the same base product page, and submitting each one individually creates unnecessary noise in the IndexNow queue without any indexing benefit.

Real user issues

Variant URL noise is the most-discussed Shopify IndexNow problem among e-commerce SEO practitioners. A product page at yourstore.com/products/sneakers generates variant URLs like yourstore.com/products/sneakers?variant=12345 for each color and size combination. Submitting each variant URL individually floods the IndexNow endpoint with low-value pings, because Shopify's canonical tag points all variant URLs to the base product URL. Submitting only the canonical product URL (without variant parameters) avoids the noise. Yet another reported issue is app conflicts when multiple marketing or SEO apps fire submission requests for the same URL on the same publish event, producing duplicate pings within the protocol's deduplication window. Store owners running Shopify Markets for international sales should also verify that the app submits only primary-market canonical URLs, because locale-variant paths can generate redundant pings that waste crawl budget without improving international indexing outcomes.

When to fall back to a manual tool

Several Shopify scenarios require manual submission. Bulk catalogue imports via CSV do not trigger the app's event hooks, so newly imported products need a manual submission batch. Collection URL changes during a site restructure similarly bypass app event listeners. Furthermore, submitting deleted product URLs (returning 404 or 301 to a replacement) is often not handled by Shopify IndexNow apps, making a manual submitter the cleaner option for removal signals. Multi-currency and multi-language Shopify Markets setups may also generate duplicate URL submissions unless the app is configured to filter alternate-locale variants. A final scenario involves headless Shopify storefronts built with Hydrogen or custom React frameworks, where the standard app hooks into Shopify admin events but the public-facing storefront runs on a separate domain that the app cannot verify, making manual submission the only reliable path for those architectures.

Shopify Markets multi-locale URLs and IndexNow canonical submission

Shopify Markets generates locale-specific URL paths for each active market. A product at yourstore.com/products/sneakers appears as yourstore.com/fr/products/sneakers for the French market and yourstore.com/de/products/sneakers for the German market. Each locale URL carries a canonical tag pointing to the primary market URL, so submitting locale variants produces the same result as submitting the canonical: the engine follows the canonical tag and indexes the primary URL.

Submit only the primary-market canonical product URL for each product, not the locale variants. This keeps the IndexNow submission list proportional to your actual product catalogue size rather than multiplying it by the number of active markets. For the locale-specific pages to rank in those markets, search engines rely on the hreflang tags rather than on separate IndexNow submissions per locale.⁴

Submitting primary-market URLs after a Shopify Markets setup

When you first activate Shopify Markets and locale URLs are generated for existing products, submit a batch of your top canonical product URLs via IndexNow. This prompts engines to re-crawl those pages and discover the newly added hreflang tags pointing to the locale variants, accelerating the international indexing signal chain without requiring individual submissions for each locale path. After the initial batch, subsequent product updates only need the primary-market URL submitted, because search engines that have already discovered the hreflang relationships will follow them to the localized versions during their normal crawl cycles.

Schedule the initial Markets batch during a low-traffic maintenance window if your catalogue is large, because re-crawling thousands of canonical URLs at once consumes crawl budget that you would otherwise spend on new product discovery. A staggered approach, submitting a few hundred top sellers first and the long tail over the following days, keeps the priority queue responsive to genuinely time-sensitive price and inventory changes. Monitor your Bing and Yandex crawl reports after the batch lands to confirm the locale hreflang signals were picked up before you move on to the next market.

Shopify Plus headless storefronts and IndexNow via the Storefront API

Shopify Plus merchants running headless storefronts via Hydrogen or a custom React framework bypass the standard Shopify lifecycle events entirely. The Shopify App Store IndexNow app hooks into Shopify admin events, but a headless storefront renders pages from a separate application layer that does not trigger those same lifecycle hooks. Consequently, headless stores need a custom submission path rather than a Shopify App Store app.

Shopify supports webhook events for product and collection updates through its Admin API, enabling headless storefronts to trigger IndexNow submissions from the frontend build pipeline. Subscribe to product and collection update webhooks and build a lightweight serverless function that receives those events, constructs the canonical storefront URL for the affected product or collection, and POSTs it to the IndexNow endpoint. Vercel Functions, Cloudflare Workers, and AWS Lambda are all suitable runtimes for this pattern.

Key file placement for headless Shopify storefronts

In a headless Shopify setup, the storefront runs on a custom domain separate from the Shopify admin domain. The IndexNow key file must be placed at the root of the custom storefront domain, not the myshopify.com admin domain.⁵ Serve the key file as a static asset from your headless framework's public directory, and verify its reachability at https://[your-custom-domain]/[key].txt before sending any IndexNow submissions. If the key file is accidentally placed on the myshopify.com admin domain instead of the custom storefront domain, all IndexNow submissions from the storefront URLs will fail the silent validation check, because the protocol matches the submitted URL's host against the key file location and rejects any request where the two do not align.

When to use this

Use a Shopify App Store IndexNow app for standard product publish and update events. Use a manual submitter for bulk catalogue imports, product deletions, collection restructures, or any batch operation that bypasses the app's event hooks.

Notes

Shopify supports IndexNow natively as of May 2025, but stores needing granular control over variant filtering or custom key file placement often still use a third-party App Store app. Submit only canonical product URLs, not variant query-string URLs. Bulk CSV imports and deletion signals need manual submission since the native path and most apps handle only lifecycle events.

Examples

Shopify Admin → Apps → App Store → search "IndexNow"
→ Install "IndexNow: for Bing and Yandex" → Authorize permissions
→ App auto-generates key file and enables submission

# After CSV import, extract canonical product URLs:
# Admin → Products → Export as CSV → filter URL column
# Paste canonical product URLs (no ?variant= parameters)
# into CapyToolkit's submitter for one-time batch submission

Try in the tool

IndexNow on Wix

With built-in IndexNow support on Premium plans, Wix pings the protocol endpoint whenever you publish or update site content without requiring any plugin installation, key file upload, or API configuration from the site owner.¹ Wix manages the verification key file on the platform side, so the verification step that trips up users on other site builders is handled invisibly.

On Wix, IndexNow covers page publishes, blog post updates, and content changes across site pages. Consequently, editorial sites and small business owners get the protocol's crawl acceleration benefits without any technical setup, which is the primary reason Wix's IndexNow implementation is often cited as the smoothest onboarding experience across all major website builders. Building on this, Wix co-announced its IndexNow support with Bing in 2023, positioning the platform as one of the first major website builders to offer native integration.²

Native vs plugin path

Wix handles IndexNow natively on Premium plans with no plugin required. When you publish or update content, Wix automatically sends the affected page URL to the IndexNow API endpoint, which distributes the signal to Bing, Yandex, Naver, Seznam, and other participating engines.¹ The verification key file is stored and served by Wix's infrastructure, satisfying the protocol's domain ownership check without any user action.³

Premium plan activation

Free Wix plans do not include IndexNow. Upgrading to any paid Wix plan activates the feature automatically for all site pages, so check your plan status before assuming submissions are firing. The activation is immediate upon plan change, but Wix's internal cache may take a few minutes to propagate the new SEO settings across all edge servers, which means the first IndexNow ping after upgrading could return a key validation error if the verification file has not yet been generated at the domain root.⁴ Waiting five minutes after the plan upgrade before submitting the first URL avoids this race condition entirely.

Real user issues

The main limitation reported by Wix users involves control over which pages trigger submissions. Because Wix fires IndexNow automatically on every publish event, there is no built-in way to exclude specific pages (such as thank-you pages, member-only pages, or noindex-tagged content) from submissions. Furthermore, Wix's IndexNow integration fires only on Wix-managed publish events; pages or content updated via Wix's CMS API, Velo backend scripts, or third-party Wix apps may not trigger the automatic ping, leaving those updates unsubmitted until the next scheduled crawl.

For sites with frequent programmatic content updates, this gap means some changes may be slower to reach search engine indexes than manually managed sites, because the automatic trigger only fires on standard Wix editor publish events and does not cover content changes made through the Wix CMS API, Velo backend functions, or third-party app integrations that modify page content without going through the standard publish workflow.

When to fall back to a manual tool

Manual submission covers two gaps that Wix's native integration leaves open. First, bulk URL submission after a site migration or domain change does not occur automatically; Wix fires pings on publish events, not on historical URL changes. Second, submitting deletion signals (pages removed or redirected) requires manual action because Wix's automatic integration does not reliably send 410 signals for deleted pages.⁵³ Third, if you manage content via the Wix CMS API or Velo and those updates do not fire a publish event, a manual submission batch ensures those URLs enter the IndexNow priority queue without waiting for Bingbot's next scheduled crawl.

Wix Velo API and programmatic content updates that bypass automatic submission

Wix Velo lets you build backend logic and data-driven pages that update independently of Wix's standard content editor. Content written or updated via Velo's wix-data API, including dynamic pages populated from Wix CMS collections through custom code, does not consistently trigger the automatic IndexNow publish event that Wix fires for standard page edits. These programmatic updates represent a gap in Wix's native IndexNow coverage that requires manual submission to close.

After running a Velo data update that changes publicly visible content, identify the affected canonical URLs and submit them through a manual IndexNow submitter. The submission delivers the same crawl acceleration as the automatic trigger would have, without requiring any changes to your Velo backend code. For sites with frequent programmatic updates, building a lightweight Velo HTTP function that calls the IndexNow API directly is a more scalable approach than manual submission after each run.

Dynamic pages from Wix CMS collections

Wix dynamic pages generate URLs based on CMS collection field values. When you add or update collection items that power dynamic pages, the corresponding URLs may not trigger the automatic IndexNow publish event. After adding or modifying CMS collection items through the Wix dashboard or the Velo data API, submit the resulting dynamic page URLs manually if those pages represent significant content updates.

Watch the volume of collection changes before you decide between manual submission and a custom API call. A single new blog post powered by a CMS item is easy to submit by hand, but a sale that reprices hundreds of collection items in one batch is better handled by a Velo HTTP function that reads the changed items and POSTs them in one request. Tie that function to the collection's onDataUpdated hook so the submission fires precisely when content changes, keeping the dynamic pages in sync with search engine caches without manual intervention.

Domain migration on Wix and IndexNow key re-verification

Moving a Wix site from a Wix subdomain (yoursitename.wixsite.com) to a custom domain changes the host on which IndexNow submissions must be verified. Wix's automatic IndexNow integration re-verifies the key file at the new custom domain when you connect it and activate a Premium plan, so no manual key file work is typically needed. However, the first IndexNow submission after a domain migration may take longer to validate as Bing re-confirms domain ownership at the new host.

During the migration window, any IndexNow submissions sent from the old Wix subdomain address do not transfer to the new domain's priority queue. After confirming the custom domain is live and the Premium plan is active, submit a batch of your highest-priority pages manually to rebuild Bing's crawl history for the new domain identity quickly.

Checking IndexNow is active after a plan upgrade

To confirm Wix's native IndexNow is active on a newly upgraded Premium account, navigate to Wix Dashboard → Promoting your site → SEO → SEO Settings. IndexNow is included automatically with your Premium plan, so there is no toggle to turn it on or off manually. If you do not see IndexNow listed under SEO Settings despite having a valid Premium plan, contact Wix support; the activation sometimes requires a manual refresh of the site's SEO settings after the plan upgrade completes.

When to use this

Wix's built-in IndexNow handles standard publish and update events automatically on Premium plans; no setup is needed.² Use a manual submitter for bulk migrations, deleted-page removal signals, and programmatic CMS API updates that bypass Wix's automatic submission trigger.

Notes

Wix Premium plans include IndexNow automatically, with no plugin or key file work required. The integration covers standard publish events. Use a manual submitter for domain migrations, deleted pages, and Velo-driven content updates that bypass the native publish trigger.

Examples

Wix Dashboard → Promoting your site → SEO → SEO Settings
(IndexNow is included automatically on Premium plans)
No additional configuration required

# Wix doesn't auto-submit deleted page signals:
# 1. Remove or redirect the page in Wix
# 2. Paste the old URL into CapyToolkit's submitter
# 3. Ensure old URL returns 301 or 410 before submitting

Try in the tool

IndexNow on Squarespace

Squarespace has not integrated IndexNow into its platform as of mid-2026, so the protocol's domain verification check requires a manual workaround because the platform restricts root directory file access.¹ Without a key file at yoursite.com/[key].txt, participating search engines cannot validate the submission source, and all IndexNow pings from that domain will be rejected.²

Third-party tools and workarounds exist for Squarespace owners who want IndexNow coverage. Because Squarespace 7.1 provides a file storage mechanism through the Link Manager, placing the key file at a path and creating a redirect that serves it as the root verification URL is a documented workaround in Squarespace community forums. Furthermore, services like IndexPlease offer automated Squarespace submissions by handling the verification and submission steps through their own infrastructure rather than your Squarespace domain configuration.

Native vs plugin path

No native IndexNow integration exists in Squarespace as of mid-2026.¹ The platform does not offer a built-in SEO setting or plugin market for IndexNow the way WordPress or Shopify do. Verification requires hosting a text file at the apex domain root, and Squarespace's file system does not permit direct uploads to that path.²

Redirect workaround and cache timing

The documented workaround for Squarespace 7.1 uses the File Storage area to upload the key file and then creates a URL redirect under Settings → Advanced → URL Redirects that points the root key file path to the hosted file location, effectively satisfying the validation check. Squarespace 7.0 sites may require a different approach depending on template structure. After creating the redirect, clear the site cache immediately and verify the key file is reachable with a direct curl request, because Squarespace's CDN layer can serve a stale 404 for the redirect path for several minutes after the rule is first published.

Real user issues

Key file verification is the primary barrier for Squarespace users, as reported across the Squarespace community forum and SEO practitioner threads. Setting up a redirect to serve the key file works, but Squarespace's redirect rules are cached, so any cache delay between creating the redirect and the engine validating the file can cause false rejection on the first ping. Clearing the site cache after setting up the redirect reduces this failure mode. Yet another reported issue involves domain ownership verification for connected custom domains; if the Squarespace site uses a domain connected from an external registrar, the verification file redirect must be tested from the custom domain path, not the squarespace.com subdomain.

When to fall back to a manual tool

Given the verification complexity, many Squarespace site owners find manual submission more practical than maintaining the redirect workaround.³ A manual submitter handles individual URL submission without requiring key file hosting on the Squarespace domain, because some third-party IndexNow services provide their own key file. For sites with infrequent content updates, weekly manual submission of changed URLs delivers most of the indexing speed benefit without the ongoing maintenance of a workaround verification setup. After major content updates or page additions, pasting the new URLs into a manual submitter takes less time than debugging a cached redirect failure. Squarespace sites that rely on scheduled publishing face an additional gap: the platform's internal scheduler does not trigger IndexNow submissions through the redirect workaround, so any content published on a schedule needs a manual submission step to ensure the URLs enter the crawl queue at the right time.

Squarespace 7.0 versus 7.1 key file workaround differences

Squarespace 7.0 and 7.1 use different underlying template architectures, and the key file redirect workaround behaves differently in each. In Squarespace 7.1, File Storage (accessible via Squarespace's backend file management) allows you to upload the key file and then create a URL redirect pointing /[key].txt to the uploaded file's URL, satisfying the IndexNow verification check. In Squarespace 7.0, File Storage works differently and the redirect approach may not be available for all 7.0 templates, depending on how the template handles static asset routing.

For Squarespace 7.0 sites, the practical alternative is a third-party IndexNow service that hosts its own key file and handles verification independently of your Squarespace domain configuration. Services like IndexPlease operate this way: you connect your domain to their service, they manage key file verification from their own infrastructure, and submissions go out under their hosted verification rather than a key file at your Squarespace root.

Verifying which Squarespace version your site uses

Navigate to Squarespace's Home Menu → Settings → Advanced → Developer Mode (7.0) or check the Squarespace dashboard for the Pages panel design (7.1 uses a fluid engine layout editor). Confirming your version before attempting the redirect workaround avoids time spent troubleshooting an approach that does not apply to your template. Squarespace 7.1 sites have access to the full File Storage and URL Redirects workflow, while 7.0 sites on older templates may lack one or both of these features, which means the key file redirect method simply will not work without switching to a third-party IndexNow service that handles verification independently.

Third-party IndexNow services as a Squarespace alternative

Third-party IndexNow submission services remove the need to configure a key file on Squarespace entirely. These services host their own IndexNow key files and submit URLs on your behalf, using their verified domain as the submission origin rather than yours. Because the key file lives at their domain and not at your Squarespace root, Squarespace's root directory restrictions become irrelevant.

The trade-off is that submissions do not originate from your domain, which means the quality signal that participating engines associate with your domain's submission history does not build under your host. For most small sites where the cumulative domain quality signal matters less than simply getting URLs indexed, this is an acceptable trade-off compared to maintaining a fragile redirect workaround.

Manual submission as the lowest-maintenance Squarespace path

For Squarespace sites that publish infrequently (once or twice per week), manual submission through a browser-based tool after each content update delivers the same indexing speed benefit as any automated approach, without requiring ongoing maintenance. CapyToolkit's submitter handles the submission in under a minute per URL and shows the engine's HTTP response code for each submission, confirming whether the IndexNow endpoint accepted the request. Over the course of a month of twice-weekly publishing, the total manual submission time amounts to a few minutes.

Batch your manual submissions when several pages change in the same week rather than submitting each one the moment it goes live. A Tuesday and Friday publishing rhythm lets you submit a small group of new URLs together, which keeps the submission list short and the response codes easy to scan for failures. If a submission returns anything other than a 202, re-check that the URL returns a 200 from the custom domain and resubmit, because a cached Squarespace redirect or a transient CDN error is usually the cause rather than a genuine indexing problem.

When to use this

For Squarespace sites, use a manual submitter after each content publish or update if native IndexNow is not configured. Set up the URL redirect workaround only if you publish frequently enough to justify the maintenance. Delete-signal submissions always require manual action.

Notes

Squarespace has no native IndexNow support as of mid-2026. Key file hosting requires an URL redirect workaround via Settings → Advanced → URL Redirects in Squarespace 7.1. For most sites, manual submission after content updates is simpler and more reliable than maintaining the redirect.

Examples

1. Generate IndexNow key at api.indexnow.org/indexnow
2. Upload [key].txt to Squarespace File Storage
3. Settings → Advanced → URL Redirects:
   From: /[key].txt  →  To: [file storage URL]
4. Test: curl https://yoursite.com/[key].txt

# After publishing a new page or blog post:
# 1. Copy the published URL from your browser
# 2. Paste into CapyToolkit's IndexNow submitter
# 3. Submit; all participating engines receive the ping

Try in the tool

IndexNow on Webflow

Because IndexNow verification requires a text file at yoursite.com/[key].txt, Webflow's restriction on root-level file uploads blocks the standard setup path.¹ Webflow does not allow uploading arbitrary files to the domain root, so the key file placement step fails without a workaround. A feature request to support key file hosting has been open on the Webflow wishlist since 2022 but remains unimplemented, with low vote counts suggesting it is not near the product roadmap.

Third-party approaches fill the gap. The most reliable documented method uses an S3 bucket (or any publicly accessible static host) to serve the key file, then configures a 301 redirect in Webflow's hosting settings to route the /[key].txt path to the S3 URL. Furthermore, third-party tools like Sight AI provide a purpose-built Webflow-to-IndexNow connector that handles verification and automatic URL submission when Webflow CMS items are published or updated via webhooks.

Native vs plugin path

No native IndexNow integration exists in Webflow as of mid-2026². Webflow hosts sites on a CDN with restricted file system access, which prevents the standard key file upload approach. The documented workaround places the verification key file on an external static host (AWS S3, GitHub Pages, or similar) and creates a redirect in Webflow's Hosting → Redirects panel that maps /[key].txt to the external URL, satisfying the verification check from the correct domain.

External key file and redirect verification

For automated submission, GitHub Actions or Zapier-based workflows can call the IndexNow API on Webflow CMS webhook triggers (CMS item published events), enabling near-real-time submission without a third-party subscription. Before relying on automation, verify that the redirect returns the key file from the custom domain, not just from the external host. The critical detail many Webflow users miss is that the redirect must return the key file content with a plain text content type, not an HTML wrapper or a download prompt, because search engine validators read the raw response body and reject any file that does not contain exactly the key value as plain text.²

Real user issues

The most-reported Webflow IndexNow challenge is redirect caching on the CDN layer. After creating the /[key].txt redirect, Webflow's CDN may serve a cached 404 for the redirect path for several minutes, causing the initial validation request from a search engine to fail. Purging the Webflow CDN cache after adding the redirect reduces this window. Yet another issue affects Webflow CMS collections: the webhook-based automation requires careful URL construction because Webflow CMS item URLs depend on the collection's URL pattern, and incorrect URL generation sends the wrong address to the IndexNow endpoint. Webflow sites using localization features face a similar challenge, as locale-specific URL paths must be submitted individually for each language variant³, and the redirect workaround only serves the primary locale unless separate redirects are configured for each language path.

When to fall back to a manual tool

Manual submission is the practical fallback for Webflow sites that update infrequently or whose owners do not want to maintain the S3 redirect and webhook pipeline. After publishing a new page or updating a CMS item, pasting the URL into a manual submitter takes under a minute and delivers the same crawl acceleration benefit. Furthermore, removal signals for deleted Webflow pages or CMS items require manual action regardless of the automation setup, because webhook-based pipelines typically trigger on publish events, not on deletion confirmation with 410 status verification³. Webflow site exports and re-imports, a common workflow during redesigns, also bypass all automation hooks entirely, meaning every URL on the rebuilt site needs a fresh manual submission batch to re-enter the IndexNow priority queue under the new site structure.

Automating Webflow-to-IndexNow submissions via CMS webhooks

Webflow emits webhook events when CMS collection items are published. The collection_item_published webhook payload includes the item's slug and collection identifier, which you can combine with your site's base URL to construct the canonical URL for IndexNow submission. Connecting this webhook to a Zapier step, a Make scenario, or a custom endpoint takes about 20 minutes and produces near-real-time IndexNow submission without manual action.

In Zapier, the workflow is: Webflow trigger (CMS Item Published) → Webhooks by Zapier action (POST) → target https://api.indexnow.org/indexnow with a JSON body containing your host, key, and the constructed URL. The key challenge is URL construction: Webflow's webhook payload provides the item slug but not the full canonical URL, so your Zapier step must concatenate the base domain, collection path, and item slug into the correct format before POSTing.

GitHub Actions as a zero-cost submission layer

GitHub Actions can serve as a free IndexNow dispatch layer triggered by Webflow deploy webhooks⁴. When Webflow publishes a site build, it can trigger a GitHub Actions workflow via repository_dispatch. The workflow reads a list of recently changed URLs from a commit or a pre-staged JSON file and POSTs them to the IndexNow endpoint using a curl step. This approach requires no third-party subscription and runs within GitHub's free-tier action minutes for most Webflow sites.

Key file CDN propagation and submission timing on Webflow

The most common failure point for new Webflow IndexNow setups is CDN cache delay after adding the key file redirect. Webflow's CDN may serve a cached 404 for the /[key].txt path for several minutes after the redirect is published, causing the engine's key validation request to fail silently. Purging the Webflow CDN cache manually after publishing the redirect and then waiting two to three minutes before sending the first IndexNow submission prevents this failure.

After purging, verify the key file is reachable by running curl -I https://yourdomain.com/[key].txt from a terminal. A 200 or 301 response confirms the redirect is serving correctly. If the response is 404, the CDN has not propagated the redirect yet and you should wait another two minutes before rechecking. Running the same curl request from a different network or using an online HTTP status checker confirms whether the propagation delay is local to your connection or global across all Webflow CDN edge nodes, which determines whether you can proceed with submissions or need to wait longer.

Choosing between S3 and GitHub Pages for key file hosting

Both AWS S3 and GitHub Pages work as key file hosts for the Webflow redirect workaround. S3 is simpler to keep private and costs negligible amounts for a static text file at typical traffic volumes. GitHub Pages is free and version-controlled⁴, which makes the key file easy to audit and rotate. For teams already using GitHub for Webflow deploy automation, GitHub Pages keeps the infrastructure consolidated.

The practical difference matters most during key rotation: with S3 you update a single object in place, while with GitHub Pages the commit history provides a built-in audit trail showing exactly when the key changed and what the previous value was, which simplifies debugging if a validation failure occurs after a rotation. For teams that need to rotate keys frequently or maintain compliance documentation, the GitHub Pages audit trail is the stronger choice because it provides timestamped proof of every key change without requiring any additional logging infrastructure.

When to use this

Use the S3 redirect workaround and a webhook-based automation pipeline if your Webflow site publishes CMS content frequently. Use a manual submitter for occasional updates, page deletions, or when the automation setup is too complex for the update frequency.

Notes

Webflow has no native IndexNow support. Host the key file externally (S3 or GitHub Pages) and redirect /[key].txt in Webflow's Hosting panel. Automate submissions via GitHub Actions or Zapier on CMS publish webhooks. Manual submission via CapyToolkit covers gaps and deletion signals.

Examples

1. Upload [key].txt to an S3 bucket (set public read)
2. Note the S3 object URL (e.g. https://bucket.s3.amazonaws.com/[key].txt)
3. Webflow Dashboard → Hosting → Redirects:
   From: /[key].txt  →  To: [S3 URL] (301)
4. Publish the site to apply the redirect

Trigger: Webflow → "CMS Item Published"
Action: Webhooks by Zapier → POST
  URL: https://api.indexnow.org/indexnow
  Body: { "host": "yourdomain.com", "key": "[key]",
          "urlList": ["{{item_url}}"] }

Try in the tool

IndexNow with Cloudflare (Crawler Hints & Workers)

From automatic CDN-level notifications to custom Workers logic, Cloudflare offers two practical paths to IndexNow integration. Crawler Hints, available free to all Cloudflare customers, automatically notifies participating search engines when Cloudflare detects content changes at the CDN layer, without requiring changes to your application code or any plugin installation.¹ For more granular control, Cloudflare Workers let you build a custom IndexNow submission handler that fires on specific routes, request patterns, or content change events triggered by your deploy pipeline.²

These two approaches serve different use cases. Crawler Hints operates transparently below the application layer, which means it works across any origin stack (WordPress, static sites, custom apps) without code changes. Workers, by contrast, give engineering teams explicit control over which URLs to submit, when to submit them, and how to batch requests, but they introduce code that must be maintained and tested as the Workers platform evolves. Building on this, Cloudflare's CDN position means it can detect content changes (via cache MISS versus cache HIT signals) before the origin server records them as published, which gives Crawler Hints a unique trigger advantage.¹

Native vs plugin path

Crawler Hints is generally available and free for all Cloudflare users. Enabling it requires no code; navigate to the Cloudflare Dashboard → Speed → Optimization → Crawler Hints and toggle it on. Cloudflare manages key file hosting internally, so the IndexNow verification step completes without any action from the site owner.³ Crawler Hints submits URLs to Bing and other participating engines when Cloudflare's CDN observes cache invalidation events, indicating content has changed.

Zero-code path versus Worker control

For custom submission logic, Cloudflare Workers can call the IndexNow API directly, giving you control over submission timing, batching, and URL filtering. Use Crawler Hints for standard publish events, and reserve Workers for migrations, custom queues, or deletion signals that the CDN hint does not cover. The key advantage of the Worker approach is that you can implement custom filtering logic, such as excluding URLs matching specific patterns or batching submissions by content type, which Crawler Hints cannot do because it operates at the CDN cache level with no awareness of your application's URL semantics.

Real user issues

Fan-out rate limiting is the most-reported Workers-based IndexNow issue. A Workers script that submits a URL to IndexNow on every incoming request or every cache purge event can generate thousands of API calls per minute, triggering IndexNow's rate-limit response (429 Too Many Requests).⁴ The correct pattern batches URLs from a queue and submits them in groups rather than one-per-event. A second issue involves Crawler Hints firing on CDN-level cache changes that are not meaningful content updates, such as cache warming requests or monitoring pings, which produce low-quality IndexNow signals. Using Cloudflare's Cache Rules to exclude monitoring paths from Crawler Hints coverage reduces noise.

When to fall back to a manual tool

Manual submission covers URLs that Crawler Hints misses. Because Crawler Hints detects changes via CDN cache signals, URLs that are always served from cache without revalidation (extremely long TTL assets) may not trigger a hint even after content changes. Similarly, URL deletions that return 301 redirects at the CDN level may not generate a Crawler Hints event. For these cases, a manual submitter provides the explicit push that automated methods cannot reliably deliver.

Cloudflare zone migrations, where all URLs temporarily resolve through a different CDN path, also benefit from a manual bulk submission after the migration completes.³ Another gap appears when Cloudflare's Bot Fight Mode or super bot fight mode challenges incoming crawler requests; if the challenge page intercepts a search engine's key validation request, the IndexNow submission fails silently, so verifying that the key file path is excluded from bot challenge rules is an essential pre-submission check.⁵

Cloudflare Pages deploy hooks and IndexNow submission after static site builds

Cloudflare Pages builds static sites from a Git repository and deploys them globally on each push. Because static sites do not produce CMS publish events, IndexNow submissions for static site content must be triggered by the deploy pipeline rather than by a CMS event hook. Cloudflare Pages deploy hooks are inbound URLs that accept HTTP POST requests to trigger new deployments from external services; for outbound build notifications, Cloudflare offers Workers Builds Event Subscriptions that publish build events (including build.succeeded) to a consumable queue.⁶

Configure a Worker that consumes build.succeeded events from a Builds Event Subscription queue, reads a pre-staged list of changed page URLs (generated as part of the build process and stored in a KV namespace), and POSTs them to the IndexNow endpoint. Generating the changed URL list during the build requires a build script that compares the current site structure against the previous deployment and outputs only the added or modified pages, keeping the submission list focused on content that actually changed.

Static site generators and changed-page detection

Static site generators like Hugo, Eleventy, and Astro output file manifests during the build. Comparing the current build's file hashes against the previous build's hashes identifies exactly which pages changed. A post-build script that reads this diff and exports the corresponding canonical URLs produces a precise IndexNow submission list without submitting unchanged pages, which preserves crawl budget and submission quality signals across all participating engines.⁷

Cache-Control TTL values and Crawler Hints trigger reliability

Cloudflare Crawler Hints fires on CDN cache invalidation events. Pages with very long Cache-Control TTLs (such as max-age=86400 or higher) may not generate a cache invalidation event when content at the origin changes, because the CDN continues serving the cached version until the TTL expires.⁸ For those pages, Crawler Hints will not fire even after a content update, leaving the change unnoticed by participating engines until the cache expires naturally.

Setting shorter Cache-Control TTLs on content pages (articles, product descriptions, news posts) improves Crawler Hints coverage at the cost of increased origin traffic. A common configuration sets max-age=3600 on content pages and max-age=31536000 on static assets (JavaScript, CSS, images). This distinction keeps CDN overhead low for assets while ensuring content changes generate cache invalidation events that Crawler Hints can detect.

Reducing noise from monitoring and infrastructure paths

Crawler Hints is a global setting with no built-in path exclusion. Paths like /health-check, /ping, and /cdn-cgi/ generate CDN activity that does not reflect meaningful content updates. To prevent these paths from producing spurious IndexNo hints, configure a Cloudflare Response Header Transform Rule that adds X-Robots-Tag: noindex to requests matching your monitoring URL patterns.

Without this exclusion, uptime monitoring tools that hit your health-check endpoint every 30 seconds can generate hundreds of spurious Crawler Hints per day, which dilutes the quality signal and wastes crawl budget on URLs that no search engine should ever index. Over weeks, those spurious hints train participating engines to treat low-value paths as regular content, which can depress the overall crawl priority of your site.

When to use this

Enable Cloudflare Crawler Hints for zero-maintenance IndexNow coverage across any origin stack. Use Workers for custom submission logic when you need explicit URL filtering, batching, or pipeline integration. Use a manual submitter for post-migration bulk pushes and deletion signals.

Notes

Enable Crawler Hints free at Dashboard → Speed → Optimization → Crawler Hints. Cloudflare manages key file hosting. For Workers-based submissions, batch URLs in groups and rate-limit calls to avoid 429 responses from the IndexNow endpoint. Manual submission covers deletions and post-migration bulk pushes.

Examples

Cloudflare Dashboard → [your domain] → Speed → Optimization
→ Crawler Hints → toggle On
No code changes required; Cloudflare manages key file

// POST to IndexNow with URL batch (max 10,000 per request):
const res = await fetch('https://api.indexnow.org/indexnow', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    host: 'yourdomain.com',
    key: YOUR_KEY,
    urlList: batchedUrls  // array of canonical URLs
  })
});

Try in the tool

IndexNow on Drupal

Without IndexNow in Drupal core, third-party modules from drupal.org provide the integration. The "Index Now" module (drupal.org/project/index_now) is the most widely adopted, covering nodes, taxonomy terms, and commerce products across create, update, and delete events.¹ Version 3.1.11, released June 13, 2026, is the current stable release and requires Drupal 10.3 or 11.¹

Because Drupal sites tend to run complex editorial workflows with multiple user roles, scheduled publishing, and content moderation states, IndexNow integration touches more lifecycle hooks than simpler CMS plugins do. Consequently, the module is designed to submit URLs at the point a content item transitions to published status rather than on every save event, which avoids pinging search engines for drafts or unpublished revisions.²

Native vs plugin path

Drupal core does not include IndexNow as of Drupal 11.³ The "Index Now" module (drupal.org/project/index_now) is the reference third-party implementation, currently at version 3.1.11 (June 2026). Install via Composer at the project root: composer require drupal/index_now, then enable through the Drupal admin at Extend → Enable → Index Now → Save configuration.

Content type selection before enabling

Module settings appear under Configuration → Search and metadata → Index Now, where you configure the API key, select which content types trigger submissions, and view a log of recent pings. The Index Now Commerce submodule, previously a separate project, merged into the main module in version 3.1.5 and now handles product and product variation URLs automatically. Before enabling the module, review your content types carefully and deselect any that represent internal or administrative pages, because submitting URLs for content that is never intended for public search results wastes crawl quota and can confuse search engines about the scope of your indexable content.

Real user issues

Scheduled publishing conflicts are the most-discussed Drupal IndexNow issue on drupal.org issue queues. When content is scheduled using the Scheduler module, the IndexNow module may fire on the pre-publish save event rather than the actual publish timestamp, submitting URLs before the content is publicly accessible. The workaround is to configure the module to hook into the Scheduler's publish event rather than the core save hook, which requires a short custom module or a patch against the IndexNow module.

A second issue affects multilingual Drupal sites; the module submits only the default language URL by default, leaving translated paths unsubmitted unless additional configuration or a custom hook specifies the translated URL for each language. This means that on a Drupal site with five active languages, only the default-language canonical enters the IndexNow priority queue, and the other four language variants must wait for organic crawl discovery, which can delay their indexing by days or even weeks depending on the domain's crawl frequency for each language section.⁴

When to fall back to a manual tool

Manual submission covers events that the Drupal module's event hooks do not capture. Bulk content migrations using the Migrate module fire standard Drupal entity hooks by default, but many production migration configurations explicitly disable those hooks using the disable_hooks setting for performance reasons, which means the IndexNow module's hooks are suppressed alongside others during import.⁵ Migrated content imported with hooks disabled needs a manual submission batch after migration completes. Similarly, taxonomy term URL changes, such as renaming a term and changing its URL alias, do not consistently trigger the IndexNow module's update hook. For multilingual sites where translated paths are important, a manual batch submission of all language variants after a content update ensures complete coverage without custom module work.

Drupal sites using the Pathauto module to generate URL aliases should also verify that alias changes trigger the IndexNow module's update hook; Pathauto generates aliases synchronously on node save by default, but the bulk-update feature for retroactively generating missing aliases runs separately and may not trigger the IndexNow module, creating a gap if large numbers of unaliased nodes receive their first alias through the bulk process rather than through an individual save event.

Drupal Scheduler module conflict and content moderation state timing

Drupal's Scheduler module queues content for future publication at a specified timestamp. When the IndexNow module hooks into Drupal's standard node save event, it fires on the pre-publish save action rather than on the actual scheduled publish moment, submitting a URL that may still return 403 or redirect to a teaser page until the scheduled time arrives. Search engines that fetch the submitted URL before it is publicly available either discard the submission or cache the inaccessible response, both of which reduce the effectiveness of the IndexNow signal.

The correct fix adds a custom Drupal event subscriber that listens to the Scheduler module's SchedulerEvents::PUBLISH event rather than the core node save hook. This event fires precisely when Scheduler transitions the content to published status, ensuring the IndexNow submission goes out only after the page is publicly accessible.⁶ Implementing this as a small custom module (roughly 30 lines of PHP) takes about one hour and permanently resolves the pre-publish submission problem.

Content Moderation module and the published state transition

Sites using Drupal's Content Moderation module define custom workflows with multiple states (draft, review, published). The IndexNow module should fire only when content transitions into the final published state, not on intermediate moderation transitions. Configure the module at Configuration → Search and metadata → Index Now to trigger on the specific state that represents live public content in your workflow, rather than accepting the default save-event trigger.

Multilingual Drupal sites and IndexNow coverage for translated paths

Drupal's Language module generates translated URL aliases for each enabled language. A node at /en/article-slug may have a corresponding translation at /fr/article-slug and /de/article-slug. The Index Now module submits only the default language URL by default, leaving all translated paths out of the IndexNow priority queue until the next scheduled crawl discovers them organically.

Extending the module's URL list requires implementing hook_index_now_url_alter() in a custom module (available since version 3.1.9). This hook receives the URL about to be submitted and allows you to modify it or submit additional URLs for each language variant. Iterating over all active language configurations, generating the translated URL alias for each language, and submitting each variant produces complete multilingual coverage.

Bulk submitting translated URLs after multilingual content migration

When migrating a multilingual Drupal site, translated paths often exist in the database but never triggered IndexNow submissions because they were imported via the Migrate module rather than created through the editorial UI. After a migration run, export the full list of translated URL aliases from Drupal (using Views or a Drush command against the path_alias table) and submit them in a manual batch. This one-time catch-up submission ensures all language variants enter search engine priority queues without waiting for organic crawl discovery.

Sort the exported alias list by language before you submit, so you can watch each locale's coverage independently rather than mixing all variants into one opaque batch. Submitting the English set first gives you a clean baseline in Bing Webmaster Tools to confirm the pipeline works, then the French and German sets can be tracked against that known-good pattern. Resubmit any language whose translated alias was generated by the bulk Pathauto process rather than an individual save, because those specific URLs are the ones most likely to have slipped past the module's update hook.

When to use this

Use the Index Now Drupal module for standard editorial content publishing, update, and delete events on nodes and commerce products. Use a manual submitter for bulk migrations, taxonomy alias changes, multilingual URL variants, and scheduled-publish edge cases.

Notes

Install the "Index Now" module (v3.1.11, June 2026) via Composer: composer require drupal/index_now, then enable at Extend → Index Now. Configure at Configuration → Search and metadata → Index Now. Commerce products are covered via the built-in submodule. Manual submission covers migration and multilingual gaps.

Examples

composer require drupal/index_now
drush en index_now
drush cr
# Configure at: /admin/config/search/index-now

# Migrate module does not fire standard node hooks:
# 1. After migration, export a list of new node URLs
# 2. Use Drush or Views to generate the URL list
# 3. Paste URLs into CapyToolkit's submitter in batches

Try in the tool

IndexNow on Joomla

With no native IndexNow support in Joomla core, integration depends on third-party plugins. Two options cover Joomla 4, 5, and 6: the "WT IndexNow" plugin (version 1.0.1, updated February 7, 2026) and the "Aimy IndexNow" plugin, which supports Joomla 3 through 6 and is available through the Joomla Extension Directory.¹ Both plugins are disabled by default after installation and require manual activation through Joomla's Plugin Manager before any submissions fire.

Joomla's plugin architecture hooks into content save and delete events, which means the IndexNow submission fires on the same lifecycle trigger as other content events in the system. Consequently, Joomla's IndexNow coverage is consistent across article types, custom content types, and third-party component-generated content, provided those components dispatch standard Joomla content events rather than bypassing the event system entirely.²

Native vs plugin path

No native IndexNow support exists in Joomla core as of Joomla 6.³ The recommended path is the WT IndexNow plugin (v1.0.1, February 2026, compatible with Joomla 4, 5, and 6) or the Aimy IndexNow plugin, both available from the Joomla Extension Directory. Installation follows the standard Joomla extension path: System → Manage → Extensions → Install → upload the plugin package.

Published-state filtering

After installation, navigate to System → Manage → Plugins, search for "IndexNow," and enable the plugin. Configuration options include the API key field, where to enter the key generated from api.indexnow.org, and which content types fire submissions. The plugin auto-generates or accepts a user-provided key and places the verification file in the Joomla root on first activation.⁴ By default the plugin fires on every content save event regardless of publication state, which means draft articles and archived items generate IndexNow pings for URLs that return 403 or redirect when search engines attempt to fetch them, gradually degrading the quality signal associated with your domain unless you configure the plugin to check the article state before submitting.

Real user issues

The most-reported Joomla IndexNow issue is that the plugin fires on every article save, including saves of unpublished draft articles. Because Joomla's save event triggers before the publish state is checked, a draft saved in the backend generates an IndexNow submission for a URL that returns 403 or a redirect when the engine fetches it. Search engines silently discard these invalid submissions, but they consume the site's crawl quota. Configuring the plugin to fire only when the article state transitions to published (state = 1) rather than on every save reduces noise.

A second issue is that third-party components (event managers, directories, e-commerce extensions) often dispatch component-specific events rather than Joomla's core content events, so the IndexNow plugin does not receive triggers for that content without additional configuration. This gap is particularly common with popular Joomla extensions like J2Store, VirtueMart, and EventList, which manage their own content lifecycle independently of the core com_content event system, meaning any articles or product pages created through those components remain invisible to the IndexNow plugin until a developer writes a custom plugin bridge that translates component-specific save events into the standard Joomla content events the IndexNow plugin listens for.

When to fall back to a manual tool

Manual submission is most useful for Joomla sites running third-party components whose events the IndexNow plugin does not intercept. An events component, a directory extension, or a custom e-commerce solution built on its own database tables and event system will not trigger the plugin's content hooks. After publishing content through those components, pasting the affected URLs into a manual submitter delivers the IndexNow signal without requiring plugin customization.

Bulk URL migration during a Joomla version upgrade (such as moving from Joomla 4 to Joomla 5 with URL structure changes) also requires manual submission, since the plugin fires only on active content lifecycle events, not on historical URL list processing. When a site upgrade changes URL aliases, menu item routing, or category structure, the old URLs need explicit IndexNow deletion signals and the new URLs need fresh submission pings, neither of which the plugin handles automatically because the migration operates at the database level rather than through the standard content save events that the plugin hooks into.

Joomla Workflow Bundle and IndexNow submission on the published state transition

Joomla 4 introduced the Workflow Bundle as a core feature for managing multi-step editorial workflows. Workflows define states (draft, review, approved, published) and transitions between them. The WT IndexNow plugin fires on Joomla's standard content save event, which may trigger on any state transition including intermediate draft saves, not just the final transition into the published state.

The correct approach wraps IndexNow submission in a Joomla Workflow Transition Action plugin. Joomla's plugin API includes the WorkflowServiceInterface and the transition action plugin type, which fires specifically when content moves from one workflow state to another. Registering an action plugin that fires only on the transition to the published state ensures IndexNow submission happens exactly when content goes live, regardless of how many intermediate saves occurred before that point.⁵

Configuring the IndexNow plugin to check article state before firing

A simpler alternative (without writing a custom action plugin) adds a state check to the IndexNow plugin's event handler: before submitting a URL, the plugin reads the article's current state field and fires only when the value equals 1 (published). This check can be added in the plugin's PHP class by querying the Joomla article model for the post-save state. The WT IndexNow plugin's GitHub repository accepts pull requests, so this fix benefits the community if contributed upstream.

Joomla multilingual sites and translated URL coverage with the Multilingual Associations component

Joomla's Multilingual Associations component links content items across languages, creating a network of related articles, each with its own language-specific URL alias. When an article is published or updated, the WT IndexNow plugin submits the default language URL, leaving all associated translated articles unsubmitted until Joomla's next scheduled tasks or organic crawl discovery find them.

Extending IndexNow coverage to translated articles requires reading the Multilingual Associations data at submission time and appending the associated language URLs to the IndexNow request. In a custom system plugin, a onContentAfterSave handler can query the #__associations database table for the saved item's associations, retrieve the URL aliases for all linked translations, and include them in the IndexNow batch alongside the default language URL.

Manual batch submission for multilingual content launches

When launching a multilingual Joomla site or adding a new language to an existing site, submit a manual batch of all translated URLs immediately after the new language content is published. Export the translated URL aliases from Joomla's menu manager or from the #__menu database table and paste them into a manual IndexNow submitter. This one-time batch pushes all translated content into the priority crawl queue without waiting for the gradual organic discovery that would otherwise build multilingual search coverage over weeks.⁶

Build the alias export from an SQL query or the menu manager before launch day, not during it, so the submitter receives a complete list rather than a fragment you assemble by hand under pressure. Group the URLs by language in the batch and confirm the default-language set lands first, because that set seeds the priority queue and gives you a reference point to compare the translated sets against. After the batch succeeds, schedule a second smaller submission for any association links you discover after the initial launch, because late-added translations will not have been part of the first export.

When to use this

Use the WT IndexNow or Aimy IndexNow plugin for standard Joomla article publish and update workflows. Activate the plugin only after verifying it fires on published state, not on every save. Use a manual submitter for third-party component content and bulk post-migration URL submissions.

Notes

Install WT IndexNow (v1.0.1, Feb 2026) or Aimy IndexNow via System → Manage → Extensions. Enable via Plugin Manager (plugins are disabled by default after install). Configure at System → Manage → Plugins → IndexNow. Watch for draft-save pings; filter to published-state transitions to avoid invalid submissions.

Examples

System → Manage → Extensions → Install → Upload Package File
→ Upload plg_system_wt_indexnow.zip
System → Manage → Plugins → search "IndexNow"
→ Enable plugin → click plugin name → enter API key → Save

# Third-party components (events, directories, e-commerce)
# do not always fire Joomla content events:
# 1. Copy the published URL from the frontend
# 2. Paste into CapyToolkit's submitter
# 3. Submit after each content publish in those components

Try in the tool