Locking a public API behind an SSR site: return 401, deploy site first

When an SSR site's data API goes from public to server-to-server with a shared header token, three things bite. Return 401 rather than hiding the route with 404: page code usually maps a 404 to 'not found', so a bad token would serve real 404s that search engines read as removed content, while 401 throws to an error page. Fail closed when the token is unset, and roll out in order: create the secret, deploy the site sending the header (the API ignores it), then deploy the enforcing API; reversing that takes the pages down. Check the CDN too: an endpoint sending Cache-Control: public could leak locked responses if caching is ever enabled, and an origin request policy that doesn't forward custom headers would strip the token, so confirm it forwards all viewer headers. Deploy scripts that only set Lambda env vars on create need an explicit update-function-configuration step on update.