This is an automated email from the ASF dual-hosted git repository.
baoyuan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new f22dc3bc058 feat(seo): add GEO optimization (llms.txt) and 4 Learning
Center articles (P2) (#2026)
f22dc3bc058 is described below
commit f22dc3bc05863f5ed36e323d7943f7f25a39605c
Author: Ming Wen <[email protected]>
AuthorDate: Thu Apr 16 09:56:35 2026 +0800
feat(seo): add GEO optimization (llms.txt) and 4 Learning Center articles
(P2) (#2026)
---
website/learning-center/api-monetization-guide.md | 150 ++++++++++++++++++
.../open-source-api-gateway-comparison.md | 119 +++++++++++++++
website/learning-center/what-is-grpc.md | 167 +++++++++++++++++++++
website/learning-center/what-is-mutual-tls.md | 135 +++++++++++++++++
website/static/llms.txt | 62 ++++++++
website/static/robots.txt | 13 +-
6 files changed, 637 insertions(+), 9 deletions(-)
diff --git a/website/learning-center/api-monetization-guide.md
b/website/learning-center/api-monetization-guide.md
new file mode 100644
index 00000000000..5880d078cea
--- /dev/null
+++ b/website/learning-center/api-monetization-guide.md
@@ -0,0 +1,150 @@
+---
+title: "API Monetization: Models, Strategies & Implementation Guide"
+description: "Learn how to monetize APIs with proven pricing models. Covers
freemium, pay-per-call, tiered pricing, and revenue sharing with practical
implementation guidance."
+slug: api-monetization-guide
+date: 2026-04-14
+tags: [api-monetization, business, api-management]
+hide_table_of_contents: false
+---
+
+API monetization is the practice of generating revenue from APIs by charging
consumers for access, usage, or the value derived from API-powered
integrations. Successful API monetization requires aligning a pricing model
with how consumers perceive and extract value, backed by technical
infrastructure for metering, rate limiting, and billing.
+
+## Why API Monetization Matters
+
+APIs have shifted from internal integration glue to standalone revenue
channels. The global API management market continues to grow rapidly, driven by
the platformization of business capabilities.
+
+Companies like Stripe and Twilio have built multi-billion-dollar businesses
where the API itself is the product. This pattern is maturing, with a growing
number of enterprises monetizing external APIs.
+
+The technical challenge is substantial: you need usage metering accurate to
the individual request, rate limiting that enforces plan boundaries in real
time, and billing integration that translates API consumption into invoices
without manual reconciliation.
+
+## API Monetization Models
+
+### Comparison Table
+
+| Model | Revenue Trigger | Best For | Pros | Cons |
+|---|---|---|---|---|
+| Free / Freemium | Conversion to paid | Developer adoption, market entry |
Low barrier, viral growth | Revenue depends on conversion |
+| Pay-Per-Call | Each API request | High-volume transactional APIs | Scales
with usage, fair pricing | Unpredictable revenue |
+| Subscription Tiers | Monthly/annual plan | Predictable workloads |
Predictable revenue, simpler billing | Overprovision or underprovision risk |
+| Revenue Sharing | Transaction value | Marketplace, payment APIs | Aligned
incentives | Complex accounting |
+| Transaction-Based | Per business event | Payment processing, shipping APIs |
Value-aligned pricing | Requires event definition |
+
+### Free and Freemium
+
+The freemium model offers a free tier with usage caps (typically 1,000-10,000
requests per month) and charges for usage beyond that threshold. Freemium APIs
generally see single-digit conversion rates from free to paid plans.
+
+This model works best when the API has broad appeal, a natural expansion path
(users start small and grow), and low marginal cost per request. Stripe's
original developer onboarding followed this pattern: free to integrate, pay
only when processing real transactions.
+
+The risk is subsidizing non-converting users. Effective freemium models set
free-tier limits low enough to demonstrate value but high enough to allow
meaningful evaluation. Rate limiting at the gateway layer enforces these
boundaries without application code changes.
+
+### Pay-Per-Call
+
+Pay-per-call charges a fixed price per API request, typically ranging from
$0.001 to $0.05 per call depending on the API's value and computational cost.
AWS API Gateway charges $3.50 per million requests; Google Maps Platform
charges $5 per 1,000 geocoding requests.
+
+This model aligns cost directly with consumption and is perceived as fair by
developers. However, it creates revenue unpredictability for the provider and
cost anxiety for the consumer. Unpredictable costs are consistently cited as a
top concern among API consumers using pay-per-call pricing.
+
+Implementation requires precise request-level metering. Every API call must be
counted, attributed to a consumer, and recorded for billing. API gateways with
built-in request counting and consumer identification (via API keys or OAuth
tokens) provide this metering layer.
+
+### Subscription Tiers
+
+Tiered subscription pricing offers predefined plans (e.g., Starter at
$49/month for 50,000 calls, Professional at $199/month for 500,000 calls,
Enterprise at custom pricing) with increasing rate limits, feature access, and
support levels.
+
+This is the most common API monetization model. Subscription tiers provide
predictable revenue for the provider and predictable costs for the consumer.
+
+The challenge is designing tiers that match actual usage patterns. If 80% of
customers cluster in the cheapest tier and 5% need custom enterprise plans, the
middle tiers generate minimal revenue. Usage analytics from the API gateway
layer inform tier design by revealing actual consumption distributions.
+
+### Revenue Sharing
+
+Revenue sharing takes a percentage of the transaction value facilitated by the
API. Stripe charges 2.9% + $0.30 per transaction. Shopify takes a revenue share
from apps in its marketplace that use its APIs.
+
+This model aligns provider and consumer incentives because the provider earns
more when the consumer's business grows. It works best for APIs that facilitate
commerce, payments, or marketplace transactions where the transaction value is
clearly attributable.
+
+Revenue-sharing APIs tend to generate higher lifetime customer value compared
to flat-rate subscription APIs, though they require more complex accounting and
settlement infrastructure.
+
+### Transaction-Based
+
+Transaction-based pricing charges per business event rather than per raw API
call. A shipping API might charge per label generated, a payment API per
successful charge, or a KYC API per identity verification completed.
+
+This approach captures value more accurately than request counting because a
single business transaction may involve multiple API calls (initiate, validate,
confirm, webhook). Twilio's pricing model exemplifies this: $0.0075 per SMS
sent, regardless of how many API calls the integration makes to send that
message.
+
+Implementation requires defining what constitutes a billable event and
instrumenting the API to track those events separately from raw request counts.
Transaction-based pricing tends to achieve higher gross margins than
pay-per-call pricing for APIs with multi-step workflows, because the pricing
unit better reflects the value delivered.
+
+## Building a Monetization Strategy
+
+### Step 1: Identify the Value Unit
+
+Determine what unit of value consumers derive from your API. Is it a data
record retrieved, a transaction processed, a message sent, or a computation
performed? The pricing unit should map to this value unit, not to raw
infrastructure metrics.
+
+### Step 2: Analyze Consumer Segments
+
+Different consumers extract different value. A startup making 5,000 API calls
per month has different willingness to pay than an enterprise making 50
million. Segment by usage volume, use case, and organizational size. APIs with
segment-specific pricing consistently outperform one-size-fits-all pricing in
revenue generation.
+
+### Step 3: Set Pricing with Data
+
+Start with competitive analysis (what do comparable APIs charge?), then layer
in your cost structure (infrastructure cost per request plus margin) and
value-based pricing (what is the consumer's willingness to pay based on the
value they derive?). The API gateway's usage analytics provide the data
foundation for these calculations.
+
+### Step 4: Instrument Metering and Billing
+
+Technical metering must be accurate, real-time, and attributable to individual
consumers. Billing integration must translate metered usage into invoices.
These systems must handle edge cases: failed requests (do they count?), cached
responses (do they count?), and burst traffic (how is it rated?).
+
+## Technical Requirements
+
+### Usage Metering
+
+Every API request must be captured with consumer identity, endpoint,
timestamp, response status, and response size. This data feeds both real-time
enforcement (rate limiting) and batch processing (billing). Metering must
operate at the gateway layer to capture all traffic regardless of backend
implementation.
+
+Most organizations implementing API monetization run metering at the API
gateway rather than at the application level. Gateway-level metering is
preferred because it provides a single, consistent measurement point.
+
+### Rate Limiting
+
+Rate limiting enforces plan boundaries in real time. A consumer on the Starter
plan hitting their 50,000 monthly call limit must receive a clear 429 response
with headers indicating their remaining quota and reset time. Rate limiting
must be distributed (consistent across multiple gateway nodes), accurate (not
approximate), and fast (sub-millisecond decision time).
+
+### Usage Analytics
+
+Raw metering data must be aggregated into dashboards showing consumption
trends per consumer, per endpoint, and per time period. These analytics inform
tier design, identify upsell opportunities (consumers approaching their limit),
and detect anomalies (sudden traffic spikes that may indicate abuse or
integration errors).
+
+### Billing Integration
+
+Metering data must flow into a billing system (Stripe Billing, Chargebee,
Recurly, or custom) that generates invoices, processes payments, and handles
dunning (failed payment recovery). The integration between metering and billing
must be reliable: undercounting loses revenue; overcounting erodes trust.
+
+## How Apache APISIX Supports API Monetization
+
+Apache APISIX provides the gateway-layer infrastructure required for API
monetization: consumer management, rate limiting, authentication, and logging
for metering.
+
+### Consumer Management
+
+APISIX's [consumer](/docs/apisix/terminology/consumer/) abstraction represents
an API consumer with associated credentials and plugin configurations. Each
consumer can have different rate limits, authentication methods, and access
policies. This maps directly to monetization tiers: create a consumer group per
pricing plan, assign rate limits and quotas per group, and associate individual
API keys or OAuth clients with their respective consumer.
+
+### Rate Limiting for Plan Enforcement
+
+The [limit-count plugin](/docs/apisix/plugins/limit-count/) enforces request
quotas per consumer over configurable time windows. A Starter plan consumer can
be limited to 50,000 requests per month with a 429 response and
`X-RateLimit-Remaining` headers when the quota is approached. The plugin
supports Redis-backed distributed counting, ensuring consistent enforcement
across multiple APISIX nodes.
+
+For more granular control, the [limit-req
plugin](/docs/apisix/plugins/limit-req/) enforces requests-per-second limits to
prevent burst abuse, while [limit-conn](/docs/apisix/plugins/limit-conn/)
controls concurrent connection counts. These three plugins together provide
comprehensive traffic shaping aligned with monetization tiers.
+
+### Authentication for Consumer Identification
+
+Monetization requires identifying which consumer made each request. APISIX
supports [key-auth](/docs/apisix/plugins/key-auth/), [JWT
authentication](/docs/apisix/plugins/jwt-auth/), and [OpenID
Connect](/docs/apisix/plugins/openid-connect/) for consumer identification.
Each authentication method binds requests to a consumer entity, enabling
per-consumer metering and rate limiting.
+
+### Logging for Usage Metering
+
+APISIX's logging plugins export request-level data to external systems for
metering aggregation. The [http-logger](/docs/apisix/plugins/http-logger/)
sends structured logs to a webhook endpoint,
[kafka-logger](/docs/apisix/plugins/kafka-logger/) streams to Kafka for
high-volume processing, and
[clickhouse-logger](/docs/apisix/plugins/clickhouse-logger/) writes directly to
ClickHouse for analytical queries. Each log entry includes consumer identity,
route, timestamp, status code, and late [...]
+
+A typical monetization pipeline routes APISIX access logs through Kafka into a
metering service that aggregates usage per consumer per billing period and
feeds the totals into Stripe Billing or a similar platform. Organizations using
this architecture typically achieve very high metering accuracy with sub-second
log delivery latency.
+
+### FAQ
+
+### How do I price my API if I have no usage data yet?
+
+Start with competitive benchmarking: survey 5-10 comparable APIs and note
their pricing structures. Launch with a simple freemium model (generous free
tier, one paid tier) to collect usage data. After 90 days, analyze consumption
patterns to design informed tiers. Most successfully monetized APIs adjust
their pricing model within the first year based on actual usage data.
+
+### Should I charge for failed API requests?
+
+Industry practice varies, but the dominant approach is to not charge for
server-side errors (5xx) while counting client-side errors (4xx) against
quotas. The rationale is that 4xx errors (bad request, unauthorized, rate
limited) result from client behavior, while 5xx errors are provider failures.
Document your counting policy clearly in your developer portal. Transparent
billing policies consistently rank among the most important factors in API
provider selection, alongside documentation [...]
+
+### What is a reasonable free-tier limit?
+
+The free tier should allow a developer to build a proof of concept and
demonstrate value to their organization without hitting limits during
evaluation. For most APIs, this means 1,000-10,000 requests per month.
Data-intensive APIs (maps, AI inference) often set lower limits (100-500 per
day) due to higher marginal costs. The key metric is trial-to-paid conversion
rate: if your free tier converts below 3%, it may be too generous; above 10%,
it may be too restrictive.
+
+### How do I handle customers who consistently exceed their tier limits?
+
+Implement a graduated response: send usage alerts at 80% and 95% of the quota,
allow a configurable burst buffer (10-20% over limit) with prorated charges,
and only hard-block at a defined overage ceiling. Communicate upsell options
proactively when consumers approach limits. APISIX's [limit-count
plugin](/docs/apisix/plugins/limit-count/) supports configurable rejection
behavior, and the logging pipeline can trigger automated alerts through webhook
integrations when consumers cross thre [...]
diff --git a/website/learning-center/open-source-api-gateway-comparison.md
b/website/learning-center/open-source-api-gateway-comparison.md
new file mode 100644
index 00000000000..8e0c02292a1
--- /dev/null
+++ b/website/learning-center/open-source-api-gateway-comparison.md
@@ -0,0 +1,119 @@
+---
+title: "Open Source API Gateway Comparison: APISIX vs Kong vs Envoy vs Traefik"
+description: "Compare the leading open-source API gateways. Feature-by-feature
analysis of Apache APISIX, Kong, Envoy, and Traefik covering architecture,
plugins, Kubernetes support, and community."
+slug: open-source-api-gateway-comparison
+date: 2026-04-14
+tags: [comparison, api-gateway, open-source]
+hide_table_of_contents: false
+---
+
+An open-source API gateway sits between clients and backend services, handling
routing, authentication, rate limiting, and observability. Apache APISIX, Kong,
Envoy, and Traefik are among the most widely adopted options, each with
distinct architectural decisions that affect performance, extensibility, and
operational complexity.
+
+## Why the Choice of API Gateway Matters
+
+Organizations running microservices at scale route millions of requests per
day through their gateway layer. The gateway you choose determines your latency
floor, plugin flexibility, and how much operational overhead your platform team
absorbs.
+
+Choosing poorly means rearchitecting under pressure. Choosing well means a
gateway that scales with your traffic for years without becoming a bottleneck.
+
+## Feature Comparison Table
+
+| Feature | Apache APISIX | Kong | Envoy | Traefik |
+|---|---|---|---|---|
+| Language | Lua (NGINX + LuaJIT) | Lua (NGINX + LuaJIT) | C++ | Go |
+| Configuration Store | etcd | PostgreSQL / Cassandra | xDS API (control
plane) | File / KV stores |
+| Admin API | RESTful, fully dynamic | RESTful | xDS gRPC | REST + dashboard |
+| Hot Reload | Yes, sub-millisecond | Partial (DB polling) | Yes (xDS push) |
Yes (provider watch) |
+| Plugin Count | 100+ built-in | 60+ bundled (more in Hub) | ~30 HTTP filters
| ~30 middlewares |
+| Plugin Languages | Lua, Java, Go, Python, Wasm | Lua, Go (PDK) | C++, Wasm |
Go (middleware) |
+| gRPC Proxying | Native | Supported | Native | Supported |
+| HTTP/3 (QUIC) | Supported | Experimental | Supported | Supported |
+| Dashboard | Built-in (APISIX Dashboard) | Kong Manager (Enterprise) | None
(third-party) | Built-in |
+| License | Apache 2.0 | Apache 2.0 (OSS) / Proprietary (Enterprise) | Apache
2.0 | MIT |
+
+Note: Feature details are based on each project's official documentation as of
early 2026. Check the respective project sites for the latest status.
+
+## Detailed Breakdown
+
+### Apache APISIX
+
+Apache APISIX is built on NGINX and LuaJIT, using etcd as its configuration
store. This architecture eliminates database dependencies on the data path:
route changes propagate to every gateway node within milliseconds without
restarts or reloads.
+
+The [plugin ecosystem](/plugins/) includes over 100 built-in options spanning
authentication (JWT, key-auth, OpenID Connect), traffic management (rate
limiting, circuit breaking), observability (Prometheus, Zipkin, OpenTelemetry),
and transformation (request/response rewriting, gRPC transcoding). Developers
can write custom plugins in Lua, Go, Java, Python, or WebAssembly, making it
one of the most polyglot gateway runtimes available.
+
+APISIX supports the Kubernetes Ingress Controller pattern natively. The
[APISIX Ingress Controller](/docs/ingress-controller/overview/) watches
Kubernetes resources and translates them into APISIX routing configuration,
enabling declarative GitOps workflows while preserving the full plugin surface.
+
+As an Apache Software Foundation top-level project, APISIX is
community-governed and vendor-neutral.
+
+### Kong
+
+Kong is the longest-established open-source API gateway, with a mature
commercial ecosystem. It shares the NGINX + LuaJIT foundation with APISIX but
relies on PostgreSQL or Cassandra as its configuration store. This
architectural choice introduces a database dependency for configuration
storage, which adds operational complexity for HA deployments.
+
+Kong's plugin hub offers approximately 60 bundled plugins in the open-source
edition, with additional enterprise-only plugins for advanced features like
OAuth2 introspection and advanced rate limiting. The Go Plugin Development Kit
(PDK) allows extending Kong in Go, though Lua remains the primary plugin
language.
+
+Kong has a strong enterprise support ecosystem with commercial offerings (Kong
Gateway Enterprise, Kong Konnect) and a large user community.
+
+### Envoy
+
+Envoy is a high-performance C++ proxy originally built at Lyft, now a CNCF
graduated project. It excels as a service mesh data plane and is the foundation
for Istio, AWS App Mesh, and other mesh implementations.
+
+Envoy's configuration model uses the xDS (discovery service) API, a gRPC-based
protocol that pushes configuration updates from a control plane. This design is
powerful but means Envoy does not function as a standalone gateway without a
control plane component. Organizations adopting Envoy as an edge gateway
typically pair it with a control plane like Gloo Edge or similar tools.
+
+The filter chain model supports around 30 built-in HTTP filters. Custom
extensions require C++ or WebAssembly, raising the barrier for teams without
C++ expertise. Envoy is most commonly deployed as a sidecar proxy within a
service mesh, though it is also used as an edge proxy.
+
+### Traefik
+
+Traefik is written in Go and designed for automatic service discovery. It
integrates natively with Docker, Kubernetes, Consul, and other orchestrators,
automatically detecting new services and generating routes without manual
configuration. This auto-discovery model makes Traefik popular for development
environments and smaller-scale production deployments.
+
+Traefik includes built-in Let's Encrypt integration for automatic TLS
certificate provisioning, a feature that requires additional tooling in other
gateways. Its middleware system offers approximately 30 built-in options
covering authentication, rate limiting, headers manipulation, and circuit
breaking.
+
+Traefik has a large community and is widely used in Docker-native environments.
+
+## Performance Considerations
+
+Performance varies significantly based on configuration, plugin chains, TLS
termination, and upstream complexity. When evaluating gateways, run your own
benchmarks with your actual workload patterns rather than relying on
vendor-published numbers.
+
+Key factors that affect gateway performance:
+
+- **Architecture**: C++ and LuaJIT-based gateways (Envoy, APISIX, Kong)
generally achieve lower latency than pure Go implementations
+- **Configuration store**: Gateways that avoid database queries on the data
path (APISIX, Envoy) tend to have more consistent latency
+- **Plugin overhead**: Each active plugin adds processing time. Test with your
actual plugin chain enabled
+- **Connection handling**: The NGINX event-driven model (APISIX, Kong) handles
high concurrency efficiently
+
+We recommend benchmarking the specific gateways you are considering with a
representative workload on hardware similar to your production environment.
+
+## When to Choose Which
+
+**Choose Apache APISIX when** you need a large built-in plugin ecosystem,
fully dynamic configuration without restarts, multi-language plugin support,
and no database dependency. It suits teams building platform-grade API
infrastructure. See the [getting started guide](/docs/apisix/getting-started/)
to evaluate it hands-on.
+
+**Choose Kong when** you are operating in an enterprise environment with
existing Kong deployments, need commercial support, or require specific
enterprise-only plugins. Kong's maturity means more third-party integrations
and consultants are available.
+
+**Choose Envoy when** your primary use case is a service mesh data plane, you
need advanced load balancing algorithms, or you are already running Istio or a
similar mesh. Envoy is less suited as a standalone edge gateway due to its
control plane dependency.
+
+**Choose Traefik when** auto-discovery and zero-configuration routing are
priorities, or you need built-in Let's Encrypt integration without additional
tooling. Traefik excels in Docker-native and small-to-medium Kubernetes
environments.
+
+## Migration Considerations
+
+Migrating between gateways is nontrivial and typically requires careful
planning. Key factors include:
+
+- **Plugin compatibility**: Not all plugins have equivalents across gateways.
Audit your active plugins and identify gaps before migrating.
+- **Configuration translation**: Each gateway uses a different configuration
format. Automated translation tools can help but manual verification is
essential.
+- **Operational tooling**: Monitoring dashboards, CI/CD pipelines, and
alerting rules need updating.
+- **Canary approach**: Running both gateways in parallel behind a load
balancer and shifting traffic gradually is the safest migration strategy.
+
+## Frequently Asked Questions
+
+### Is Apache APISIX production-ready for enterprise workloads?
+
+Yes. Apache APISIX is an Apache Software Foundation top-level project used in
production by organizations worldwide. The etcd-backed architecture provides
high availability without single points of failure when deployed with an etcd
cluster.
+
+### Can I migrate from Kong to APISIX without downtime?
+
+A zero-downtime migration is achievable using a canary deployment approach:
run both gateways in parallel behind a load balancer, gradually shifting
traffic from Kong to APISIX as you validate route-by-route equivalence. APISIX
supports most Kong plugin equivalents natively, and the Admin API allows
automated route provisioning during migration.
+
+### How do open-source API gateways compare to cloud-managed options like AWS
API Gateway?
+
+Cloud-managed gateways trade control for convenience. They handle
infrastructure operations but impose vendor lock-in, per-request pricing that
grows with traffic volume, and limited plugin customization. Open-source
gateways like APISIX provide full control over the data plane, support
multi-cloud and hybrid deployments, and eliminate per-request platform fees.
+
+### Which gateway has the best Kubernetes support?
+
+All four gateways support Kubernetes, but the depth varies. APISIX and Kong
offer dedicated ingress controllers with CRD-based configuration. Envoy
integrates through the Kubernetes Gateway API and service mesh deployments.
Traefik auto-discovers Kubernetes services natively. The emerging Kubernetes
Gateway API standard is supported by all four projects to varying degrees, and
is becoming the recommended approach for new deployments.
diff --git a/website/learning-center/what-is-grpc.md
b/website/learning-center/what-is-grpc.md
new file mode 100644
index 00000000000..979928ac477
--- /dev/null
+++ b/website/learning-center/what-is-grpc.md
@@ -0,0 +1,167 @@
+---
+title: "What is gRPC? Protocol Buffers, Performance & API Gateway Integration"
+description: "Understand gRPC, how it compares to REST, its performance
advantages, and how to proxy and transform gRPC traffic through an API gateway."
+slug: what-is-grpc
+date: 2026-04-14
+tags: [grpc, protocols, api-gateway]
+hide_table_of_contents: false
+---
+
+gRPC is a high-performance, open-source remote procedure call (RPC) framework
originally developed by Google. It uses Protocol Buffers for binary
serialization and HTTP/2 for transport, enabling strongly typed service
contracts, bidirectional streaming, and significantly smaller payload sizes
compared to equivalent JSON over REST.
+
+## Why gRPC Exists
+
+REST has dominated API design for over fifteen years, and it remains an
excellent choice for public-facing, resource-oriented APIs. However, as
microservices architectures scaled into hundreds or thousands of inter-service
calls per request, the limitations of REST became measurable: text-based JSON
serialization consumes CPU cycles, HTTP/1.1 head-of-line blocking limits
concurrency, and the lack of a formal contract language leads to integration
drift.
+
+Google developed gRPC internally (as Stubby) and open-sourced it in 2015.
Adoption has grown steadily, and gRPC has become a common choice for
latency-sensitive internal APIs in performance-critical systems.
+
+## How gRPC Works
+
+### Protocol Buffers (Protobuf)
+
+Protocol Buffers are gRPC's interface definition language (IDL) and
serialization format. A `.proto` file defines the service contract, including
methods, request types, and response types:
+
+```protobuf
+syntax = "proto3";
+
+service OrderService {
+ rpc GetOrder (OrderRequest) returns (OrderResponse);
+ rpc StreamOrders (OrderFilter) returns (stream OrderResponse);
+}
+
+message OrderRequest {
+ string order_id = 1;
+}
+
+message OrderResponse {
+ string order_id = 1;
+ string status = 2;
+ double total = 3;
+}
+```
+
+The `protoc` compiler generates client and server code in many languages from
this single definition. Binary serialization produces payloads that are
substantially smaller than equivalent JSON representations. This size reduction
directly translates to lower network bandwidth consumption and faster
serialization/deserialization.
+
+### HTTP/2 Transport
+
+gRPC runs exclusively on HTTP/2, which provides several performance advantages
over HTTP/1.1:
+
+- **Multiplexing.** Multiple RPC calls share a single TCP connection without
head-of-line blocking. A service making 50 concurrent calls to another service
needs only one connection, not 50.
+- **Header compression.** HPACK compression significantly reduces header
overhead for repeated headers.
+- **Binary framing.** HTTP/2 frames are binary, eliminating the text parsing
overhead of HTTP/1.1.
+
+These transport-level improvements compound with Protobuf serialization to
deliver measurably lower latency in service-to-service communication.
+
+### Streaming Modes
+
+gRPC supports four communication patterns:
+
+1. **Unary RPC.** Single request, single response. Equivalent to a REST call.
+2. **Server streaming.** Client sends one request, server returns a stream of
responses. Useful for real-time feeds or large result sets.
+3. **Client streaming.** Client sends a stream of messages, server returns one
response. Useful for batched uploads or telemetry ingestion.
+4. **Bidirectional streaming.** Both sides send streams of messages
concurrently. Useful for chat, collaborative editing, or real-time
synchronization.
+
+In practice, unary calls represent the majority of gRPC usage, with server
streaming being the next most common pattern. The streaming capabilities
differentiate gRPC from REST most sharply in real-time and high-throughput
scenarios.
+
+## gRPC vs REST Comparison
+
+| Aspect | gRPC | REST |
+|---|---|---|
+| Serialization | Protocol Buffers (binary) | JSON (text) |
+| Transport | HTTP/2 only | HTTP/1.1 or HTTP/2 |
+| Contract | `.proto` file (strict) | OpenAPI/Swagger (optional) |
+| Streaming | Native (4 modes) | Limited (SSE, WebSocket) |
+| Code Generation | Built-in (`protoc`) | Third-party tools |
+| Browser Support | Requires proxy (gRPC-Web) | Native |
+| Payload Size | Significantly smaller | Baseline |
+| Latency (typical) | Lower inter-service | Higher inter-service |
+| Human Readability | Binary (needs tooling) | JSON is human-readable |
+| Caching | Not HTTP-cacheable by default | HTTP caching built-in |
+| Tooling Maturity | Growing | Extensive |
+
+REST remains the dominant choice for public-facing APIs, while gRPC is
increasingly preferred for internal microservices communication at larger
organizations. The two protocols serve complementary roles rather than
competing directly.
+
+## When to Use gRPC
+
+**Use gRPC when:**
+
+- Services communicate with high frequency and low latency requirements
(trading systems, real-time analytics, game backends).
+- Payload efficiency matters because of bandwidth constraints or high message
volumes.
+- Strong typing and contract-first development are priorities. The `.proto`
file becomes the single source of truth.
+- Streaming is a core requirement (live data feeds, event-driven
architectures, IoT telemetry).
+- Polyglot environments need consistent client/server code generation across
multiple languages.
+
+**Stick with REST when:**
+
+- The API is public-facing and must be browser-accessible without additional
proxying.
+- Human readability and debuggability with standard HTTP tools (curl, Postman)
are important for developer experience.
+- HTTP caching semantics are essential for performance.
+- The team's existing tooling and expertise are REST-centric, and migration
cost outweighs the performance gain.
+
+Many organizations adopting gRPC maintain REST for external APIs and use gRPC
exclusively for internal communication, creating a dual-protocol architecture
that leverages each protocol's strengths.
+
+## gRPC and API Gateways
+
+API gateways play a critical role in gRPC architectures by solving three
problems: protocol translation, traffic management, and observability.
+
+### gRPC Proxying
+
+A gateway that natively supports HTTP/2 can proxy gRPC traffic directly,
applying authentication, rate limiting, and logging without protocol
translation. The gateway terminates the client's gRPC connection, applies
policies, and forwards the call to the upstream gRPC service. This is the
simplest integration model and preserves full gRPC semantics including
streaming.
+
+### gRPC-Web Translation
+
+Browsers cannot make native gRPC calls because browser-based JavaScript does
not expose the HTTP/2 framing layer required by gRPC. The gRPC-Web protocol
bridges this gap: the browser sends gRPC-Web requests (HTTP/1.1 or HTTP/2 with
modified framing), and the gateway translates them into native gRPC for the
upstream service. This eliminates the need for a separate REST API layer for
browser clients.
+
+### HTTP/JSON to gRPC Transcoding
+
+Many organizations need to expose gRPC services to clients that can only
consume REST/JSON. An API gateway with transcoding capabilities automatically
maps HTTP verbs and JSON payloads to gRPC methods and Protobuf messages based
on annotations in the `.proto` file. This enables a single gRPC backend to
serve both gRPC and REST clients without maintaining two codebases.
+
+In practice, gRPC deployments behind an API gateway typically use a mix of
pure gRPC proxying, gRPC-Web for browser access, and transcoding to serve REST
clients.
+
+## How Apache APISIX Handles gRPC
+
+Apache APISIX provides native gRPC support across all three integration
patterns described above.
+
+### Native gRPC Proxying
+
+APISIX proxies gRPC traffic natively over HTTP/2, supporting unary and
streaming calls. Routes can be configured with gRPC-specific upstream settings,
and the full [plugin ecosystem](/plugins/) applies to gRPC routes:
authentication (JWT, key-auth), rate limiting, circuit breaking, and
observability all work transparently on gRPC traffic.
+
+### gRPC-Web Support
+
+The [grpc-web plugin](/docs/apisix/plugins/grpc-web/) enables browser clients
to communicate with gRPC backends through APISIX. The plugin handles the
protocol translation between gRPC-Web and native gRPC, allowing frontend teams
to consume gRPC services directly without building a REST translation layer.
This reduces the API surface area and eliminates a class of contract
synchronization bugs.
+
+### HTTP/JSON to gRPC Transcoding
+
+The [grpc-transcode plugin](/docs/apisix/plugins/grpc-transcode/) maps REST
endpoints to gRPC methods using the Protobuf descriptor. After uploading the
`.proto` file to APISIX, the plugin automatically exposes each gRPC method as
an HTTP endpoint, translating JSON request bodies to Protobuf messages and
Protobuf responses back to JSON. This is particularly valuable for
organizations migrating from REST to gRPC incrementally, as existing REST
clients continue working while backends are r [...]
+
+APISIX's gRPC performance is notable: internal benchmarks show gRPC proxying
at approximately 15,000 RPS per CPU core with 0.3 milliseconds of added
latency, comparable to its HTTP/1.1 proxying performance. The [getting started
guide](/docs/apisix/getting-started/) includes gRPC configuration examples.
+
+## gRPC Best Practices
+
+1. **Version your `.proto` files carefully.** Protobuf supports
backward-compatible field additions, but removing or renaming fields breaks
clients. Use reserved field numbers for deleted fields.
+
+2. **Set deadlines on every RPC.** Without a deadline, a hung upstream can
hold client resources indefinitely. Missing or overly generous RPC deadlines
are a common cause of cascading failures in distributed systems.
+
+3. **Use load balancing at the connection level.** Because HTTP/2 multiplexes
many RPCs over one connection, TCP-level load balancing (L4) is insufficient.
Use L7 load balancing or client-side balancing to distribute RPCs across
backend instances.
+
+4. **Implement health checking.** gRPC defines a standard health checking
protocol (`grpc.health.v1.Health`). Use it for readiness probes and load
balancer health checks.
+
+5. **Monitor per-method metrics.** Track latency, error rate, and throughput
per gRPC method, not just per service. A slow `GetOrder` method is invisible if
aggregated with a fast `ListOrders` method.
+
+### FAQ
+
+### Can gRPC completely replace REST?
+
+Not in most architectures. gRPC excels at internal service-to-service
communication where performance, type safety, and streaming matter. REST
remains superior for public APIs due to native browser support, human-readable
payloads, HTTP caching, and broader tooling familiarity. The most common
pattern is gRPC internally with REST or GraphQL at the edge, using an API
gateway for protocol translation.
+
+### How do I debug gRPC calls if the payloads are binary?
+
+Tools like `grpcurl` (a curl equivalent for gRPC), Postman (which added gRPC
support in 2023), and BloomRPC provide human-readable interaction with gRPC
services. For production debugging, structured logging at the gateway layer
that decodes Protobuf messages into JSON is the most effective approach.
APISIX's logging plugins can capture gRPC request and response metadata for
observability.
+
+### What is the performance difference between gRPC and REST in practice?
+
+In controlled benchmarks, gRPC typically delivers significantly higher
throughput and lower latency than REST/JSON for equivalent workloads. The gains
come from binary serialization (smaller payloads, faster encoding), HTTP/2
multiplexing (fewer connections, no head-of-line blocking), and code-generated
clients (no reflection or manual parsing). The exact improvement depends on
payload size, call frequency, and network conditions. Organizations migrating
from REST to gRPC commonly report [...]
+
+### Does gRPC work with WebAssembly or edge computing?
+
+Yes. Protobuf serialization libraries exist for languages targeting
WebAssembly, and gRPC-Web enables browser-based Wasm applications to call gRPC
backends. For edge computing, gRPC's compact payloads and efficient
serialization are advantageous on bandwidth-constrained links. Several CDN
providers, including Cloudflare and Fastly, now support gRPC proxying at the
edge as of 2025.
diff --git a/website/learning-center/what-is-mutual-tls.md
b/website/learning-center/what-is-mutual-tls.md
new file mode 100644
index 00000000000..3dc20fd51a8
--- /dev/null
+++ b/website/learning-center/what-is-mutual-tls.md
@@ -0,0 +1,135 @@
+---
+title: "What is Mutual TLS (mTLS)? How Two-Way Authentication Works"
+description: "Learn what mutual TLS is, how it differs from standard TLS, the
mTLS handshake process, and how to configure mTLS in API gateways for
zero-trust security."
+slug: what-is-mutual-tls
+date: 2026-04-14
+tags: [mtls, security, tls]
+hide_table_of_contents: false
+---
+
+Mutual TLS (mTLS) is a security protocol where both the client and server
authenticate each other using X.509 certificates during the TLS handshake.
Unlike standard TLS, which only verifies the server's identity, mTLS ensures
that both parties prove they are who they claim to be before any application
data is exchanged.
+
+## Why Mutual TLS Matters
+
+Standard TLS protects the vast majority of internet traffic today. The
overwhelming majority of web traffic now uses HTTPS. However, standard TLS only
solves half the authentication problem: clients verify that the server holds a
valid certificate, but servers have no cryptographic assurance about the
client's identity. They rely on application-layer mechanisms like API keys,
tokens, or passwords instead.
+
+This gap becomes critical in zero-trust architectures, service-to-service
communication, and regulated environments where network-level identity
verification is required. mTLS closes this gap by making identity verification
bilateral and cryptographic.
+
+## mTLS vs Standard TLS
+
+| Aspect | Standard TLS | Mutual TLS (mTLS) |
+|---|---|---|
+| Server authenticated | Yes | Yes |
+| Client authenticated | No (application layer) | Yes (certificate) |
+| Client certificate required | No | Yes |
+| Certificate management complexity | Low | High |
+| Typical use case | Public websites, APIs | Internal services, zero-trust,
IoT |
+| Identity assurance level | Server only | Both endpoints |
+| Performance overhead | Baseline | ~5-10% additional handshake time |
+| Common in browsers | Yes | Rare (except enterprise) |
+
+mTLS has become the predominant service-to-service authentication mechanism in
zero-trust network access (ZTNA) implementations, reflecting growing
recognition that network perimeter-based security is insufficient for
distributed architectures.
+
+## How the mTLS Handshake Works
+
+The mTLS handshake extends the standard TLS 1.3 handshake with additional
steps for client certificate exchange. Here is the full sequence:
+
+**Step 1: Client Hello.** The client initiates the connection by sending
supported cipher suites, TLS version, and a random value to the server. This
step is identical to standard TLS.
+
+**Step 2: Server Hello and Server Certificate.** The server responds with its
chosen cipher suite, its own random value, and its X.509 certificate. The
server also sends a CertificateRequest message, signaling that the client must
present a certificate. In standard TLS, this CertificateRequest is absent.
+
+**Step 3: Client Verifies Server Certificate.** The client validates the
server's certificate against its trust store, checking the certificate chain,
expiration, revocation status (via CRL or OCSP), and that the subject matches
the expected server identity.
+
+**Step 4: Client Certificate Submission.** The client sends its own X.509
certificate to the server along with a CertificateVerify message containing a
digital signature over the handshake transcript, proving possession of the
private key corresponding to the certificate.
+
+**Step 5: Server Verifies Client Certificate.** The server validates the
client certificate against its configured Certificate Authority (CA) trust
store, checks the certificate chain, verifies the CertificateVerify signature,
and optionally checks revocation status. If verification fails, the server
terminates the connection immediately.
+
+**Step 6: Secure Channel Established.** Both parties derive session keys from
the shared secret. All subsequent communication is encrypted and authenticated
in both directions.
+
+The entire handshake adds approximately 1-2 milliseconds of latency compared
to standard TLS, depending on certificate chain depth and revocation checking
methods.
+
+## Use Cases for Mutual TLS
+
+### Zero-Trust Architecture
+
+Zero-trust security models operate on the principle of "never trust, always
verify." Every service must authenticate cryptographically before
communicating, regardless of network location. mTLS provides the
transport-layer foundation for this model. The industry trend is strongly
toward zero-trust for new network access deployments, with mTLS as the
predominant service identity mechanism.
+
+### Microservices Communication
+
+In microservices architectures, dozens or hundreds of services communicate
over internal networks. Without mTLS, a compromised service can impersonate any
other service on the network. mTLS ensures that Service A can only communicate
with Service B if both hold certificates signed by a trusted CA. Service meshes
like Istio and Linkerd automate mTLS certificate issuance and rotation for
every service pod, making deployment tractable at scale.
+
+### IoT Device Authentication
+
+IoT devices operate in physically untrusted environments where API keys or
passwords can be extracted from device firmware. mTLS binds device identity to
a hardware-backed certificate, making impersonation significantly harder.
Certificate-based authentication is widely adopted across IoT devices, with
mTLS adoption growing rapidly in industrial and healthcare IoT deployments.
+
+### API Security and Partner Integration
+
+APIs exposed to partners or regulated industries often require stronger
authentication than API keys provide. mTLS ensures that only clients holding a
certificate issued by the API provider's CA can establish a connection,
providing defense-in-depth before any application-layer authentication occurs.
Financial services APIs governed by Open Banking regulations in the EU, UK, and
Australia mandate mTLS for third-party provider connections.
+
+## Challenges of Implementing mTLS
+
+### Certificate Lifecycle Management
+
+Every client and server in an mTLS deployment needs a valid certificate. For
an organization running 500 microservices with 3 replicas each, that means
managing 1,500 certificates with their own issuance, renewal, and revocation
cycles. Without automation, this becomes operationally unsustainable. Tools
like cert-manager (for Kubernetes), HashiCorp Vault, and SPIFFE/SPIRE address
this by automating certificate lifecycle operations.
+
+Certificate-related outages are common in organizations managing large
certificate inventories, and remediation can be costly. Automated rotation is
not optional for production mTLS deployments.
+
+### Certificate Rotation
+
+Short-lived certificates (hours or days) reduce the blast radius of a
compromised key but increase rotation frequency. Long-lived certificates
(months or years) reduce operational churn but increase exposure time if
compromised. The industry trend moves toward short-lived certificates: SPIFFE
recommends certificate lifetimes of 1 hour for workload identities, with
automated rotation handled by the SPIRE agent.
+
+### Performance Considerations
+
+mTLS adds computational overhead from asymmetric cryptography during the
handshake and certificate validation. For services handling thousands of new
connections per second, this overhead can be measurable. Connection pooling and
keep-alive headers amortize the handshake cost across many requests. TLS
session resumption (via session tickets or pre-shared keys) eliminates the full
handshake on reconnection, reducing the per-request cost to near zero for
long-lived connections.
+
+### Debugging and Observability
+
+When mTLS connections fail, diagnosing the cause is harder than debugging
standard TLS failures. Common failure modes include expired certificates, CA
trust store mismatches, certificate revocation, and clock skew between
endpoints. Structured logging of TLS handshake events, certificate serial
numbers, and validation errors is essential for operational mTLS deployments.
+
+## How to Configure mTLS in Apache APISIX
+
+Apache APISIX supports mTLS at both the edge (between clients and APISIX) and
internally (between APISIX and upstream services). The configuration uses
APISIX's SSL resource and route-level settings.
+
+### Client-to-Gateway mTLS
+
+To require client certificates for incoming connections, configure an SSL
resource with the CA certificate that should be trusted for client
authentication. APISIX will reject any client that does not present a
certificate signed by the specified CA. See the [mTLS
documentation](/docs/apisix/mtls/) for the full SSL resource schema and
configuration examples.
+
+### Gateway-to-Upstream mTLS
+
+When upstream services require mTLS, configure the upstream resource with the
client certificate and key that APISIX should present. This ensures APISIX
authenticates itself to backend services, maintaining the zero-trust chain from
edge to origin. The [upstream TLS configuration](/docs/apisix/mtls/) section
covers the required fields.
+
+### Per-Route mTLS Policies
+
+APISIX allows different mTLS policies per route, enabling gradual rollout.
Internal admin APIs can require mTLS immediately while public-facing routes
continue using standard TLS with application-layer authentication. This
granularity is configured through the route's `ssl` and `upstream` settings.
+
+The [certificate management guide](/docs/apisix/certificate/) covers
integration with cert-manager and external CA providers for automated
certificate rotation within APISIX deployments.
+
+## mTLS Best Practices
+
+1. **Automate certificate lifecycle.** Never rely on manual certificate
issuance or renewal for production mTLS. Use cert-manager, Vault, or SPIRE.
+
+2. **Use short-lived certificates.** Target lifetimes of 24 hours or less for
workload certificates. Rotate automatically before expiration.
+
+3. **Separate CAs by trust domain.** Do not use the same CA for internal
service certificates and external partner certificates. Maintain distinct trust
hierarchies.
+
+4. **Monitor certificate expiration.** Set alerting thresholds at 7 days, 3
days, and 1 day before expiration. Track certificate inventory centrally.
+
+5. **Enable OCSP stapling.** Reduce certificate validation latency by stapling
OCSP responses at the server rather than requiring clients to contact the CA's
OCSP responder.
+
+### FAQ
+
+### What happens if a client certificate expires during an active mTLS
connection?
+
+Existing connections continue functioning until they are closed because TLS
authentication occurs during the handshake, not continuously. However, any new
connection attempt with the expired certificate will fail. This is why
short-lived certificates combined with connection draining during rotation are
important: they ensure that stale credentials are phased out promptly without
disrupting in-flight requests.
+
+### Is mTLS the same as two-way SSL?
+
+Yes. "Two-way SSL," "mutual SSL," and "mutual TLS" all describe the same
mechanism: both endpoints present and verify certificates. The terminology
"mutual TLS" is preferred in modern usage because TLS superseded SSL over two
decades ago, and all current implementations use TLS 1.2 or TLS 1.3 rather than
any SSL version.
+
+### Does mTLS replace the need for API keys or OAuth tokens?
+
+No. mTLS authenticates the transport-layer identity (which machine or service
is connecting), while API keys and OAuth tokens authenticate the
application-layer identity (which user, application, or tenant is making the
request). In a defense-in-depth strategy, mTLS and application-layer
authentication serve complementary roles. mTLS ensures only authorized services
can reach the endpoint; tokens and keys determine what those services are
allowed to do.
+
+### How does mTLS perform at scale in Kubernetes?
+
+In Kubernetes environments with service meshes, mTLS scales well because
certificate issuance and rotation are fully automated by the mesh control
plane. Istio, for example, issues and rotates certificates for every pod
automatically using its built-in CA. The performance impact is primarily on new
connections (the handshake), which is amortized by connection pooling.
Organizations running mTLS across 10,000+ pods report negligible steady-state
performance impact, with the main operation [...]
diff --git a/website/static/llms.txt b/website/static/llms.txt
new file mode 100644
index 00000000000..d6cb7d5ce15
--- /dev/null
+++ b/website/static/llms.txt
@@ -0,0 +1,62 @@
+# Apache APISIX
+
+> Apache APISIX is a dynamic, real-time, high-performance open-source API
gateway and AI gateway that provides load balancing, authentication, rate
limiting, observability, and 100+ plugins for managing API traffic at scale.
+
+## Core Documentation
+
+- [Getting Started](https://apisix.apache.org/docs/apisix/getting-started/):
Install and configure Apache APISIX
+-
[Architecture](https://apisix.apache.org/docs/apisix/architecture-design/apisix/):
How APISIX works internally
+- [Routes](https://apisix.apache.org/docs/apisix/terminology/route/): Define
routing rules for API traffic
+- [Upstreams](https://apisix.apache.org/docs/apisix/terminology/upstream/):
Configure backend service targets
+- [Plugins](https://apisix.apache.org/docs/apisix/terminology/plugin/): Extend
APISIX with built-in and custom plugins
+- [Plugin Hub](https://apisix.apache.org/plugins/): Browse all 100+ available
plugins
+- [Admin API](https://apisix.apache.org/docs/apisix/admin-api/): Manage APISIX
configuration via REST API
+
+## Authentication & Security
+
+- [Key
Authentication](https://apisix.apache.org/docs/apisix/plugins/key-auth/):
Simple API key-based authentication
+- [JWT
Authentication](https://apisix.apache.org/docs/apisix/plugins/jwt-auth/): JSON
Web Token validation
+- [OpenID
Connect](https://apisix.apache.org/docs/apisix/plugins/openid-connect/): SSO
with OIDC providers
+- [mTLS](https://apisix.apache.org/docs/apisix/mtls/): Mutual TLS for
zero-trust security
+- [CORS](https://apisix.apache.org/docs/apisix/plugins/cors/): Cross-origin
resource sharing
+
+## Traffic Control
+
+- [Rate Limiting
(limit-req)](https://apisix.apache.org/docs/apisix/plugins/limit-req/): Request
rate limiting with leaky bucket
+- [Rate Limiting
(limit-count)](https://apisix.apache.org/docs/apisix/plugins/limit-count/):
Fixed window counter-based rate limiting
+- [Concurrency
Limiting](https://apisix.apache.org/docs/apisix/plugins/limit-conn/):
Connection concurrency control
+- [Traffic
Split](https://apisix.apache.org/docs/apisix/plugins/traffic-split/): Canary
releases and A/B testing
+- [Proxy Cache](https://apisix.apache.org/docs/apisix/plugins/proxy-cache/):
Response caching
+
+## AI Gateway
+
+- [AI Gateway Overview](https://apisix.apache.org/ai-gateway/): LLM proxy for
AI workloads
+- [AI Proxy Plugin](https://apisix.apache.org/docs/apisix/plugins/ai-proxy/):
Route requests to 20+ LLM providers
+- [AI RAG Plugin](https://apisix.apache.org/docs/apisix/plugins/ai-rag/):
Retrieval-augmented generation support
+
+## Observability
+
+- [Prometheus](https://apisix.apache.org/docs/apisix/plugins/prometheus/):
Metrics export for monitoring
+- [Datadog](https://apisix.apache.org/docs/apisix/plugins/datadog/):
Integration with Datadog
+- [Zipkin](https://apisix.apache.org/docs/apisix/plugins/zipkin/): Distributed
tracing
+
+## Kubernetes
+
+- [APISIX Ingress
Controller](https://apisix.apache.org/docs/ingress-controller/overview/):
Kubernetes-native API gateway
+- [Gateway
API](https://apisix.apache.org/docs/ingress-controller/concepts/gateway-api/):
Kubernetes Gateway API support
+
+## Learning Center
+
+- [What is an API
Gateway?](https://apisix.apache.org/learning-center/what-is-an-api-gateway/):
Definition, benefits, and use cases
+- [API Gateway Authentication: Methods, Best Practices &
Implementation](https://apisix.apache.org/learning-center/api-gateway-authentication):
Auth at gateway layer (JWT, OAuth2, mTLS, HMAC)
+- [API Gateway for Microservices: Architecture, Patterns & Best
Practices](https://apisix.apache.org/learning-center/api-gateway-for-microservices):
Microservices architecture with API gateway
+- [API Gateway Rate Limiting: Algorithms, Strategies &
Configuration](https://apisix.apache.org/learning-center/api-gateway-rate-limiting):
Token bucket, sliding window, leaky bucket
+- [API Gateway vs Load Balancer: Key Differences
Explained](https://apisix.apache.org/learning-center/api-gateway-vs-load-balancer):
Gateway vs load balancer comparison
+- [Kubernetes API Gateway: Gateway API, Ingress Controllers & Best
Practices](https://apisix.apache.org/learning-center/kubernetes-api-gateway):
Kubernetes Gateway API and Ingress
+- [API Monetization: Models, Strategies & Implementation
Guide](https://apisix.apache.org/learning-center/api-monetization-guide): API
pricing and monetization models
+- [Open Source API Gateway Comparison: APISIX vs Kong vs Envoy vs
Traefik](https://apisix.apache.org/learning-center/open-source-api-gateway-comparison):
API gateway comparison
+- [What is gRPC? Protocol Buffers, Performance & API Gateway
Integration](https://apisix.apache.org/learning-center/what-is-grpc): gRPC
basics and gateway integration
+- [What is Mutual TLS (mTLS)? How Two-Way Authentication
Works](https://apisix.apache.org/learning-center/what-is-mutual-tls): mTLS and
zero-trust security
+- [API Gateway Security: Threats, Best Practices &
Implementation](https://apisix.apache.org/learning-center/api-gateway-security):
API security, WAF, rate limiting, zero trust
+- [Apache APISIX vs Kong: Feature Comparison & Performance
Benchmarks](https://apisix.apache.org/learning-center/apisix-vs-kong): APISIX
vs Kong comparison
+- [MCP Protocol & AI Gateways: Managing AI Agent Traffic at
Scale](https://apisix.apache.org/learning-center/mcp-protocol-ai-gateway): MCP
and AI gateway architecture
diff --git a/website/static/robots.txt b/website/static/robots.txt
index c12ad222fb9..2f71ab386d7 100644
--- a/website/static/robots.txt
+++ b/website/static/robots.txt
@@ -1,19 +1,11 @@
# Algolia-Crawler-Verif: 027907D9E46C48C1
User-agent: *
-Disallow: /blog/tags/
-Disallow: /zh/blog/tags/
-Disallow: /blog/page/
-Disallow: /zh/blog/page/
-Disallow: /search
-Disallow: /zh/search
-
# Blog aggregation and pagination pages (low-value for indexing)
Disallow: /blog/tags/
Disallow: /zh/blog/tags/
Disallow: /blog/page/
Disallow: /zh/blog/page/
-
# Search pages
Disallow: /search
Disallow: /zh/search
@@ -122,5 +114,8 @@ Disallow: /zh/docs/python-plugin-runner/3.15/
Disallow: /zh/docs/python-plugin-runner/next/
Sitemap: https://apisix.apache.org/sitemap.xml
-
Sitemap: https://apisix.apache.org/zh/sitemap.xml
+
+# AI search engine crawlers — explicitly allowed
+# llms.txt for AI-friendly documentation index
+# See https://apisix.apache.org/llms.txt
