IndexNow Not Working? Troubleshoot It

This guide is for site owners, developers and SEO leads who work with indexnow not working and need a reliable routine without guesswork. Many teams hit the same wall: submissions return mixed codes, logs are thin, and regional or automated coverage moves slowly while stakeholders ask for dates. The facts matter here. IndexNow is an open protocol co developed by Microsoft Bing and Yandex, Google does not support IndexNow, and one request can carry up to 10000 URLs with a key file at the site root for verification. You will learn exact checks, safe pacing, logging that proves what happened, and recovery steps that work in production. Follow the sections in order, test with a handful of URLs first, then scale once responses stay clean.

Intro scope: this article focuses on practical IndexNow operation for production sites. It assumes a live https host, access to server logs, and the ability to host a plain text file at the site root. It does not promise rankings or instant inclusion, because engines still decide crawl and index eligibility after a successful ping.

Key takeaways

How to tell IndexNow is actually failing starts with key file health and host pure batches, not with faster retries.
Key file problems missing wrong content blocked fetch works best with one test URL and full logs before bulk batches.
IndexNow is co developed by Bing and Yandex, Google does not support it, and one request can carry up to 10000 URLs.
Deduplicate, filter to changed canonical URLs, then queue at a fixed pace with backoff on 429.

Indexnow not working: how to tell it is actually failing
Key file problems missing wrong content blocked fetch
Host key and URL mismatch errors
Response codes 400 403 422 and what each means
Hosting and CDN issues that break verification
CMS and plugin misconfiguration
Engine side delays versus real failures
Logs and tests that isolate the cause fast
Fixes for the five most common setups
When to rotate keys versus fix plumbing
Checklist to restore healthy submissions
FAQ
Sources
Further reading

Indexnow not working troubleshooting checklist with key file and response checks

Indexnow not working: how to tell it is actually failing

This section covers how to tell indexnow is actually failing in the context of indexnow not working. Start with evidence, not feelings. A failing setup shows repeated client errors in submit logs, no bot fetch uplift in server logs, and no referral change in analytics for submitted groups. A healthy setup shows 200 or 202 per batch plus faster fetches for submitted URLs versus a control group. Collect one week of submit logs, fetch logs and a small control set before changing config. Clear baselines prevent fixing the wrong layer. Start with basic indexnow troubleshooting, run an indexnow debug pass on recent batches, and list open indexnow issues by code. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

IndexNow is a simple notification protocol co developed by Microsoft Bing and Yandex. When you create, update or delete a page, your site sends an HTTP request with the list of affected URLs plus a key that proves ownership. Participating engines can then prioritize those URLs for recrawling. The protocol does not upload content, does not guarantee indexing, and does not change quality evaluation. It shortens discovery time so good pages can be evaluated sooner with less waiting.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

Google does not support IndexNow, so plan for two ecosystems from the start. IndexNow notifies Bing, Yandex, Naver, Seznam and other partners that share the protocol, while Google relies on sitemaps, Search Console inspection and the Indexing API for JobPosting and BroadcastEvent pages only. A practical setup prepares one URL list at publish time, then branches to IndexNow batches plus Google sitemap coverage. Coverage improves without double counting or false expectations.

Server logs prove whether IndexNow prompts faster fetches. Record submission time, endpoint, host, URL count and response code for every batch, then watch for engine fetches of the key file and notified URLs. Compare submitted URLs against an unsubmitted control group from the same template to measure delay honestly. If fetch quickens but index state does not change, the constraint is content or eligibility rather than discovery. Evidence beats assumptions in every review.

In practice, create a short runbook for how to tell indexnow is actually failing and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

Key file problems missing wrong content blocked fetch

This section covers key file problems missing wrong content blocked fetch in the context of indexnow not working. The key file must live at the site root as plain text with exact content and public 200. Common breaks are 404 after redesigns, extra HTML wrapping from themes, whitespace changes, wrong Content-Type handling, and auth walls that block anonymous fetch. Test from outside your network with a simple GET and diff the body against the stored key. Re verify after every migration, CDN switch or security plugin change. An indexnow key invalid error often means key file not found or an indexnow 400 from bad shape, so check both. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Ownership in IndexNow is proven by a key text file hosted at the site root. The file name is your key plus .txt and its content is the key string itself. Engines fetch that URL during verification and compare it with the key in your submission. If the file is missing, returns 404, wraps content in HTML, or blocks anonymous fetch, verification fails with client errors. Keep the file plain text, publicly reachable, and stable across deploys and redesigns.

