How can gated content appear in AI search? Decide what to share and how to configure Google

AI search optimization for gated content starts with deciding which text to share with search and which text to reserve for members. A public summary can serve as the entry point, or selected gated content can be made available to Google for indexing. Confidential information should remain protected by authentication.[1][2][4]

This guide is for website teams responsible for registration-only resources, research materials and subscription articles. It covers Google AI Overviews and AI Mode, based on official documentation checked on October 16, 2026. The publishing policy and review worksheets below are our proposed ways to coordinate decisions with the team maintaining the site.

Start AI search optimization for gated content with a publishing policy

Making every members-only article publicly accessible is unnecessary. First decide what content should be discoverable through search, then choose access and display settings that support that decision. Google provides guidance for marking registration-only and subscription content intended for indexing.[2]

“Crawling” means Google retrieving a page; making content eligible for indexing is a separate step from seeing it in an AI response. To qualify as a supporting link in Google's AI features, a page must be indexed and eligible to appear in Search with a snippet, the short description associated with a result.[1]

The first deliverable is a written policy for one resource. List what nonmembers, members and Google should receive. This makes it possible to agree whether the full article should be available to search or whether only a summary should provide an entry point.

Separate free registration and paid subscriptions from access permissions

Free registration still creates an access restriction when readers must register to read the article. Google's gated-content guidance applies to content intended for indexing that requires registration, as well as content behind a paid subscription.[2]

Record payment requirements separately from who can read the content. Treating free content as public, or paid content as automatically excluded from search, can obscure what the site actually delivers. Review the text available before registration, alongside the article name and URL.

For example, a proposed resource might offer a public summary and a detailed explanation after free registration. Put the summary in the public-access column and the explanation in the members-only column. This is a design example, not an account of a site we have tested.

The handoff sheet should identify whether registration and payment are required, what is visible before registration and what becomes available afterward. Where the answer is unclear, attach the relevant screen and identify the person responsible for resolving it. A pricing page alone does not establish the resource's access policy.

Separate information for search from information reserved for members

Select search-facing text from information its owner has approved for disclosure. Do not move members-only text or customer-specific information into public pages solely to improve discoverability. Google's guidance calls for protecting confidential content so that only authorized users can access it.[4]

Public summary, gated text and customer-specific information are useful working categories. A research resource may permit disclosure of its purpose while prohibiting details that identify respondents. Identify who can authorize disclosure for each part.

Start with one article and label its sections as public, members-only or unavailable for external disclosure. Extract only the candidate search-facing material and read it as a standalone explanation. Do not invent figures or examples to fill gaps where disclosure has not been approved.

Keep this inventory for implementation and subsequent reviews. When the policy changes, record which text was approved for broader access and who approved it. This reduces guesswork for the search team and preserves a clear comparison between the old and new decisions.

Distinguish Google's AI search features from other AI services

The settings discussed here concern AI Overviews and AI Mode in Google Search. AI Overviews summarize information in search results, while AI Mode supports exploration, follow-up questions and comparisons. Both can present links to relevant websites.[1]

Google applies its core search requirements to these features. It does not require special AI files or a dedicated structured-data type for inclusion. Meeting the requirements still does not guarantee crawling, indexing or display.[1]

These Google-specific controls do not establish how other AI providers handle members-only content. Label internal records “Google Search access” or “Google Search previews,” rather than “permission for all AI.” Separate controls for different services instead of combining them into one approval box.

A useful handoff note is: “This change concerns AI features in Google Search. Whether the gated article is provided for indexing follows the separate content-access policy.” Other services can be reviewed later using their own official guidance, without treating this review as evidence of their behavior.

Choose a public summary, indexable gated text or fully private content

Consider three approaches: make only a summary available to search, make selected gated text available for indexing, or keep the information fully private. These are our working categories, not Google product categories. Different articles on the same site can use different approaches.

Policy	Content provided to Google	Reader access
Use a public summary as the entry point	The approved public summary	Full text after registration or subscription
Include gated text in search	Text approved for indexing	Nonmember access designed separately
Keep content fully private	Do not provide the private text	Authorized users only

Choose according to what information may be shared with search. Determine whether a useful summary can be published, whether sharing the article itself is acceptable and whether it contains confidential information. Then check Google's gated-content requirements and the access protections needed for that choice.[2][4]

