StoreBuilt reviewed Shopify’s password-page, preferences and theme-template guidance for this launch checklist. Our implementation position is that publishing the right design and opening the right storefront are separate decisions. A successful preview establishes neither public access nor a complete purchase journey.
When a Shopify password page is still showing, resist changing unrelated settings in a hurry. A UK brand preparing email, paid media or a product launch needs a short, evidence-led sequence that distinguishes the access gate, public domain and published theme. The examples here are illustrative launch scenarios, not claims about client incidents.
Contact StoreBuilt to review a launch blocker and the public checks required before campaign traffic starts.
Table of contents
- Start with the exact public address
- Identify the gate before removing it
- Confirm eligibility and store access settings
- Separate theme publication from store access
- Check domain and campaign destinations
- Define the public launch acceptance gate
- Walk through a preview-link launch mistake
- Review crawlability after access is open
- Keep a short launch evidence sheet
- StoreBuilt point of view
Start with the exact public address
Copy the address a customer will actually receive. Check the campaign link, navigation link and primary storefront domain separately. A theme preview URL is useful for review, but it is not the same evidence as a public-domain visit from a fresh session.
Open that address in a browser profile or guest session that has not already entered the store password. Record the screen shown and the final URL after redirects. If a colleague sees something different, compare the session and address before assuming an intermittent platform problem.
Keep the initial report precise: “the campaign product URL redirects to the store password page for a guest” is actionable. “The website is not live” could instead describe a DNS error, a missing product, an old theme or an account login screen.
Identify the gate before removing it
The native storefront password page, customer-account login and a wholesale-access application can all ask for credentials. They do not have the same purpose or configuration. A branded login screen alone is insufficient to identify which system is responsible.
Shopify’s password-page guidance explains the storefront access mechanism. Compare the observed page with the actual store configuration. If an application controls a restricted catalogue, involve its owner rather than switching off unrelated storefront protection.
| Observed screen | Likely area to investigate | Evidence to confirm |
|---|---|---|
| Storewide password landing page | storefront access settings | guest URL and current setting |
| Customer account login | account journey | destination and account context |
| Wholesale approval screen | B2B or access application | provider and intended audience |
| Browser domain error | domain connection | exact error and DNS ownership |
| Correct store, wrong design | theme publication | published theme versus preview |
This distinction protects intended access rules. The objective is to open the agreed public experience, not to remove every barrier that happens to appear during testing.
Confirm eligibility and store access settings
Check the current admin requirements for the store type and plan. Shopify’s guidance states that a pricing plan must be chosen to remove password protection during a free trial. Development-store rules can differ, so do not apply a normal merchant-store checklist without checking the context.
Review the Store access area described in Shopify’s online-store preferences documentation. Confirm the intended setting and save it through the supported admin flow. Record who made the change and when, especially if several people are coordinating launch tasks.
Avoid inferring success from the editor closing or a teammate saying the switch was changed. Repeat the public guest test after the saved change. If the page still appears, capture the exact final address and current setting before taking another action.
Separate theme publication from store access
A password landing page can have its own design, and a theme preview can show work that is not yet published. Verify that the intended theme is live independently of the storefront access decision. Otherwise the store may open successfully with an older design.
Shopify’s password-template documentation is relevant when customising that template. It does not make a theme preview equivalent to a public launch. Keep the developer’s template work and the merchant’s access decision clearly documented.
Use a recognisable, non-sensitive visual detail to distinguish the intended version during QA. Then check a product and a collection, not only the homepage. Different templates or assignments can expose unfinished layouts even when the landing page looks correct.
Check domain and campaign destinations
A custom domain problem is not solved by removing a password. Record whether the browser reaches Shopify, receives a certificate error, redirects unexpectedly or lands on another hostname. Give domain administration to the person who controls the actual configuration.
Verify that campaign links use the intended public URLs. Remove preview-specific parameters from final marketing links where they are not part of the published route. Check the complete journey from the actual email or advertisement destination rather than manually typing a cleaner homepage address.
For existing stores being reworked, preserve the established URL structure unless there is an intentional migration plan. Our Shopify migration service covers the wider redirect and launch sequence when a domain or platform move is involved.
Define the public launch acceptance gate
Public access is necessary but insufficient. Agree the small set of checks that must pass before increasing traffic: homepage, important collections, representative products, navigation, cart and the agreed checkout test. Include delivery information, contact access and key policy links.
Use controlled test methods appropriate to the store rather than creating accidental real orders. The person responsible for payments should confirm the intended production configuration. Do not equate a product entering the cart with successful payment readiness.
If a critical step fails, keep the campaign release on hold while the team fixes that specific issue. This is a project decision based on evidence, not a reason to leave a public storefront in an uncertain state without an owner.
Walk through a preview-link launch mistake
Imagine an illustrative homeware brand whose team approves a new theme using a preview link. The marketing draft includes that same link, while the normal public domain still shows the password page. Internal reviewers believe the store is ready because their sessions consistently show the design.
The corrective sequence checks the intended published theme, verifies storefront eligibility and access, and replaces the campaign destination with the public product URL. A fresh guest test then follows the actual marketing route into the store and through the agreed purchase checks.
The acceptance result is a reproducible public journey. It does not prove search indexing or campaign performance. Keeping those outcomes separate makes the launch report more useful and prevents a design approval from being mistaken for operational readiness.
Review crawlability after access is open
Search engines need access to useful public pages, but removing a password does not guarantee indexing. Check important URLs for an appropriate response, intended canonical and absence of accidental noindex directives. Confirm that navigation and the sitemap expose the pages you want discovered.
Google’s technical requirements for Search distinguish accessibility, successful responses and indexable content. Treat those as foundations rather than a promise of inclusion. Search Console inspection is a separate follow-up after the live page is available.
For a fuller technical review, use our Shopify SEO checklist. Do not repeatedly change URLs or page titles on launch day merely because a new page has not immediately appeared in search results.
Keep a short launch evidence sheet
Assign an owner and timestamp to each important check. A small shared record is easier to act on than a large checklist where every item is marked complete without evidence. Include the real URL and the session used for the test.
| Check | Passing evidence | Responsible role |
|---|---|---|
| Guest access | public domain opens without old access | launch owner |
| Published theme | approved version on key templates | implementation team |
| Marketing route | final campaign link reaches intended page | marketing owner |
| Purchase path | agreed controlled test passes | commerce owner |
| Discovery | important pages linked and in sitemap | SEO owner |
Repeat the guest check immediately before traffic starts if access settings have changed during preparation. Keep the original issue description and final evidence together so the team can explain what actually blocked launch.
StoreBuilt point of view
A launch is ready when a new visitor can complete the intended journey on the real address. We would trust that evidence over any screenshot from an authenticated preview. Separating access, design, purchase readiness and indexing keeps the decision clear.
Bring the public URL, the screen a guest sees and the intended launch time. Contact StoreBuilt for a focused readiness review that identifies the blocker and verifies the resulting customer experience.
If the launch address shows a browser security warning, use the Shopify SSL pending diagnostic guide before changing the theme.