Step 1: Confirm host, key, keyLocation and endpoint in server config.
Step 2: Validate JSON shape locally against the official docs before sending.
Step 3: Deduplicate URLs and split by host so each request stays host pure.
Step 4: Send at a fixed pace, handle 429 with backoff and 403 with pause for review.
Step 5: Review fetch logs daily and record submit to fetch delay per URL group.

One IndexNow POST can carry up to 10000 URLs in urlList, but polite batches of a few hundred with pauses work better for steady trust. Deduplicate before sending, keep requests host pure with absolute https URLs on one host, and split larger backlogs across requests with delays. Reject invalid entries at queue entry with a logged skip reason so one bad URL never fails a batch of good ones. Honest change only signals beat full sitemap dumps sent daily.

Crawl health still decides whether a notified URL qualifies for the index. Keep response times low, avoid redirect chains, return clear status codes, and allow anonymous GET for important resources. Use canonical tags to consolidate variants, hreflang for translated pages, and robots rules that block only low value paths such as facets and internal search. When the crawler can fetch quickly without loops, each IndexNow hint carries more weight.

In practice, create a short runbook for key file problems missing wrong content blocked fetch and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

For background on the protocol, see IndexNow complete guide which explains endpoints, keys and fanout across participating engines.

Diagram showing indexnow not working flow with key file, queue and engine fanout

Host key and URL mismatch errors

This section covers host key and url mismatch errors in the context of indexnow not working. Submissions fail when host, key, keyLocation and urlList disagree. Mixed hosts in one request, relative paths in the list, localhost entries, or a keyLocation on a different host all return client errors. Keep one host per request, use absolute https URLs on that host, and confirm keyLocation points to the root file on the same host. Local validation before send catches most mismatches in seconds. When you see indexnow submission failed with indexnow no effect or indexnow ignored in logs, apply one indexnow fix at a time and retest. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Response codes tell you exactly what to do next. Codes 200 and 202 mean accepted so you mark the batch done. Code 400 means malformed JSON so you fix shape locally. Code 403 means key or ownership failed so you verify the key file and host. Code 422 means invalid URLs so you clean the list. Code 429 means slow down so you back off with delay. Log code plus URL count plus response snippet for every send to make weekly triage fast.

Internal linking helps IndexNow driven crawlers find changes fast after the ping. New URLs that sit four clicks from the home page may wait longer for a visit, while URLs linked from popular categories or recent posts blocks get visited quickly. Add new pages to relevant hubs, link related items, and keep pagination crawlable with plain anchors. Avoid loading key links only through scripts that require clicks. Simple stable links support both human visitors and engine crawlers.

In practice, create a short runbook for host key and url mismatch errors and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

For official details, see IndexNow documentation which defines fields, key handling and batch rules.

Response codes 400 403 422 and what each means

This section covers response codes 400 403 422 and what each means in the context of indexnow not working. A 400 means malformed JSON or missing fields, so recheck shape against the official docs. A 403 means key or ownership failed, so recheck the key file and host. A 422 means URLs were invalid, so clean the list and drop non canonical entries. A 429 means slow down with backoff. Log code plus count plus snippet per batch and route each code to its single fix rather than retrying blindly. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Bing Webmaster Tools gives the clearest reporting for IndexNow among Western engines, with submission views and crawl data to pair with your own logs. Yandex Webmaster provides its own verification and diagnostics for its index. Naver and Seznam publish less detailed quota text, so operate conservatively with small batches and strict change only filtering. Always re check the current participants page on the official site during planning rather than trusting a stale screenshot.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

Robots directives and meta tags can silently block indexing even after successful submission. A stray noindex in a template, an X Robots Tag header from a staging config, or a disallow that covers new paths will keep pages out. Audit headers with a fetch tool, render pages as a crawler sees them, and check webmaster coverage for excluded reasons. Fix the template once rather than patching URLs one by one. Clean permissions make each accepted ping useful.

In practice, create a short runbook for response codes 400 403 422 and what each means and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

To compare coverage and limits, read generate and host your IndexNow key before you commit time to one route.

Hosting and CDN issues that break verification

This section covers hosting and cdn issues that break verification in the context of indexnow not working. CDNs and security layers often block or cache the key file in ways that break engine verification. Check page rules that force auth, bot fight modes that challenge foreign crawlers, aggressive edge caching that serves stale key content after rotation, and http to https redirect chains that drop query paths. Purge edge cache for the key path, allowlist engine fetchers where documented, and test via edge plus origin. Stable delivery matters more than clever caching here. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Step 1: Export changed URLs from CMS or build manifest with last change dates.
Step 2: Keep only canonical 200 URLs on one host, drop drafts, 404s and noindex pages.
Step 3: Confirm key file GET returns 200 with exact body from outside the network.
Step 4: Send a single test URL, confirm success code, check logs for engine fetch.
Step 5: Queue remaining URLs in small batches with pauses, log every response.