Publish a summary while keeping the gated text out of search

When registration must remain in place and only an entry point should be discoverable, publish an approved summary. If the gated article is not provided to Google, do not expect its unpublished details to supply search descriptions or AI answers. The intended search-facing resource is the summary.[1][4]

Explain the intended audience, the question addressed and what becomes available after registration. “Register to learn more” alone gives visitors little basis for deciding whether the material is relevant. Approved conclusions or a description of the contents can explain its value without publishing the full text.

Identify both the summary URL and the members-only URL in the implementation request. If one URL serves different views, specify the text delivered before registration and the text delivered to members. Describe the actual content, rather than relying on the number of URLs to explain the policy.

During review, check that a logged-out visitor can read the summary and follow the registration guidance. Confirm separately that the gated text remains unavailable and that the summary explains the resource's purpose. Discovery of the entry page and protection of the article are two distinct checks.

Consider making registration-only text available for indexing

If the article itself should be available to Google, design that access around Google's official guidance. Google describes both access for Googlebot and structured data identifying content that requires registration or a subscription.[2]

Googlebot retrieves pages for Google Search. Structured data is a machine-readable description of a page's content and properties. Adding a description of the restricted section does not, by itself, give Googlebot access through an authentication barrier.

Before choosing this approach, agree with the information owner that the selected text may be provided to search while ordinary readers must register. Define the scope article by article, excluding customer-specific information and confidential materials. This is not a reason to remove authentication across the site.

The request should specify the search-facing text, restricted section boundaries, nonmember and member views, and the content Google is expected to receive. After implementation, compare Google's retrieved content with that specification. Creating eligibility and observing an actual appearance in an AI response remain separate outcomes.

Protect confidential information with authentication

Customer-specific quotations and private business information need access controls that verify authorization. Google describes password protection as a way to restrict confidential content to authorized users. A search-exclusion instruction alone does not prevent someone with the URL from visiting it.[4]

Fully private information does not need to be prepared for inclusion in AI search. A separate general description may be appropriate if it can be published without exposing private details. Where no such description is permissible, creating a search-facing page need not become a goal.

Record authorized users, permitted uses and the person responsible for the information. A search review does not require copying customer names or actual quoted amounts into its working notes. A reason such as “contains customer-specific terms; not approved for external disclosure” may be sufficient for the decision.

When access must be narrowed, give the implementation team an exact description of that boundary. Check that unauthorized users do not receive the text, rather than waiting only for a search result to disappear. Preserve the original disclosure policy when considering possible search benefits.

Create a summary that helps visitors decide before registering

A public summary should explain its audience, what the resource answers and the conditions for reading more. The purpose is to support a decision before registration. Google also identifies useful content and important information in textual form as relevant foundations for AI search.[1]

The following approach applies those principles to a member site as an editorial proposal. Using only approved information, draft the resource name, question, publishable answer, contents available after registration and access conditions. If the reason for registration is unclear, resolve it with the site team before polishing the wording.

Read the summary beside the original resource. Check that it neither promises answers the resource lacks nor exposes restricted material. The public explanation and what members actually receive should agree before publication.

Describe the intended reader and the contents available after registration

Describe the situation in which someone would use the resource, rather than naming only a job title. Explain which decision it supports instead of promising vague “useful information.” Together, these details let visitors compare the resource with their needs before registering.

For a proposed comparison of working methods, a summary could name the task and the alternatives compared. Verify that the comparison actually exists, and avoid adding costs or outcomes it does not cover. A claim such as “everything needed for implementation” should not extend beyond the source material.

Extract publishable items from the resource's contents and answers. If a heading alone is unclear, add a short explanation of the decision it helps readers make. Send gaps back to the responsible person instead of filling them with generic claims.

During review, ask whether the audience, coverage and exclusions are clear without registration. For work on PDF text and tables, see the guide to PDF catalogs and AI search. The aim here is to explain enough for a registration decision, not to republish the entire resource.

Keep conclusions, conditions and update information together

Place the conditions for a conclusion close to the conclusion itself. Removing the applicable audience or scope while shortening a summary can turn a limited finding into a broader promise. Keep the answer and its conditions together within the approved public material.

A working draft can use four fields: answer, audience, exclusions and date checked. Dates should reflect the actual review or update of the information. Do not refresh only the date on an old resource or invent unpublished numbers to present it as current.

