Gemini Notebook Enterprise changes URLs: dates and access checks
Google is changing Gemini Notebook Enterprise web addresses. Its November 6 release notes warn that organizations filtering specific URL paths may need network-rule updates, despite automatic redirects.
The rollout has two stages
The added /go/ path is live for global and US locations, rolling out in the EU, and starts elsewhere November 9. From November 16, notebooklm.cloud.google.com becomes notebook.cloud.google.com for Google Identity. On the same date, Workforce Identity Federation moves to notebook.cloud.google instead of notebooklm.cloud.google.
Google recommends allowing both old and new hostnames. For Notebook inside Gemini Enterprise, the documented pattern is vertexaisearch.cloud.google.com/notebooklm/*. Organizations allowing only specific paths need both /REGION and /go/REGION. Consult the release note for the exact patterns relevant to your deployment.
Start with the enterprise entry point
The product overview describes an AI research and writing service that answers from sources added to a notebook. The enterprise interface is project-specific and distributed to users by an administrator. It can be purchased separately or accessed within Gemini Enterprise. Notebooks are accessible from both apps when the project and location match.
That distinction matters when collecting affected links. A browser bookmark, an internal help page and an application launcher can point to different entry routes. Build an inventory from the links people actually use, rather than assuming that everyone starts from the same home page.
Google separates administration from everyday notebook use. The Cloud NotebookLM Admin role handles identity configuration and access setup; the Cloud NotebookLM User role permits sign-in and notebook creation. The overview says that user role is required even for free trials. A successful redirect therefore should not be treated as evidence that every user has the necessary access.
Keep identity changes out of a URL repair
Google’s identity-provider guidance says existing Workforce Identity Federation customers can remain on that system. It also warns that switching providers changes user identifiers and makes existing Gemini Enterprise chat history unavailable. A web-address rollout is a poor reason to improvise an identity migration.
When someone reports a failure, first record where it occurs: reaching the website, completing sign-in, or opening a particular notebook. Those observations help the responsible administrator separate a network restriction from an identity or resource-permission problem. Avoid broad permission changes simply because the browser reaches a different address.
Test the routes people rely on
A useful check follows a normal user from the organization’s launcher or saved link into an existing notebook. Include each deployed location and sign-in route. Confirm that sources remain available to an authorized reader, and that a shared notebook opens under the intended work identity. Record the original link, resulting address and any error so support staff can reproduce the problem.
Refresh internal guidance after those checks, and route network changes through the organization’s usual approval process. Redirects reduce the burden on individual users, but an enterprise deployment still has bookmarks, identity settings and network rules maintained by different teams. Assigning an owner to the entry-point check makes this small change easier to manage.
Administrators reviewing other Google transitions should keep a separate calendar for Gemini Code Assist subscription deadlines. That article covers licensing and developer access; the notebook change here concerns how users reach their research workspace.
AI generated editorial illustration by ByteForward. Google and the Google logo are trademarks of Google LLC. ByteForward is not affiliated with or endorsed by Google.