Thin or duplicated content slows indexing because engines prioritize pages likely to satisfy searchers. Short descriptions copied from suppliers, empty category pages and near duplicate articles often wait longer for inclusion. Add specific details such as dimensions, materials, compatibility, usage steps and original photos. Consolidate near duplicates into one strong page with redirects. Better content earns more frequent revisits and steadier indexing after discovery.

In practice, create a short runbook for hosting and cdn issues that break verification and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

curl -s https://example.com/YOUR_KEY.txt | head -c 200
# compare with stored key, check for HTML wrapping or whitespace
curl -s -o /dev/null -w "%{http_code}" https://example.com/YOUR_KEY.txt

CMS and plugin misconfiguration

This section covers cms and plugin misconfiguration in the context of indexnow not working. Plugins fail when API keys are pasted into the wrong field, when post types are excluded, when staging URLs leak into production queues, or when hooks fire on autosave instead of publish. Audit settings for host plus key plus endpoint, confirm included post types, and guard hooks by published status. Disable one plugin at a time and test with five URLs to isolate conflicts. Clean settings beat reinstalling blindly. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Security for IndexNow stays simple because auth uses a key file rather than JWTs, but hygiene still matters. Keep the submitter config private on the server, never embed keys in browser JavaScript, and store host plus key plus endpoint outside the web root or in platform secrets. Serve the key text file at the root as plain text for engines while keeping submitter secrets separate. Rotate with overlap by hosting old and new files briefly during switches.

In practice, create a short runbook for cms and plugin misconfiguration and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

Workflow showing indexnow not working handling with paced queue and logging

Engine side delays versus real failures

This section covers engine side delays versus real failures in the context of indexnow not working. Not every slow pickup is a failure. Engines schedule crawls by site health, server speed and per site trust, so valid pings can still wait hours before a visit. Compare submitted versus unsubmitted URLs from the same template: if submitted pages fetch sooner on average, the protocol works and content quality is the next constraint. If neither group fetches, fix crawl barriers first. Honest comparison separates protocol issues from quality issues. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

Automation works best with a queue between publish events and engine endpoints. Hooks in the CMS or deploy pipeline insert rows in milliseconds while a single worker sends at a fixed pace such as one batch per minute. Filter to changed canonical indexable URLs only, dropping drafts, previews, archives and staging domains. Fixed pacing plus retry timestamps absorbs import spikes, prevents limit storms, and keeps logs readable during launches.

In practice, create a short runbook for engine side delays versus real failures and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

When errors persist, review IndexNow response codes explained to isolate key, shape and pacing causes with logs.

Logs and tests that isolate the cause fast

This section covers logs and tests that isolate the cause fast in the context of indexnow not working. Run five fast tests: GET the key file from outside, POST one URL and read the code, POST ten URLs and read the code, check server logs for engine fetch of the key file, then check for fetch of the notified URL. Log timestamp, endpoint, host, count, code and snippet for each. When you can show which step failed with exact output, fixes become one line changes. Keep these tests in the runbook for on call use. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Measurement should separate discovery speed from ranking movement. IndexNow speeds the first step from change to engine fetch, but ranking still depends on relevance, quality and competition. Track submit to fetch delay in logs, fetch to index state in webmaster tools, and index to visit in analytics as three separate intervals. When stakeholders ask about value, report each interval with dates rather than promising position gains that the protocol never claims.

Step 1: Confirm host, key, keyLocation and endpoint in server config.
Step 2: Validate JSON shape locally against the official docs before sending.
Step 3: Deduplicate URLs and split by host so each request stays host pure.
Step 4: Send at a fixed pace, handle 429 with backoff and 403 with pause for review.
Step 5: Review fetch logs daily and record submit to fetch delay per URL group.

In practice, create a short runbook for logs and tests that isolate the cause fast and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

curl -s https://example.com/YOUR_KEY.txt | head -c 200
# compare with stored key, check for HTML wrapping or whitespace
curl -s -o /dev/null -w "%{http_code}" https://example.com/YOUR_KEY.txt

Fixes for the five most common setups