If access is limited to a particular membership tier, state that condition near the registration guidance too. Avoid a page that limits eligibility at the beginning but appears to promise access to everyone at the signup step. Read the explanation and the action text together to check that their scopes match.

Google recommends providing important information as text and keeping structured data consistent with visible content.[1] After revising a summary, check the page description and machine-readable information for outdated conditions as well. Record the wording changed, alongside the review date, so the change can be checked again.

Explain why registration is required and where it leads

Registration guidance should state what the visitor receives and where the next step leads. Creating a reading account, requesting a resource and contacting a representative produce different expectations. The action label should match its actual destination.

Confirm whether access is immediate, provided through a message or dependent on another step. Describe the verified process without inventing waiting times or free-access conditions. Explain the reason for registration only where the site team can substantiate it.

A concrete request is: “Make it clear where the visitor will read the resource after registration.” If existing members use a different login route, include that route in the review. Also check later whether signing in returns the reader to the original resource.

Improved guidance does not guarantee more registrations. Before publication, verify that the description matches the behavior; afterward, count visits and completed registrations separately. If registration does not increase, first check whether the promised resource is reachable before deciding what to change in the summary or form.

Use structured data when gated text is intended for search

Structured data tells Google that an article intended for indexing requires registration or a subscription. Google explains that this helps distinguish gated content from cloaking, a prohibited practice of presenting different content to search engines and users.[2]

Use this markup when the restricted text is intended to be crawled and indexed. It does not turn private material into public content or act as a special AI citation setting. Match the required description to the publishing policy already agreed.

Give the implementation team the page type, the beginning and end of each restricted section and any existing structured data. Check the actual section boundaries after the markup is added. Marking the summary and restricted article as one broad section would fail to identify accurately where registration is required.

Choose CreativeWork or a more specific type that fits the page

The markup supports CreativeWork, a broad category for creative works, and more specific types. Google's examples include Article, NewsArticle, Course and WebPage.[2]

An example using NewsArticle does not mean every member article should be classified as news. Select a type that describes what the page actually provides. This is a content classification, not a choice of a label expected to receive preferential treatment in search.

The handoff sheet can list the URL, current type and reason for the choice. Begin with a plain-language description such as “an explanatory article for members” or “a registration-only course description.” Compare that explanation with the supported types so the decision is based on the content, not just a technical name.

Where a page has multiple structured-data descriptions, identify which one contains the access information. Locate the existing description to update instead of adding conflicting statements. The introduction to structured data for SEO and AI search explains the underlying concepts.

Identify restricted sections with isAccessibleForFree and hasPart

Google lists isAccessibleForFree as a required property. Use false to identify content that requires registration or a subscription. The properties describing individual sections under hasPart are listed as recommended.[2]

Property	Value or meaning
Article's isAccessibleForFree	false: registration or subscription required
hasPart.@type	WebPageElement: a section within the page
hasPart.isAccessibleForFree	false: that section has restricted access
hasPart.cssSelector	The class identifying the restricted section

cssSelector identifies the relevant section within the page. Google's guidance permits only .class selectors and says not to nest restricted sections.[2] Give the implementation team both the selector and the first and last text it should encompass.

Do not choose the value solely on whether access costs money. For multiple restricted sections, compare each selector with the actual section it identifies. Check that the public summary is excluded from those boundaries, and record the markup change separately from the successful boundary review.

Compare Googlebot access with the restrictions for ordinary readers

Check Googlebot's ability to retrieve content separately from the markup describing it. Google requires access to the page when its content, including gated sections, is intended for crawling and indexing. Googlebot-News may also be relevant where applicable.[2]

The implementation team should explain what a nonmember, a member and Google each receive. Compare this behavior with the publishing policy. If Google should receive the restricted article but receives only a login prompt, the presence of markup alone does not solve the problem.

Conversely, if the policy is summary-only but Google receives the full text, review delivery before treating discoverability as a success. Technical accessibility and permission from the information owner are separate requirements. Both must agree with the intended behavior.

Use URL Inspection, discussed below, to examine retrieved content; Google's gated-content guidance points to this tool for crawling and rendering checks.[2] Authentication and delivery differ between sites, so obtain evidence for the specific URL rather than treating an unverified CMS setting as a universal implementation recipe.

Choose AI search preview controls to match the publishing policy

