SERA integration on other web-servers

If you are using a web-server for which SERA integration steps are not provided here, just follow the steps below.
Sending requests to SERA is simple: all you need is a SERA token and a simple proxy configuration.

Prerequisites#

All your page requests must get intercepted by below SERA routing rule
- Please check your routing, caching and cache-variation policies for that
If caching is enabled, Users and Bots should have a separate cache-variations configured. This is to not serve the SERA’s bot-optimized-content to users.

Steps#

1. Identify Matching Requests#

1.1 Request-Method#

Only the GET requests should be sent to SERA.

1.2 User-Agent Pattern#

Requests matching only the mentioned bot user-agents should be sent to SERA.
You can define a regular expression or other matching criteria to identify requests that should be proxied to SERA.

DURING POC PHASE use this User-Agent regex to match crawlers:

/(n7TestUserAgent|google\ page\ speed|chrome-lighthouse|google-inspectiontool|PTST|GTmetrix|n7ua)/

ON GOING LIVE ON SERA use this User-Agent regex to match crawlers:

/(n7TestUserAgent|google\ page\ speed|chrome-lighthouse|google-inspectiontool|PTST|GTmetrix|n7ua|googlebot|facebookexternalhit|bingbot)/

ON GOING LIVE ON SERA for AI bots use this User-Agent regex to match crawlers:

/(openai|gptbot|claudebot|claude-user|perplexity-user|perplexity-bot|google-extended|google-cloudvertexbot|google-notebooklm|amazonbot|duckassistbot|metaai|metabotic|meta-externalagent|copilot|baiduspider)/

1.3 File Extension Pattern#

Only the page request patterns should be sent to SERA.

You can either include only the page requests using a pattern like:
```
~*.*(|.html|aspx|php)($|\?.*)
```

Or else, exclude all non-HTML requests using a pattern like:

~*\.(ai|ashx|asmx|aspx|avi|avif|bmp|css|csv|dat|dmg|doc|eot|exe|flv|gif|ico|iso|jpeg|jpg|js|json|jsp|less|m4a|m4v|mov|mp3|mp4|mpeg|mpg|ogg|otf|pdf|php|png|ppt|psd|rar|rss|svg|swf|tif|torrent|tf|txt|wav|webm|webp|wmv|woff|woff2|xls|xml|zip)($|\?.*|&.*)

Keep updating this pattern for any new non-page types.

1.4 Page Exclusion Pattern#

Some page requests should never be sent to SERA, e.g., login or checkout flow.
You can exclude them using a pattern like:
```
~*.*(/static/|/_next/|/api/|/login|/logout|/account/|/wishlist/|/cart/|/checkout/|/payment/).*
```
Keep updating this pattern for any API/sitemap-excluded requests.

1.5 GMC Query Parameter Pattern#

1.5.1 GMC Query Parameter Usage#

GMC requests should always be served with fresh content, else Google flags them with content-mismatch.
So, make sure all the product URLs in your GMC feed file have nsbp query parameter.
Above condition should route these requests to origin to serve latest content to Google.

1.5.2 GMC Query Parameter Exclusion Pattern#

Use a regex like below to bypass SERA for requests containing nsbp query parameter, and route them to your origin.:
```
~*.*\?(.*&)*nsbp=.*
```

1.6 SERA Internal Request Headers#

Exclude the requests with these 2 request headers:
```
x-nv-app
```
```
x-nv-sera-bypass
```
x-nv-app and x-nv-sera-bypass headers mentioned in logic are added on request when SERA connects to your server to fetch page content for optimizing and caching, and also when it bypasses the requests to origin on failover scenario.
These requests are bypassed to your server.

2. Configure Proxy#

Use a proxy server or module that supports conditional forwarding based on request headers.
Examples include: Nginx (for reference, not implementation-specific), Apache HTTPd with mod_proxy.

2.1 Proxy Target#

Set the proxy target to the SERA server endpoint shared with you
For example, the page:
https://www.example.com/app/1v1/home.html
should be proxied to SERA like:
https://SERA_ENDPOINT/app/1v1/home.html
(with request headers : x-nv-sera-token: <token> and x-nv-access-key: <n7-access-key>)

2.2 SERA Token Addition#

Add a request header to the above forwarded request with the SERA token as:

x-nv-sera-token: <your-token>
x-nv-access-key: <n7-access-key>

2.3 Forwarding Conditions#

Implement logic to forward requests based on:

Matching user-agent pattern
URL pattern to pass only required page requests to SERA
Remove query string from URL - IF YOUR SITEMAP PAGE URLS DO NOT HAVE QUERYSTRING

3. Handle Responses#

3.1 Proxy Response#

Forward the response from SERA back to the crawlers.

Keep refining the logic by adjusting the user-agent list and SERA exclusion patterns as needed.
Test thoroughly:
- WPT and GTMetrix will automatically receive the response from SERA due to the routing rule set above.
  - Steps to validate page using WPT
- To check the SERA rendered page on a browser, you can use DevTools > Network conditions facility , or a browser extension (like Simple modify headers ) to manipulate the browser user-agent.
  If in testing phase, use these user-agent values:
  For desktop:
```
n7TestUserAgent
```
For mobile:
```
n7TestUserAgent; Android
```
If SERA is live, you can use these actual bot user-agent values:
For desktop:
```
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +<http://www.google.com/bot.html)> Chrome/W.X.Y.Z Safari/537.36
```
For mobile:
```
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +<http://www.google.com/bot.html)>
```
On go-live day, set the user-agent condition regex to actual bot user-agent values. Additionally, ensure that your condition is case-insensitive.
Whitelist SERA requests at your origin to avoid any issues with indexing. Details are here
After go-live, in any dashboards created for monitoring the “actual user traffic” (e.g., Google Analytics), exclude the requests with user-agent string containing the word “Nitrogen SERA” to get a correct understanding about user traffic.

Notes#

Go through the different scenarios mentioned here
Also Refer the Frequently Asked Questions about SERA here