You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by ba...@apache.org on 2026/04/16 01:56:40 UTC
(apisix-website) branch master updated: feat(seo): add GEO optimization (llms.txt) and 4 Learning Center articles (P2) (#2026)
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 <mo...@gmail.com>
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