Select a control according to whether the restriction should cover the whole page, a particular passage or the length of a text preview. A snippet is the short text description shown with a search result. Google explains that search preview controls also apply to AI Overviews and AI Mode.[2][3]

Intended restriction	Control to consider
Prevent text previews for the page	nosnippet
Exclude particular passages	data-nosnippet
Limit the length of text previews	max-snippet

Check the approved search-facing text before selecting a control. Eligibility for supporting links in Google's AI features requires snippet eligibility, so consider a broad preview restriction alongside the intended search appearance.[1] Authentication protecting confidential information must remain a separate part of the design.

Use nosnippet to restrict previews for the entire page

nosnippet instructs Google not to show a text snippet or video preview for the page. Google also says it prevents the content from being used as direct input for AI Overviews and AI Mode. A static image thumbnail may still appear.[3]

Confirm that the instruction covers the page as a whole, rather than only its restricted section. Applying it to a public summary intended as an AI search entry point can conflict with the desired eligibility. Decide how the information should appear before choosing the affected URLs.

The implementation request should identify the URL receiving nosnippet and state whether the summary URL is included. The instruction can be placed in the page's HTML or in an HTTP response header returned by the server. Ask the team to record where it was configured.[3]

A setting visible in the administration screen is not enough to complete the review. Confirm that the response Google receives contains the instruction, then monitor its processing. This controls search presentation; it does not stop the article being delivered to someone who opens the URL.

Use data-nosnippet to identify particular passages

data-nosnippet is an attribute that excludes specified page text from snippets. An attribute adds an instruction to an element in the page's markup. Google supports this attribute on span, div and section elements.[3]

Give the implementation team the exact beginning and end of the passage to exclude. If the public summary should remain eligible while another passage is excluded, compare that boundary with the implemented one. Applying the attribute to a broad container can also exclude text intended to remain available.

The attribute takes effect through its presence: writing data-nosnippet="false" does not disable it.[3] When removing the restriction, confirm that the attribute itself has been removed rather than only changing its value. Incorrectly closed markup can also affect the intended boundary.

This enforces a search-preview preference, not permission to read confidential information. Authentication and content delivery determine whether readers receive the text. Structured data has separate treatment, so marking visible text alone does not establish that every form of information provided to Google has been restricted.[3]

Check max-snippet limits and separately supplied information

max-snippet sets a maximum character count for a text snippet. Google says it also limits how much content may be used as direct input for AI Overviews and AI Mode. It does not set the length of the AI-generated answer as a whole.[3]

A value of 0 prevents a snippet and is equivalent to nosnippet. A value of -1 sets no character limit, allowing Google to choose the length it considers appropriate. For other limits, choose according to the publishing policy and display objective rather than presenting a particular number as universally recommended.[3]

There are exceptions for content provided under separate permissions. Google explains that this limit does not prevent uses of information supplied through on-page structured data or covered by other permissions. Structured-data descriptions have additional treatment, so review both the article text and machine-readable information.[3]

Record the URL, chosen limit, configuration location and information supplied in structured data. Do not infer that a shorter snippet makes private information secure. If information that should not be shared is present in the markup, the content-delivery design needs correction before adjusting a character limit.

Keep content protection separate from search settings

Review three different questions: whether the text is delivered, whether it is displayed and what instructions are sent to search. Text missing from the visible screen may still have reached the browser. Google advises choosing an implementation that does not supply gated text to the browser when it should not be available there.[2]

Area to check	Question for the implementation team
Authentication and delivery	Is the text returned to an unauthorized visitor?
Screen presentation	Is delivered text merely hidden from view?
Search settings	What instructions govern crawling, indexing and previews?

Keep findings for the public summary separate from findings for the restricted content. A CMS is the system used to manage articles and pages. Check the actual response and instructions for the target URL instead of relying on a setting's name in the CMS.

Distinguish hiding text from withholding its delivery

A logged-out page can conceal the article while still delivering its text as page data. Restricting what is visible differs from withholding the data itself. Google's guidance says that an implementation should meet the requirement not to supply content to the browser where that is the intended restriction.[2]

Ask the implementation team: “Is the restricted text itself sent to the browser when the visitor is logged out?” If the answer describes only how the text is hidden on screen, request confirmation of the delivered data too. The scope of delivery can be checked without first mastering every implementation technique.

