Context Types 

The extension provides several built-in context types. Each type evaluates different conditions to determine if a context is active.

IP Address Context 

Match visitors by their IP address or IP range. Supports both IPv4 and IPv6.

Configuration 

IP/Range
type

string

required

true

Single IP address, CIDR notation, range, or comma-separated list.

Examples:

  • Single IP: 192.168.1.100
  • CIDR notation: 10.0.0.0/8, FE80::/16
  • Range: 192.168.1.1-192.168.1.255
  • Wildcards: 80.76.201.*, 80.76.*.37
  • Multiple: 192.168.1.0/24,10.0.0.0/8

Use Cases 

  • Internal network detection (show admin tools for office IPs)
  • Geographic content (by IP geolocation with contexts_geolocation)
  • Office vs. external visitor differentiation
  • Development/staging environment detection

Domain Context 

Match based on the accessed domain name (HTTP_HOST).

Configuration 

Domain
type

string

required

true

Domain name(s) to match. One domain per line.

Matching Rules:

  • Without leading dot: Exact match only

    • www.example.org will not match example.org
  • With leading dot: Matches all subdomains

    • .example.org matches www.example.org, shop.example.org, etc.

Examples:

  • Single: www.example.com
  • Multiple (one per line):

    example.com
    www.example.com
    Copied!
  • Subdomain wildcard: .example.com

Use Cases 

  • Multi-domain setups (different content per domain)
  • Staging vs. production detection
  • Brand-specific content on shared installations
  • Language-specific domains

Query Parameter Context 

Match based on URL query parameters (GET parameters).

Configuration 

Parameter Name
type

string

required

true

The GET parameter name to check.

Expected Value
type

string

required

false

Value to match. Supports regular expressions. If empty, any non-empty value activates the context.

Store in Session
type

boolean

default

true

When enabled, the context state is stored in the user session, persisting across page navigations even after the parameter is removed from the URL.

Examples:

  • ?debug=1 with parameter debug and value 1
  • ?variant=a for A/B testing
  • ?affID=partner for affiliate tracking

Use Cases 

  • A/B testing variants
  • Debug mode activation
  • Campaign and affiliate tracking
  • Feature flags via URL

HTTP Header Context 

New in version 3.0.0

HTTP Header context for matching request headers.

Match based on HTTP request headers sent by the browser or proxy.

Configuration 

Header Name
type

string

required

true

The HTTP header name to check (case-insensitive).

Expected Value
type

string

required

false

Value(s) to match against the header. One value per line. Matching uses case-insensitive substring comparison: if any configured value appears anywhere in the actual header value, the context matches. If empty, any non-empty header value activates the context.

Store in Session
type

boolean

default

true

Has no effect for this context type. The header is evaluated on every request, so the context is active only on requests that carry a matching header.

New in version 4.0.0

PSR-7 header support and case-insensitive substring matching.

Header Name Resolution 

The extension supports both standard HTTP header names and $_SERVER parameter keys:

  • PSR-7 header names (recommended): User-Agent, Accept-Language, X-Forwarded-For
  • $_SERVER keys (legacy): HTTP_USER_AGENT, HTTP_ACCEPT_LANGUAGE

The lookup order is:

  1. PSR-7 $request->getHeaderLine() (standard header name)
  2. $request->getServerParams() ($_SERVER key format)

Value Matching 

Values are matched using case-insensitive substring comparison. For example, with header User-Agent and configured values:

Mobile
Android
iPhone
Copied!

A User-Agent string like Mozilla/5.0 (iPhone; CPU iPhone OS) matches because it contains iPhone (case-insensitive).

Examples:

  • X-Forwarded-For for proxy detection
  • Accept-Language for language preferences
  • User-Agent for browser/device detection
  • Custom headers from CDN or load balancer

Use Cases 

  • CDN or proxy detection (X-Forwarded-For, CF-Connecting-IP)
  • Mobile device detection via User-Agent
  • Accept-Language based content
  • Custom application headers
  • Bot detection; for AI crawlers use the AI crawler context

AI crawler context 

Matches requests whose User-Agent header names a known AI crawler or AI fetcher. Editors select the type and need no user-agent strings; the list of crawlers ships with the extension. Use the context like any other, for example to show or hide pages and content elements.

Configuration 

Additional user-agent substrings
type

string

required

false

Further substrings, one per line, for crawlers that are not on the built-in list. Matching is the same as for the HTTP header context: case-insensitive substring comparison against the User-Agent header.

Store in Session
type

boolean

default

true

Has no effect for this context type. The header is evaluated on every request.

Built-in user agents 

Each entry is the name its vendor documents for its crawler or fetcher. OpenAI and Perplexity publish the full user-agent strings; Anthropic publishes the bot names. Last checked against the sources on 2026-11-06.

User agent Vendor's stated purpose Source
GPTBot Crawls content that may be used to train OpenAI's foundation models OpenAI crawlers
OAI-SearchBot Indexes sites for ChatGPT search OpenAI crawlers
ChatGPT-User Visits a page for a user action in ChatGPT OpenAI crawlers
ClaudeBot Collects content that may be used to train Anthropic's models Anthropic crawlers
Claude-SearchBot Indexes content to improve search answers Anthropic crawlers
Claude-User Fetches a page when a user asks Claude a question Anthropic crawlers
PerplexityBot Surfaces and links websites in Perplexity search results Perplexity crawlers
Perplexity-User Visits a page when a user asks Perplexity a question Perplexity crawlers

Not on the list:

  • Google-Extended is a robots.txt product token only. Google states that it has no separate HTTP user-agent string, so it cannot be detected in a request.
  • anthropic-ai does not appear in Anthropic's documentation.
  • OAI-AdsBot checks the landing pages of ChatGPT ads; it does not read content for training, search or users.

Extending the list 

Integrators add user agents for all AI crawler contexts of an installation in config/system/additional.php or an extension's ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['contexts']['aiCrawlerUserAgents'][] = 'ExampleAiBot';
Copied!

Entries that are not non-empty strings are ignored. To add a user agent for one context only, use Additional user-agent substrings.

Session Context 

Match based on frontend user session data.

Configuration 

Session Key
type

string

required

true

Key in the session data to check.

Expected Value
type

string

required

false

Value to match. If empty, checks if the key exists and is not NULL.

Use Cases 

  • User state tracking
  • Shopping cart state (cart has items)
  • Login/authentication state
  • Multi-step form progress
  • User preference flags

Combination Context 

Combine multiple contexts with logical operators for complex rules.

Configuration 

Expression
type

string

required

true

Logical expression combining context aliases.

Operators:

  • && - logical AND (all must match)
  • || - logical OR (any must match)
  • ! - negation (must NOT match)
  • (...) - parentheses for grouping

Examples:

  • mobile && !tablet - Mobile but not tablet
  • internal || admin - Internal network or admin user
  • (german || austrian) && !guest - German-speaking non-guest
  • campaign_a && !already_converted - Campaign A visitors who haven't converted

Use Cases 

  • Complex multi-condition business rules
  • Nested context hierarchies
  • Exclusion rules (show to A but not if B)
  • Compound targeting (A AND B OR C)