This section covers fixes for the five most common setups in the context of indexnow not working. WordPress: verify plugin key, included post types and no caching of the key file. Shopify without app: confirm key file hosting via theme or proxy and use an external worker for sends. Static Astro builds: ping only after production deploy with a manifest diff. Headless CMS: validate webhook signatures and normalize URLs. Custom PHP: check timeouts, TLS and JSON encoding. One focused fix per stack resolves most reports. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Sitemaps remain the backbone of discovery even with IndexNow in place. A clean XML sitemap lists only canonical indexable URLs that return 200 and load quickly. Split large catalogs into chunks, compress with gzip, and reference each chunk from a sitemap index. Update lastmod only when content truly changes. Submit the index in Bing Webmaster Tools and keep it reachable. A tidy sitemap reduces wasted fetches and leaves room for priority pages to be visited sooner.

In practice, create a short runbook for fixes for the five most common setups and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

For engine side guidance, see Bing Webmaster help which covers submission, quotas and reporting.

When to rotate keys versus fix plumbing

This section covers when to rotate keys versus fix plumbing in the context of indexnow not working. Rotate keys when the secret may have leaked, when staff with access left, or when verification fails after confirming file correctness with no other cause. Fix plumbing when logs show shape errors, host mismatch, CDN blocks or CMS misconfig. Rotation with overlap means hosting old and new files briefly, switching sends, verifying success, then removing the old file. Do not rotate to hide a broken queue. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

In practice, create a short runbook for when to rotate keys versus fix plumbing and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

Checklist to restore healthy submissions

This section covers checklist to restore healthy submissions in the context of indexnow not working. Restore in order: verify key file GET, validate single submit, clean URL list, check CDN and robots, audit CMS settings, test ten URLs, confirm bot fetch in logs, re enable automation at half pace, watch codes for one hour, then document cause and fix. Assign one owner for keys and one for logs until success stays steady for a week. Ordered checks restore service without new breakage. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Step 1: Export changed URLs from CMS or build manifest with last change dates.
Step 2: Keep only canonical 200 URLs on one host, drop drafts, 404s and noindex pages.
Step 3: Confirm key file GET returns 200 with exact body from outside the network.
Step 4: Send a single test URL, confirm success code, check logs for engine fetch.
Step 5: Queue remaining URLs in small batches with pauses, log every response.

In practice, create a short runbook for checklist to restore healthy submissions and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

FAQ

Why does IndexNow return 403?

Ownership failed. The key file is missing, has wrong content, blocks anonymous fetch, or host plus key plus keyLocation disagree. GET the file from outside, diff the body, and confirm host purity before resending anything. An indexnow key invalid result often pairs with key file not found in logs, so check both paths carefully each time. Test with five URLs after each fix for safety and record results. Keep a short log of what you checked and when, so the next review starts from evidence.

Why do I see 422 for my URLs?

The list contains invalid entries such as relative paths, wrong host, localhost or non canonical variants. Clean the list locally, keep absolute https on one host, then resend a small test batch of five URLs. An indexnow 400 means shape is wrong, so validate JSON against docs before resending. Deduplicate and keep host pure always for safety. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory and stays simple.

I get 200 but no crawl. Is it broken?

Not always. Engines schedule by health and trust, so allow hours and compare submitted versus control URLs from the same template. If submitted pages fetch sooner on average, the ping worked and quality is the next constraint to fix. An indexnow no effect report often turns out to be indexnow ignored due to duplicates rather than failure. Measure honestly before changing config or rotating keys. Keep a short log of what you checked and when, so reviews start from evidence.

Could my CDN block IndexNow?

Yes. Bot protections, auth walls and stale edge cache for the key path break verification quickly. Purge the key path, test via edge plus origin, and allow documented engine fetchers where possible. Run an indexnow debug fetch from outside and record headers for review with the team. Re verify after each CDN change and record dates. Keep a short log of what you checked and when, so the next review starts from evidence and stays simple for on call use.

Should I rotate the key now?

Only for leak risk or confirmed key failure after plumbing checks pass. Otherwise fix shape, host, CDN or CMS settings first and retest with five URLs. Rotate with overlap to avoid downtime by hosting old and new files briefly together. A clean indexnow fix starts with logs, not rotation, unless secrets leaked. Document cause and date clearly for the team each time. Keep a short log of what you checked and when, so the next review starts from evidence and stays simple.

Does IndexNow work for Google?

No. Google does not support IndexNow. A 200 from IndexNow never reaches Google systems. Keep Google diagnostics on Search Console and sitemaps for Google coverage always. If you see indexnow submission failed, fix IndexNow plumbing separately from Google work, and review open indexnow issues weekly with logs and timestamps. Plan two tracks from the start to avoid confusion across teams. Test with five URLs before scaling for safety. Keep a short log of what you checked and when, so reviews start from evidence.

Sources

https://www.indexnow.org/documentation
https://www.bing.com/webmasters/help
https://support.google.com/webmasters/answer/7440203

IndexNow Not Working? A Troubleshooting Checklist