Have an authorized site maintainer perform the review using approved test environments and accounts. Do not remove authentication and make the material public merely to test it. Alongside screen captures, ask the maintainer to confirm whether the nonmember response matches the publishing policy.

If a summary-only design also delivers the full article, resolve that discrepancy before proceeding with publication. If the policy intentionally provides gated text to Google, verify those conditions separately. Compare intended and actual behavior rather than inferring the entire delivery model from a single screenshot.

Do not substitute noindex or robots.txt for authentication

noindex instructs search engines not to include a page in search results, while robots.txt tells crawlers which URLs they may retrieve. Neither verifies membership or grants reading permission. Google explains that people can still visit noindexed content through a link or a direct URL.[3][4]

Google must be able to retrieve a page to read instructions placed in it. Blocking crawling through robots.txt prevents Google from seeing a noindex instruction on the blocked page.[3] Describe the intended restriction to the implementation team instead of assuming that combining both controls provides stronger protection.

For confidential text, first confirm that unauthorized visitors do not receive it. For a page that may be publicly read but should stay out of search, consider indexing instructions. This order avoids treating absence from search as evidence that access is protected.

Use separate fields for authentication requirements and indexing policy in the review sheet. If a public page intended for search is missing, continue with the AI search visibility checklist. Keep protection of restricted information separate from troubleshooting a public page.

Check which settings apply to public and members-only URLs

After changing a shared template, inspect both the public summary and the members-only URL. An unintended search restriction on the public page and unintended text delivery on the restricted page are different faults. A successful check on one does not establish the behavior of the other.

Label the review list with categories such as public summary, member article and customer-specific information. If one URL serves different views, create separate rows for logged-out and member states. The list should show which browsing state each test needs to reproduce.

Ask the implementation team to inspect HTTP response headers as well as HTML. Google processes instructions from both places and applies the more restrictive rule when directives conflict.[3] Removing a single CMS setting does not establish that every restriction has been removed.

Record intended settings separately from observed results. Include the URL, browsing state, text returned, search instructions, date and reviewer; leave untested rows explicitly unverified. Keeping a record of the expected working state makes it possible to repeat the same checks after a CMS update.

Verify the publishing policy from three perspectives

After implementation, separately inspect what ordinary visitors, members and Google receive. The nonmember screen cannot establish whether members can read the full article or what Google retrieved. Google's gated-content guidance recommends both structured-data testing and URL Inspection.[2]

Perspective	What to compare	What to record
Nonmember	Public summary and registration guidance	Visible content and destination
Member	Authorized restricted text	Available content and arrival page
Google's retrieved response	Intended search-facing text and settings	Retrieved content and test time

This table is a proposed review worksheet, not a set of completed test results. Select the URL and browsing state, then enter actual observations. A successful Google test does not validate membership permissions or guarantee an appearance in AI search, so retain separate evidence for each check.[5]

Compare the page and registration route when logged out and signed in

Open the same resource while logged out and while signed in as an authorized member. Compare the summary, registration guidance and destination after registration or login with the publishing policy. Use a site under the team's control and accounts approved for testing.

First check that the logged-out page shows only text approved for public access. Then read the registration or login guidance against what the reader will receive. If an action labeled “Read the resource” leads to an unrelated service overview, revise the description or destination.

In the member view, verify that the target article is reachable and that its available content matches the membership tier. Use an operator-approved method where testing would involve payments or external submissions. Opening a screen does not prove that an unperformed registration or payment succeeded.

Finally, compare text wrapping and controls on desktop and mobile. Check that long headings do not obscure the guidance, registration links remain readable and restricted text does not appear unexpectedly. Record device, browsing state and time, and distinguish this visual review from verification of the delivered data.

Test the markup and compare it with the restricted sections

Use Google's Rich Results Test to inspect the structured data. It checks markup related to enhanced search appearances, and Google's gated-content guide recommends using it. Resolve critical errors reported by the test.[2]

Test URLs whose content has been approved for Google access. Run the URL test and send the detected items and error explanations to the implementation team. Do not make a confidential authenticated page public for the tool or copy its private text into an input field.

Separately, have a person compare the restricted sections with their selectors. Check where the class named in cssSelector occurs and whether it incorrectly includes the public summary. Correct markup syntax alone does not establish compliance with the organization's disclosure policy.[2]

