Troubleshooting a Site Won't Open Under Site Lock or an Allow-Only Access Plan

Use this guide when Site Lock or the use of an Allow-Only Access Plan results in a block page for the student, rather than successful access of the desired site.

How Blocking Works

Site Lock and Allow-Only Access Plans only check the browser's address bar. Everything a page loads in the background (images, fonts, scripts, embedded widgets, CDNs, ads) is ignored. When a site fails to work during Site Lock or with an Allow-Only plan, it might be because additional domains need to be allowed too.

When additional domains need to be added: they are needed when the address bar itself changes to another domain. This could be due to a login redirect or an app that jumps to different domains completely (not just sub-domains of the original).

Example: readingapp.com redirects to auth.vendorsite.com to sign in. In this case auth.vendorsite.com is the additional domain that needs to be allowed.

Common Identity Providers (IDPs): Google, Microsoft, Clever, and ClassLink are already on Securly's system-wide allow list, so they never need to be added to an allow list or web link dependency.

Subdomains: Web links (when used with "allow entire site") and allow-only URLs that do not include a subdomain (i.e. edusite.com, not content.edusite.com) will automatically have all subdomains allowed, so there’s no need to add them.

Site Lock vs. Allow-Only Access Plans: Site Lock (with "allow entire sites") evaluates and blocks the same as an allow-only plan. If a site fails under one, it fails under the other. Test using either one.

Entire domain allowed: Site Lock (with "allow entire site") and Allow-Only URLs tell the browser to allow the entire domain.  That is, adding site.com/page/assignments to the list will allow everything on site.com. 

Used Classroom before 2023? Site Lock used to check every resource a page loaded, so long CDN/font/script lists were required. That's no longer true; most legacy dependency entries can be removed.

How to Fix a Site Lock or Allow-Only Plan Failure

1. Confirm the site works with no blocking plan. Push it to a student or open it directly, all the way through sign-in and into the site.

2. Reproduce the failure under Site Lock or the Allow-Only Access Plan (same site, student, device).

3. Check the student’s history to find the blocked site: Users > Students, or Class Session History > Student > Sites Accessed. Look for the blocked entry right after the failed attempt.

4. Note the site that was blocked and add it to one of three places to allow it: Organization Allow List, Web Link Dependency, Allow-Only Plan (see next section for details).

5. Test again. Sites can redirect more than once. The process stops after the first block, so repeat until nothing is blocked.

Where to Allow the Domain

There are three places a domain can be allowed. Stop at the first option that fits:

1. Organization Allow List: use for domains safe for students to access at any time. This is the best choice for domains that should always be open, since one entry here covers every web link and access plan any user creates going forward.

2. Web Link Dependency List: Additional sites here are called dependencies. Each Web Link has its own dependency list. Web links can be reused across multiple Access Plans, which is why it’s the better long-term choice over adding a site to a single plan.

3. Directly in an Allow-Only Access Plan: This is the last choice because adding the additional needed sites here has to be repeated every time the original site is needed in a different plan.

Not Something You Need to Allow

• Embedded content (iframes, embedded video): never evaluated by Site Lock/Allow-Only. A Securly Filter setting, not Classroom.

• Content embedded in Google Docs: same as above. Links out are still enforced, except Google Classroom coursework.

• A page that loads oddly but isn't blocked: not caused by Site Lock or an Access Plan. Contact support.