Save the URL, date, detected items, corrections and boundary-review result together. If an expected item is not detected, review the tested content and type rather than immediately concluding that access protection has failed. The structured-data testing guide covers the basic testing workflow.

Use URL Inspection to check retrieved content and index status

Open URL Inspection in Search Console with permission to view the relevant property. Enter the complete URL belonging to that property in the inspection field at the top. The first result describes Google's stored index information; distinguish it from a fresh retrieval of the current page.[5]

To examine the current page, run “Test live URL.” Use “View crawled page” for the stored crawl or “View tested page” for the live test to inspect the returned HTML and available details.[5] If a view is unavailable, record what could be checked and any retrieval errors instead of treating the content as verified.

Compare the retrieved text with the publishing policy. For a summary-only policy, check that restricted text is absent; when gated text should be indexable, check that Google received more than a login prompt. Confirm the intended preview instructions with the implementation team too.

If the response differs from the policy, include the tested URL, time and intended audience in the correction request. An indexability result does not guarantee inclusion in an AI answer.[5] Use the test to review settings, and record actual search appearances as a separate observation.

Review search appearances and registrations separately

After configuration, record AI search appearances, site visits and completed registrations separately. An increase at one stage does not establish improvement at the others. Google recommends combining search information with analytics that measure outcomes on the site.[1]

Stage	Record
AI search appearance	Query, observation date and cited URL
Visit	How visits to the target page are counted
Completed registration	The condition counted as completion
Continued access-policy compliance	Content received by nonmembers, members and Google

These are proposed operational records, not evidence that a particular setting increases registrations. Mark stages that cannot be observed as unmeasured. Continue checking the access boundaries alongside the outcome measurements.

Record change dates, URLs and the definition of a completed registration

Before comparing outcomes, record the URL, change, change time and comparison periods. Define a registration-button click, a form view and a completed registration as distinct events. This prevents different actions from being combined under the same “registrations” label.

Ask the analytics owner to describe in words what counts as completion. Clarify the treatment of an interrupted form, a validation error and an existing member signing in again. The improvement record needs counting rules, not personal names or submitted form contents.

A change log can use one row per URL, with descriptions such as “clarified the summary's coverage,” “corrected the post-registration destination” or “changed the restricted section's preview instruction.” Record simultaneous changes together. Do not attribute the result to one setting when several things changed at once.

For a registration rate, define the denominator as well as the completed-registration count. Visits to the resource and entries to the registration form produce different measures. Use the same definition across comparison periods, and treat periods with changed measurement methods separately.

Track preview changes through retrieved content and review dates

If search presentation does not change after a settings update, first check whether Google can see the instruction. Google's guidance recommends inspecting the crawled HTML and allowing time for recrawling and processing. A recrawl can be requested where appropriate.[1]

Keep the configuration date, live-test date, stored crawl time and search-observation date separate. Comparing an older crawl with a current screen as if they represented the same moment makes it harder to distinguish an inaccessible instruction from a change awaiting processing.

If the live test does not show the instruction, return to the configuration location and target URL with the implementation team. If it does, continue checking crawl records and search presentation. Separating stored index information from a test of the current page helps determine whether another correction is needed.[5]

Request recrawling only for material approved for search. Do not make fully private information public merely to inspect it. Avoid promising immediate changes or disappearance within a fixed number of days; use dated observations to decide what to investigate next.

Recheck the same URLs after CMS or access-policy changes

Treat CMS updates, membership changes and changes to content access as reasons to repeat the review. Inspecting previously working URLs in the same browsing states makes intended and unintended differences easier to compare. Update the original publishing-policy record instead of rebuilding the review from memory each time.

Begin with a policy sheet for one article. Include the URL, relevant text, nonmember access, member access, content supplied to Google, settings, observed results and responsible person. If the sheet becomes too wide, list the same fields vertically for each URL.

An implementation request can say: “Provide only the specified text to search, display the agreed scope to nonmembers and members, and return the three retrieval or display results after the change.” Leave empty test results marked incomplete, with an owner and a next review point. Save the completed sheet with the article's internal management record.

AI search optimization for gated content can begin by comparing this agreed policy with actual behavior. Prepare the public explanation, decide how the restricted text will be treated, and check authentication, search instructions and the reader's route. Keep the original access boundaries as the basis for decisions while monitoring appearances and registrations.