13 parts · 11 checkpoints · Take away: 4 records · 1 note
Show all 13 parts
- 01Give the shopper a clear next step
- 02Prepare information the store can stand behind
- 03Assign each page a buyer job
- 04Choose a structure for the buyer’s task, has a checkpoint, has a work product
- 05Follow one market view to pre-checkout
- 06Write four usable storefront handoffs, has a checkpoint, has a work product
- 07Trace the storefront problem to its admin source
- 08Compare plans against the work you have
- 09Review the address, promises and help path
- 10Make edits traceable to an owner and rollback source
- 11Review pages, domain, access and mobile together
- 12Repair the point where the shopper gets stuck
- 13Check the mobile path against your own evidence, has a checkpoint, has a work product
Give the shopper a clear next step
The homepage, collection and product page hand the shopper from one decision to the next. Store structure helps someone find a suitable product, understand price, delivery, returns and support, then add it to cart, edit it and reach checkout. Decide what each page helps the shopper do and where it leads before deciding how many pages to build.
Our example is a 20oz insulated tumbler for US office commuters. Follow a mobile ad entry through the homepage, Office Commute / Travel Tumblers collection, product page, policies and cart to pre-checkout. Capacity, cup-holder fit, leak resistance, insulation time, material and cleaning limits need product evidence. The US, USD and English define the classroom scope; they do not establish your entity, payment eligibility, stock location or fulfillment capacity.
You can enter with your own hero product, target market, page drafts and responsible person. If you have an admin setup record, bring account recovery, market display, controlled payment tests, notification/support receipt and event evidence. Those cover their own admin steps; finding a product, reading policies and using a mobile menu still need separate checks. This lesson makes no store, order, payment, notification or DNS changes. Any later controlled test needs its own authorization.
Continues from
Connect the decision to the admin work
This lesson leaves a store path launch map: page jobs, entries, evidence and ownership. For field-by-field work, use Theme backup and customization and Pages, menus and navigation. Full product listing, payment tests and public-launch quality assurance (QA) have their own lessons.
Prepare information the store can stand behind
A CTA is a button or link that asks the shopper to take the next step. A SKU identifies a particular stock item; use the same SKU throughout a review so results before and after a change are comparable.
Write down a stable store name and brand direction, a maintainable support inbox and Contact page, first market, featured collection and SKU, policy drafts, domain plan and owner. Address, time zone, units, language, currency, customer accounts, notification routing and baseline events also affect the storefront. Reconcile these inputs with public promises before arranging pages.
Here, 2FA means two-factor authentication: sign-in requires another factor beyond the password. This table records its status; account setup remains an Admin task.
What to locate before page work
Identity and help
- Input
- A stable name, public support route and response expectation consistent with merchant identity.
- Minimum reviewable evidence
- Contact URL, receiving owner and the location of an authorized test result.
First market and product
- Input
- Target country/region, display language/currency, collection, hero SKU and supportable delivery/return promises.
- Minimum reviewable evidence
- Entry-to-SKU path and price, stock and market-availability record.
Policy drafts
- Input
- Shipping, Returns, Privacy, Terms and Contact contain actual business information.
- Minimum reviewable evidence
- Page URLs, versions, owners and comparison with product promises.
Domain plan
- Input
- Choose temporary myshopify.com use or a brand-domain plan, and locate primary-domain/TLS checks.
- Minimum reviewable evidence
- Chosen address, redirect direction and Settings > Domains status.
Access and changes
- Input
- Separate owner, staff and collaborator tasks; assign sign-in protection and recovery ownership.
- Minimum reviewable evidence
- Permission table, 2FA status, change log and usable rollback source.
These inputs cover identity, domain/security, page structure and operational preparation. Keep gaps in notifications, shipping, time zone or tracking in the admin or launch-QA record. Bring their effect on the buyer path into this map without repeating the entire admin setup.
Set the path before polishing it
Define the first purchase path
Name the ad or homepage entry, featured collection and SKU, then cart and pre-checkout. Keep store identity and first-market scope consistent.
You should see
Keep the entry URL, target SKU and buyer task.Make public promises findable
Make price, delivery, returns, Contact, response expectations and policies reachable, with wording that matches actual capacity.
How to confirm
The purchase area and policies agree; a named person owns incoming support.Review the core handoffs
Check menus, collections, product pages, policies and cart. Start where the shopper lands and record each next click and the surface to repair if it fails.
Keep as evidence
Same market and product, mobile screenshots and review date.Polish after the path works
Schedule effects, apps and deeper customization after the path has evidence. Keep affected campaigns and traffic paused while the earliest break remains.
If it goes wrong
After repair, repeat the original entry and product on the same kind of device and record the result.
Assign each page a buyer job
A collection groups products around a use or comparison task and helps the shopper choose what to open. A product detail page (PDP) explains one product and variants such as color or capacity, resolving purchase questions. The homepage routes, policies and Contact explain promises and help, and cart confirms the selection. Select a page to inspect its job, exit and failure signal.
Review a page’s job and exit
- Job
Help a new visitor understand who you are, what you sell, what to view first, and why to continue.
- Next step
Move to the featured collection, hero product, or key use-case page.
- Failure signal
The homepage is busy with story and mood, but the shopper still does not know where to click.
- Job
Help shoppers compare by use, situation, category or problem; make the product cards show useful differences.
- Next step
Enter a product page with clear hero picks and differences.
- Failure signal
Product cards look similar, so shoppers cannot decide what to open.
- Job
Explain value, specs, fit, shipping time, return path, and support path.
- Next step
Add to cart, inspect policy, open FAQ, or contact support.
- Failure signal
The shopper still needs support to know whether they can buy.
- Job
Explain shipping, returns, privacy and terms, with a usable support route so shoppers can check promises and get help.
- Next step
Return to product, cart, or contact form.
- Failure signal
Policy pages hide in the footer and conflict with product-page promises.
- Job
Confirm items, price, discount, shipping expectation, and checkout entry.
- Next step
Proceed to checkout; if unsure, return to policies or continue shopping.
- Failure signal
Price, discount, or shipping expectation is unclear, so users leave before checkout.
For the tumbler, Travel Tumblers / Office Commute tells a shopper more than an unexplained internal brand label. The 2-tap homepage-to-main-collection target is an exercise goal, not a Shopify menu limit; a single-product store may route directly to the PDP. Understanding labels and finding back/help paths matters more than reaching a menu count.
Choose a structure for the buyer’s task
The right structure changes with the buying task: choosing one product, comparing categories, gifting, understanding a subscription, or checking a high-ticket fit. Each model includes the first screen, navigation, collections, discovery, orientation, mobile labels and a stop line. The menu preview is a discussion draft, not an implemented theme.
Choose the closest buyer-task model
- First buyer decision
First decide whether one product fits, then confirm specification, delivery, trust, and the purchase path.
- First screen
The first screen explains the product, core outcome, one primary CTA, and reachable Shipping or Contact. It does not send shoppers to an empty collection first.
- Navigation
Put available product-decision and help pages in the main menu. Keep unfinished pages out of it.
- Collection plan
A collection can serve one use case or bundle entry. Do not create many collections just to make a single-product store look like a marketplace.
- Search and filtering
Search and filters are usually not the first task, but record where a shopper goes when they cannot find a specification, FAQ, or accessory.
- Orientation and return
When hierarchy is shallow, keep back paths, policies, and contact consistent. Do not assume every theme has the same breadcrumb pattern.
- Mobile-menu draft
(1) Product; (2) Why it fits; (3) Shipping and returns; (4) Contact
- Accessibility review
After opening the menu by keyboard and on mobile, focus must remain visible, the current entry must be understandable, and closing must return to the trigger before release-level QA.
- Stop line
If the first screen lacks a clear learn-or-buy entry, or shoppers cannot find Shipping, returns, and contact, repair structure before adding brand motion.
- First buyer decision
First find the relevant category or use case, then compare available products instead of guessing through every SKU.
- First screen
The first screen offers one clear primary-category entry and one secondary use-case entry instead of making every collection, promotion, and brand story compete.
- Navigation
Name the main menu by buyer-readable categories or use cases. Keep only comparison-helping levels in submenus and recheck each return path on mobile.
- Collection plan
Each collection answers one comparison question, such as category, use case, or budget. Hero ordering, empty states, and stockout treatment need an explanation.
- Search and filtering
When shoppers must narrow across products, record whether search, filters, and sorting are supported by the current theme, and offer filters only for real product attributes.
- Orientation and return
Deep collections and product pages should help shoppers know which category or use case they came from. Treat breadcrumbs or an equivalent orientation cue as behavior to test in the current theme, not an assumed feature.
- Mobile-menu draft
(1) Shop by category; (2) Shop by use case; (3) Search; (4) Shipping and returns; (5) Contact
- Accessibility review
Test menu levels, filter buttons and sort controls with a keyboard and on a small screen. They must be readable and usable. Assign unsupported behavior to theme changes or development.
- Stop line
If one menu label represents unrelated categories, or filters show misleading zero-result choices, repair classification and product data first.
- First buyer decision
First find a suitable gift by recipient, occasion, budget, or delivery timing, then understand packaging, arrival, and return boundaries.
- First screen
The first screen states an occasion or recipient and one primary entry instead of stacking every deadline, gift box, and discount together.
- Navigation
Navigation prioritizes shopping by recipient, occasion, or budget and keeps delivery timing, packaging, and return access available.
- Collection plan
Collections can organize by gifting job, such as coworkers, birthdays, or budget bands. Each collection should explain when it is not a fit instead of accepting every product.
- Search and filtering
When gift choice is broad, record real conditions such as budget, arrival timing, recipient, or wrapping. Filters and search do not replace separate delivery-promise acceptance.
- Orientation and return
After entering a product from a gift guide, the shopper should still be able to return to the original occasion or recipient path. Whether the current theme provides an orientation cue needs testing.
- Mobile-menu draft
(1) Gifts by recipient; (2) Gifts by occasion; (3) Arrival and wrapping; (4) Returns; (5) Contact
- Accessibility review
Do not use gift imagery or color alone to communicate occasion and budget. Menus, filters, delivery timing, and return access need text labels and visible focus.
- Stop line
If arrival timing, packaging, or return promises cannot be read from the gift path, do not send holiday traffic into it.
- First buyer decision
First understand what is subscribed to, how often it renews, whether it can pause or cancel, and what differs between the first and recurring order.
- First screen
The first screen explains replenishment or membership value, frequency, and the primary choice. It does not merge one-time purchase and subscription terms into an opaque CTA.
- Navigation
Navigation keeps access to how subscription works, manage subscription, Shipping, returns, and contact. Do not hide account access until after checkout.
- Collection plan
Collections organize by replenishment need, subscription plan, or buyer fit. The difference between one-time and subscription purchase must be visible before the product decision.
- Search and filtering
Search and filters can help find a fit, but they do not replace separate reading and acceptance of frequency, cancellation, pause, price changes, or customer-account flow.
- Orientation and return
From plan comparison to product page and account access, shoppers need to know whether they are choosing a product, frequency, or managing an existing subscription.
- Mobile-menu draft
(1) How it works; (2) Choose a plan; (3) Manage subscription; (4) Shipping and returns; (5) Contact
- Accessibility review
Frequency, price, and one-time versus subscription choices cannot rely on visual state alone. Keyboard focus, explicit labels, and error feedback need testing in the current theme and subscription component.
- Stop line
If shoppers cannot find management, pause, cancellation, or next-charge information before purchase, make subscription management and charging information reachable before increasing subscription traffic.
- First buyer decision
First verify fit, specification, compatibility, delivery, risk, and help path before choosing direct purchase, consultation, or a quote.
- First screen
The first screen explains buyer fit, key constraints, and whether the next step is specification, comparison, appointment, or contact. It does not replace a purchase decision with imagery and a low-price anchor.
- Navigation
Navigation should reach specifications, compatibility, examples, delivery, warranty or returns, and consultation. Complex technical language needs buyer-readable labels.
- Collection plan
Collections can compare by use, compatible platform, or budget tier, but cannot mix products with critical constraints into an unexplained product wall.
- Search and filtering
When specifications or compatibility conditions are broad, search and filters should map to real data fields. Verify theme support and zero-result state before treating them as a purchase path.
- Orientation and return
After entering a product from a case, collection, or specification comparison, shoppers need a reviewable return path and clear consultation access. Orientation cues are not a theme-default promise.
- Mobile-menu draft
(1) Choose by use; (2) Specs and compatibility; (3) Examples and compare; (4) Delivery and warranty; (5) Consultation
- Accessibility review
Specification tables, compare controls, and consultation access must be readable through text, keyboard, and focus state. Video or demonstrations cannot be the only compatibility or safety explanation.
- Stop line
If product constraints, delivery conditions, or consultation access are hidden in long copy, imagery, or private chat, repair information architecture before promising purchase.
Search helps someone with a query find content; filters narrow by attributes such as capacity, color, gift set or cup-holder fit; sorting decides what appears first. Core Shopify search and Search & Discovery configuration do different jobs. Filters need a compatible theme and real product fields: creating them in the app does not make them appear in an unsupported theme. Check empty results, stockouts and incorrect fields separately. Breadcrumbs and every filtering feature are not universal theme guarantees.
Open the menu with a keyboard, move through its items, enter and leave drawers or filters, and check where focus returns on closing. Focus should remain visible rather than disappear behind a sticky header, banner or cart. Labels, buttons and errors must be readable on small screens. W3C WCAG 2.2 gives specific focus-obscuring and target-size criteria with exceptions; the checklist records review work rather than a complete accessibility audit.
Read the current progress or completion state in the checklist above. With gaps, return to the earliest buyer-task or evidence break. With every item checked, still read back the current theme, market, product data and release batch.
Evidence recorded
All items reported; review the underlying evidence
Hold
Evidence is still missing
Prioritize a filter decision for a multi-category store
Self-check not answered
Next step from the selected answer
Choose the buyer-task model; verify real fields, theme support and the mobile path.
Prioritize needed entries, then give other pages clear levels and review evidence.
Test the current theme, data, small screen and release batch before relying on capabilities.
Note
No answer selected
Write your own menu labels and evidence locations for the selected model. Fields can remain blank while you investigate; the next reviewer should be able to locate the buyer task, menu route, discovery basis, return/focus scope and untested behavior.
Structure model, evidence and review record
Start with item 1; your choices in the exercises above are carried over.
Example: an office commuter compares leakproofing, cup-holder fit, and arrival timing between two tumblers.
Write actual labels, child levels, and return path after close. Do not enter accounts, passwords, or customer data.
Explain why it is needed or not, which real product field it uses, and evidence of current-theme support.
Record deep-page return path, visible focus, keyboard, drawer close, and small-screen review points.
Record target market, page URL, screenshot date, issue, stop line, and next review. Do not enter customer orders or payment data.
Not saved yet.
Kept in this browser only. Switching device or clearing browser data removes it; download a copy.
Each record group has its own Save, Restore, Clear and JSON export. Save every group you want to keep. After restoring, check that theme, product data, market and paths still apply. Copy/text download reads current content and has a different scope from saving; JSON backs up the corresponding group’s fields and text. If a browser action fails, retain the input and manually copy the visible notes somewhere you control.
These are learning records in this browser on this device. They do not configure Shopify, a theme or search app, or submit inputs to those admin systems. Keep accounts, passwords, recovery codes and customer, order or payment data out of the notes. Each text field accepts up to 2000 characters. If older notes are longer, retain the original browser record and a complete external copy before moving summaries and evidence locations here.
Follow one market view to pre-checkout
Start with currency, language, products, shipping and policies for the target market, then follow navigation, collection, PDP and cart. Markets Active/Draft controls market availability; visitors outside active markets may receive the backup-region experience. A visible page does not establish shipping eligibility, correct tax or a usable payment method. Check those against the current product and address.
Select the least certain path segment
- Buyer question
When I visit from the US, are currency, language, shipping promise, and hero product prepared for me?
- Page action
Review one target market first: the US in this example, or the UK, Canada, Australia, a target country in the EU, or your own first market. Keep unprepared markets in Draft and review the backup-region experience. Route the homepage CTA to the featured collection. The US is a classroom choice, not an inference about the merchant or legal entity.
- Evidence to keep
Markets state screenshot, sample primary-market homepage screenshot, and currency / shipping / language display note.
- Market risk
Without Markets acceptance, shoppers can see wrong currency, unavailable shipping countries, wrong tax treatment, or inconsistent policies.
- Stop line
Do not launch ads in other markets before the US primary path passes.
- Buyer question
Why should I open this 20oz tumbler, and how is it different from the others?
- Page action
Product cards should show more than image and price: capacity, cup-holder fit, leakproof claim, insulation time, or office commute scenario.
- Evidence to keep
Collection product-card screenshot, hero SKU order, and product-page entry click note.
- Market risk
If primary-market price, inventory, or product availability is inconsistent, the collection can show products that cannot or should not be bought.
- Stop line
Pause collection work when hero SKU price, stock, and market availability are inconsistent.
- Buyer question
Do I know capacity, cup-holder fit, cleaning limits, shipping time, return boundary, and who helps if something goes wrong?
- Page action
Place short Shipping, Return, FAQ, and Contact access near add-to-cart, and keep them aligned with policy pages.
- Evidence to keep
Product add-to-cart screenshot, policy access screenshot, and product-policy promise comparison table.
- Market risk
Shipping, return, and support promises can differ by market, so one vague line cannot cover all countries.
- Stop line
Do not enter checkout QA when product-page and policy promises conflict.
- Buyer question
Before checkout, do I understand item, discount, shipping expectation, edit path, and payment entry?
- Page action
In an authorized test environment, use the current hero SKU, specified discount code and an approved US test address to review the mobile cart. Record messages, shipping expectation, edit path and checkout entry. This lesson records the plan and evidence; it creates no order or payment.
- Evidence to keep
Cart screenshot, discount display, shipping message, and pre-checkout screenshot.
- Market risk
If Markets, shipping profile, or discount rule is not aligned, shoppers see shipping surprise or discount failure before checkout.
- Stop line
Do not send live traffic when cart and product-page expectations disagree.
The selected card explains how to review that segment. Evidence for a homepage entry does not cover cart or mobile navigation. Keep market, SKU, discount conditions, theme version, date and device consistent so a repair can be compared.
Write four usable storefront handoffs
Once the sequence is clear, decide what each page carries. Give the homepage one primary CTA to Office Commute / Travel Tumblers. Explain hero, lightweight and gift-set choices in the collection. Near add-to-cart, use 3 to 4 short trust points with Shipping, Returns, FAQ and Contact access. The cart confirms quantity, discount, cost expectations and an edit path.
The sample copy below is a classroom draft to verify. The 30-day return window and USD 50 free-shipping threshold are example merchant choices, not legal rules, Shopify defaults or observed promises. Before publishing, reconcile market, threshold calculation, exclusions, inventory and fulfillment capacity. If the PDP says 7 days while Shipping says 15 to 20 days, resolve that conflict first.
Choose a handoff: placement, click and proof
- Placement
Keep one primary mobile hero CTA pointing to the Office Commute / Travel Tumblers collection; place Shipping or Contact as secondary access without competing with the main path.
- Example copy to verify before use
Sample copy: 20oz leakproof commuter tumbler for office, car cup holders, and daily coffee. Start with US-ready styles.
- Click target
Send the CTA to the primary collection, not all products and not a brand-story page first.
- Proof to keep
Mobile hero screenshot, CTA URL, primary collection URL, and US-market view record.
- Team rule
Hero CTA, primary collection, and campaign entry can be changed only by the store or operations lead, not casually by design.
- Placement
Use the collection first screen to explain why these tumblers belong to one use case, then separate hero, lightweight, and gift-ready picks.
- Example copy to verify before use
Sample copy: If leakproof travel and cup-holder fit matter most, start with the 20oz Commuter. For gifting, start with the gift set.
- Click target
Product cards open the matching product page; filters stay buyer-readable: capacity, color, gift set, and cup-holder fit.
- Proof to keep
Collection first-screen screenshot, hero SKU order, filter fields, and two-tap mobile path.
- Team rule
Merchandising owns collection order; design improves expression but does not change hero SKUs casually.
- Placement
Near add-to-cart, place 3-4 short trust points: 20oz capacity, cup-holder fit, US shipping timing, returns, and support access.
- Example copy to verify before use
Sample copy: 20oz / Fits most cup holders / Ships from US-ready inventory / 30-day return window.
- Click target
Shipping, Returns, FAQ, and Contact open near the add-to-cart area, not only from the footer.
- Proof to keep
Product add-to-cart screenshot, policy links, FAQ accordion, and support access test record.
- Team rule
Any PDP promise change must sync with policy pages, support scripts, and cart messaging.
- Placement
Cart confirms item, quantity, discount, shipping expectation, edit path, and checkout entry.
- Example copy to verify before use
Sample copy: Free shipping over $50 / Discount applied / Review shipping at checkout / Questions? Contact support.
- Click target
The shopper can return to product details, open Shipping/Returns, then enter checkout.
- Proof to keep
Hero SKU, specified discount code, applicable region of the US test address, mobile cart screenshot and pre-checkout state. Redact controlled evidence; do not enter a full address here.
- Team rule
Operations and support jointly review cart messages, discounts, and shipping promises before any campaign goes live.
Collection cards should explain capacity, fit, color, gift-set and use-case differences rather than only image and price. The PDP also needs material, cleaning limits, price, stock and variant-error information. If a discount can only be entered at checkout, explain where it applies. “Calculated at checkout” still needs cost conditions and a route back; it does not explain an unexpected shipping charge by itself.
Homepage, collection and PDP working notes
Start with item 1.
Hero CTA, main menu label, and screenshot proving the main collection is reachable within two clicks.
How the collection groups products, default sorting, hero item, and empty collection handling.
Hero promise, spec position, Shipping / Returns / FAQ / Contact access, without writing full SKU listing details here.
The weakest page, sample copy to place, click target, proof screenshot, and review lead.
Not saved yet.
Kept in this browser only. Switching device or clearing browser data removes it; download a copy.
Trace the storefront problem to its admin source
A Store Structure Map records storefront entry, admin source, buyer question, evidence and stop action. Menu labels live in Content > Menus, while menu display and mobile opening behavior belong to the current theme. Collection product data and the product template also have separate sources. A template arranges sections, the larger page areas, and their blocks. Product facts come from the product record.
Choose the storefront entry to trace
- Storefront surface
Review homepage, collection, cart, and pre-checkout from the same primary-market view.
- Current admin source
Markets: review target-market status, products, currency, language, domain or subfolder, and backup region.
- Buyer question
Are currency, language, shipping country, and policy prepared for my market?
- Evidence before continuing
Record the sample primary-market state, homepage URL, collection URL, cart currency, and pre-checkout shipping availability; if your first market is not the US, replace US market with your own target market.
- Stop signal
The target market is visible before ready, or unfinished markets can still be reached by ads, menus, or campaigns.
- Storefront surface
Product page, policy page, cart, and pre-checkout message should tell one shipping, tax, and delivery expectation.
- Current admin source
Settings > Shipping and delivery; Settings > Taxes and duties; Markets; Shipping policy in Settings > Policies.
- Buyer question
Before checkout, do I know shipping expectation, tax treatment, delivery timing, and return boundary?
- Evidence before continuing
Within an authorized test environment, compare the product, policy, cart and pre-checkout cost messages using the same hero SKU, discount code, target market and test address. Record date and errors without customer or payment data.
- Stop signal
Product page promises free shipping, but cart or pre-checkout reveals unexpected cost or unavailable shipping.
- Storefront surface
Footer, product decision area, mobile menu, and pre-order path can reach Shipping, Return, Privacy, and Contact.
- Current admin source
Online Store > Pages for Contact and other pages; Settings > Policies for policies; Content > Menus for links; Online Store > Themes for their display near the purchase decision.
- Buyer question
If I worry about shipping, returns, or support, can I find usable answers before buying?
- Evidence before continuing
Save footer links, product-nearby access, mobile menu access, Contact form or support email test record.
- Stop signal
Policy content has not been checked against operations, email is unusable, or product-page promises conflict with policy copy.
What belongs in the admin evidence sheet?
Keep the following locations and fields. Names follow current English official documentation; permissions, theme or feature version can change what appears. If an entry is absent, record the difference and ask the owner rather than guessing from an old path.
Storefront issue, admin record and stop action
Markets
- Admin location and fields
- Target market, countries/regions, Active/Draft, products, currency/language, domain path and backup region.
- Storefront check / record
- Same-country homepage, collection, cart and shipping messages; market-path record.
- Pause while unresolved
- Other-market ads, cross-border discounts and shipping promises.
Content > Menus
- Admin location and fields
- Main/Footer menu labels, order, target URLs and mobile entry; check display in the theme.
- Storefront check / record
- Main-collection click path and footer policy/contact links; navigation change log.
- Pause while unresolved
- Homepage polish, ad landing pages and SEO links relying on the broken destination.
Products > Collections
- Admin location and fields
- Handle, manual/conditional grouping, hero SKU order, intro and product publication/market availability.
- Storefront check / record
- First screen explains buyer fit, offer and first pick; collection-path sheet.
- Pause while unresolved
- Primary-category campaigns, collection links and homepage-CTA expansion.
Online Store > Themes > Edit theme
- Admin location and fields
- Home/collection/product templates, sections, blocks, add-to-cart/policy areas and theme version.
- Storefront check / record
- Purchase-area links match policies; theme-version record. Template changes affect all assigned resources; preview does not itself assign the template.
- Pause while unresolved
- Product/template publishing and checkout QA that depends on the template.
Settings > Policies / Online Store > Pages
- Admin location and fields
- Policy copy, Contact URL, version, update date and owner; links in Content > Menus.
- Storefront check / record
- Footer, purchase area and mobile menu reach the same accurate promises; policy-version log.
- Pause while unresolved
- Review submissions relying on old policy content, support-route migration and new promises.
Theme cart / Cart drawer
- Admin location and fields
- Type, discount display, shipping message, quantity, return-to-product and errors.
- Storefront check / record
- Mobile pre-checkout record for the same SKU, discount conditions and target-market test address; cart-path record.
- Pause while unresolved
- Live traffic, discount campaigns and launch announcements.
Settings > Users
- Admin location and fields
- Roles, cumulative effective permissions, theme/menu/policy/product/order scope, 2FA, review date and rollback owner.
- Storefront check / record
- Each change has editor, date, reason and recovery method; access/change ledger.
- Pause while unresolved
- Uncontrolled multi-person work, outsourced redesign and unrecorded launch-day template edits.
For each path, locate the admin source, field record, mobile review and stop action on failure. Read configured shipping and tax messages back for the address. Configuration, actual fulfillment, tax obligations and payment approval remain separate jobs.
Compare plans against the work you have
Count the pages, roles, markets, reports and shipping/tax rules you must review before considering an upgrade. Grow / Shopify reflects historical naming, and Advanced / Plus is not one shared feature promise. Current official documentation gives Basic and Starter no additional staff accounts; exempt owner, collaborator and POS-only user types have their own conditions. Check seats, prices and permissions for the current region, plan and role. Do not bypass limits by sharing the owner login.
A task basis for the plan discussion
Basic
- Task fit
- Best for an early store with one primary market, one main path, limited page changes, and founder-led review. The job is to make homepage, main collection, product page, policy access, and cart-to-pre-checkout work.
- Reason to reassess
- Consider moving up when multiple people edit the theme, support / ads / operations depend on the same path proof, or reporting and permission review become routine work.
- What to solve first
- Do not upgrade just to make the store feel professional. A higher plan does not automatically repair navigation, policy access, or cart proof when the path is broken.
Grow / Shopify
- Task fit
- Best when the main path is stable and the store needs more review rhythm, more collaboration roles, and clearer operating data. Use the actual workload to assess the plan.
- Reason to reassess
- There is a real reason to upgrade when every campaign requires homepage, collection, cart, policy, permission, and data-entry review, and that work starts affecting launch speed.
- What to solve first
- Do not use Grow as a cure for messy page design. Clarify page jobs, path responsibility, and proof records before discussing the plan.
Advanced / Plus
- Task fit
- Best for stores with multiple markets, teams, permissions, shipping / tax rules, and heavier review cadence. Assess these plans when operating rules have become more complex.
- Reason to reassess
- Reassess advanced plans when markets, taxes, shipping, reporting, permissions and support explanations need stronger controls, and the current records identify the bottleneck.
- What to solve first
- Do not jump to an advanced plan to skip basic acceptance. Document paths and changes first so problems remain traceable as settings become more complex.
An upgrade should address an evidenced collaboration, access, reporting or market bottleneck. Repair broken navigation, conflicting policies or unexplained cart costs at their source.
Review the address, promises and help path
The domain brings the visitor to the intended store, TLS protects transport over HTTPS, and policies/Contact explain promises and help. Choose root or www as primary, then check the other entry and old links. Use this checkpoint review here; return to Domain and business email for the full DNS/mail workflow.
Select a domain trust checkpoint
- What to inspect
For a manual third-party-domain connection, compare the current official A, AAAA and www CNAME targets. Verify any regional target shown in the current admin, and inspect records at the actual authoritative DNS host.
- Evidence to keep
Record changed A, AAAA, CNAME records, removed conflicts, and review time.
- What to inspect
Choose whether the root or www is the primary domain, then check the other entry and old-link redirects. Record how a temporary myshopify.com URL is used while preparing a brand domain; a domain name does not verify merchant identity or payment eligibility.
- Evidence to keep
Screenshot of Domains page with primary domain and redirect direction.
- What to inspect
Shopify documents a possible TLS certificate-issuance window of up to 48 hours. Avoid repeated record changes while the certificate is being issued.
- Evidence to keep
Check Connected in Settings > Domains, load the HTTPS storefront without a certificate warning, and inspect external images, fonts or videos for HTTPS delivery.
The record example below follows the current official manual third-party-domain instructions. It is not a lookup result or a command run by this lesson. @ means the root and www a subdomain; compare each value with the actual connection instructions. Resolve conflicting website records without deleting unrelated mail MX/TXT. If registrar and DNS host differ, inspect the authoritative DNS service.
Host Type Value
@ A 23.227.38.65
@ AAAA 2620:0127:f00f:5::
www CNAME shops.myshopify.com.
The official CNAME target includes a trailing dot; a DNS editor may normalize it. The expanded equivalent IPv6 form is 2620:0127:f00f:0005:0000:0000:0000:0000. Keep previous values, change/review times and Settings > Domains status. TLS issuance for a third-party connection can take up to 48 hours. Avoid stacked edits when values are correct within that window; investigate explicit errors or an exceeded window with evidence. A working HTTPS connection covers that layer only.
Questions the policies must answer
Shipping Policy
- Explain
- Clarify processing time, transit time, shipping cost, tracking, and special regions.
- Conflict to repair
- If product page says 7 days but Shipping says 15-20 days, trust breaks.
Return / Refund
- Explain
- Clarify return window, non-returnable cases, cost responsibility, and contact steps.
- Conflict to repair
- An easy-return promise on the PDP that conflicts with a no-return policy leaves shoppers unsure which promise applies.
Privacy Policy
- Explain
- Explain what data is collected, why it is used, and how privacy questions are handled.
- Conflict to repair
- A blank privacy page or a template that has not been checked against operations leaves data-handling questions unanswered.
Terms of Service
- Explain
- Set service terms, purchase limits, dispute handling, and site usage boundaries.
- Conflict to repair
- Terms that conflict with checkout promises create dispute risk.
Contact / About
- Explain
- Provide usable support email, form, response expectation, and basic brand information.
- Conflict to repair
- A new store without contact access makes buyers doubt who will help when problems happen.
Policy windows and costs depend on actual operations, applicable market requirements and deliverable processes. Templates, automated policies and page existence do not complete legal-applicability review. Subscriptions, regulated products or market-specific requirements may need additional disclosures; refer unresolved applicability to a qualified professional. Privacy must match actual data use and tools, and Terms must match purchase limits, disputes and site use. Contact/About should provide real brand information, a usable email/form, response expectations and escalation.
For the built-in Contact page, use the contact template in Online Store > Pages and link it through Content > Menus. Submissions go to the sender email, which is not automatically the owner-login email; check Settings > Notifications. A planned test, sent submission, received message and handled request are distinct states. Record the result of an authorized test.
Make edits traceable to an owner and rollback source
A theme controls layout; templates contain sections and blocks, while product facts come from the resource. A shared-template edit can affect many products or collections. A theme copy preserves theme files/settings; version products, menus, policies, apps and external configuration separately. Shopify-developed free themes, such as Dawn or a current official theme, can be a starting comparison. Still test the actual version, speed, navigation, purchase area and maintenance support.
Three access and change responsibilities
Store owner
- Rule
- Do not share the store owner login; every person who can change the store path needs a clear role.
- Record
- Record account lead, recovery path, 2FA status, and who can approve path changes.
Staff permissions
- Rule
- Design, support, ops, and media roles get only task access; navigation, theme templates, policy access, and cart messages are not open by default.
- Record
- Permission table lists role, editable areas, and review date.
Change log
- Rule
- Navigation, collection, product template, policy access, cart message, and app changes need traceable notes.
- Record
- Record operator, time, reason, affected page, and rollback path.
Arrange two-step authentication and personal recovery for administrators and key operators, then assign task access. Keep recovery codes/passwords in controlled systems rather than plain chat. In this case, design owns authorized theme/menu work and support owns necessary order/customer work. That is a responsibility split, not an assumption that Shopify restricts each role to one page or order. Role permissions accumulate and dependencies may be selected together. The authorized owner should review effective scope, expiry/review and revocation.
Choose the page responsibility to hand over
- Owner
Content lead and design lead share responsibility, with final approval by the store lead.
- Editable scope
Headline, featured collection, hero image, CTA, and one-line brand explanation.
- Review trigger
Review when hero SKU, campaign, positioning, or creative angle changes.
- Evidence to keep
Record current homepage goal, destination path, mobile hero screenshot, and launch date.
- Owner
Merchandising lead; design handles expression, not product logic.
- Editable scope
Collection naming, sort, filters, hero picks, empty states, and mobile browse path.
- Review trigger
Review after launches, delists, price-band changes, and stockouts.
- Evidence to keep
Keep collection rules, sort rationale, stockout handling, and product-link examples.
- Owner
The product lead owns facts, content owns wording, and support answers recurring buyer questions.
- Editable scope
Title, benefits, specs, variants, media, shipping, returns, FAQ, and support access.
- Review trigger
Review after price, spec, fulfillment promise, or return-rule changes.
- Evidence to keep
Record SKU fact sheet, hero screenshot, policy references, and support FAQs.
- Owner
Store lead and support lead are responsible; templates cannot stay unreviewed.
- Editable scope
Shipping, returns, privacy, terms, contact, response time, and escalation path.
- Review trigger
Review when logistics promises, markets, pixel tools, support SLA, or return rules change.
- Evidence to keep
Keep policy URLs, page entry points, support snippets, and latest review time.
After theme, menu or app changes, rerun the main menu, homepage CTA, collection first screen, PDP purchase area, cart drawer and footer policy links. Then inspect recent template, section, app-block and link changes. Restore the affected path and record editor, change, time, reason, pages, rollback source and retest result.
Review pages, domain, access and mobile together
Use the gate cards to locate missing evidence: domain/TLS, page handoffs, policy consistency, access/change control, maintainable theme and mobile path. Carry controlled payment, notification, support and event tests after cart into launch QA. These cards do not cover those separate tests or establish payout, KYC or fulfillment completion.
Choose the gate currently blocking work
- Check
Root domain, www, HTTPS, primary domain, and conflicting DNS records must be accepted.
- Evidence
Shopify domain details show a healthy connection, with DNS change and review times recorded.
- Stop
Do not run ads or share the formal link while domain or TLS is unstable.
- Check
Product page, shipping, return, and contact promises cannot contradict each other.
- Evidence
Shipping time, return boundary, support email, and policy access are visible near decision points.
- Stop
Policy conflicts hurt trust and can affect ad review, support explanations, and disputes.
- Check
Store owner, staff, designers, support, media buyers, and contractors receive only task-needed access.
- Evidence
There is a permission table, 2FA status, and key configuration change record.
- Stop
If multiple people share the store owner login, stop and split access first.
- Check
Start with an official, light, maintainable theme and make the mobile path and product template work first.
- Evidence
Theme, template, app, and code changes have version notes.
- Stop
Do not hide structure problems behind many apps and custom code.
- Check
Run mobile: homepage to collection, product, policy, add-to-cart, cart, and pre-checkout check.
- Evidence
Key path screenshots, issue notes, and responsible leads.
- Stop
If mobile is not smooth, desktop beauty does not mean the launch structure is ready.
Repair the point where the shopper gets stuck
A complete-looking page can still have three common breaks: no mobile route to the hero product, no policy access near add-to-cart, or cart costs that contradict earlier copy. Read the symptom, cause, repair moves, complete proof list and distraction to avoid. Then retest from the same entry.
Choose a break and its smallest useful repair
- Symptom
The homepage hero has a large image and brand line, but mobile users scroll several screens before products appear, and the menu has no clear main category.
- Cause
The homepage does not show where to view products, and its menu labels do not tell shoppers where to go next.
- Repair moves
(1) Keep one clear hero CTA that goes to the featured collection or hero product. Do not show too many exits at once; (2) Name main menu items by category, use case, or problem. Do not rely only on internal brand terms; (3) Rerun the mobile path from homepage to collection and confirm the hero product path is within two taps.
- Complete proof
(1) Mobile homepage hero screenshot; (2) Open main menu screenshot; (3) Homepage-to-collection click path note
- Avoid first
Do not add more brand story or motion first. If users cannot find products, a longer story only adds noise.
- Symptom
The product page has benefits and specs, but buyers must jump to the footer to find Shipping, Returns, or Contact.
- Cause
Trust access is missing near the buying decision. The buyer may like the product but still not know delivery timing, return path, or support access.
- Repair moves
(1) Place short shipping, return, and support links near add-to-cart, not only in the footer; (2) Keep product-page promises aligned with policy pages: timing, return window, and support email must not conflict; (3) Turn frequent support questions into FAQ or product-page notes so buyers do not need support before ordering.
- Complete proof
(1) Product add-to-cart area screenshot; (2) Shipping / Return / Contact link check; (3) Policy and product-page promise comparison note
- Avoid first
Do not use trust badges as a substitute for real policy access. Badges do not answer shipping, return, or support questions.
- Symptom
After adding to cart, the buyer sees shipping cost, discount, or timing that does not match the product-page expectation, then leaves before checkout.
- Cause
The cart does not carry the earlier promise. Product page, policy page, cart, and pre-checkout message are not saying the same thing.
- Repair moves
(1) Set the key shipping expectation on the product page: free-shipping threshold, flat rate, zone rate, or calculated at checkout; (2) Use the cart to confirm item, discount, shipping expectation, and edit path before checkout surprises the buyer; (3) Run product page, add-to-cart, cart, and pre-checkout on mobile, then save screenshots and issue notes.
- Complete proof
(1) Product-page shipping expectation screenshot; (2) Cart price, discount, and shipping message screenshot; (3) Mobile pre-checkout retest note
- Avoid first
Do not treat "calculated at checkout" as the whole explanation. Buyers decide whether to continue before checkout.
The next pressure scenarios ask whether work should continue. Keep the unsafe move, continue condition, first evidence, repair target and pause rule together. “Continue” means the next controlled repair or review, not permission to launch publicly.
Choose the pressure the team faces
- Pressure
Product benefits are written, and support thinks Shipping, Returns, and Contact can be filled after launch.
- Unsafe move
Hide policy pages in the footer and put only trust badges near the product decision.
- Decision
Pause first. Shipping, returns, and support access must be visible near the buying decision, and promises must match policy pages.
- First evidence
Product add-to-cart screenshot marking Shipping, Returns, Contact access, and matching policy wording.
- Repair target
Move frequent doubts into product copy, FAQ, or policy summaries so buyers do not need support before ordering.
- Pause rule
Before policy conflicts are removed, do not scale traffic or promise faster timing.
- Pressure
Products can be added to cart, and the team assumes Shopify checkout defaults are enough.
- Unsafe move
Skip a real product, discount, market, and mobile path test before checkout.
- Decision
Pause first. Run at least one real SKU through product page, add-to-cart, cart, discount, shipping expectation, and pre-checkout message.
- First evidence
Mobile cart screenshot recording item, price, discount, shipping expectation, edit path, and any error message.
- Repair target
Make product page, policy page, cart, and pre-checkout message carry the same promise.
- Pause rule
If cart still creates price or shipping surprise, do not move into ad launch or campaign publishing.
- Pressure
Designers, contractors, support, and media buyers all ask for access and say they only need small edits.
- Unsafe move
Share the store owner login for convenience, or open navigation, theme template, policy access, and cart message edits together.
- Decision
Pause first. Grant minimum task access and record editable scope, review date, 2FA, and path review lead.
- First evidence
Permission table screenshot or note: role, editable pages, blocked areas, review date, and recovery path.
- Repair target
Turn temporary access into reviewed access and restrict key settings to fixed responsible leads.
- Pause rule
Until editable scope, screenshot evidence, and rollback path are recorded, do not let multiple people keep editing.
Check the mobile path against your own evidence
The earlier worked example checked home-collection (homepage to collection) and product-cart (PDP to add-to-cart): 2/6. That illustrates what a tick means; it does not complete those tasks for you. Your fresh and cleared record starts empty. Check an item only when you have evidence for that path.
Read your current progress or completion state in the checklist above. If the mobile menu fails, policies cannot be found, or variants/add-to-cart are unclear, repair those gaps before launch QA. A desktop screenshot does not substitute for a mobile result.
Evidence recorded
All items reported; review the underlying evidence
Hold
Evidence is still missing
What comes first when Shipping and Contact are missing?
Self-check not answered
Next step from the selected answer
Repair navigation, footer and policy/contact access near the purchase decision.
Establish understanding, trust and continuation before decoration.
Clarify category, policy, contact and purchase paths first.
Note
No answer selected
Policy, cart and responsibility working notes
Start with item 1.
Shipping, Returns, Privacy, and Contact access in the footer, near product decisions, and in the mobile menu.
Add-to-cart, quantity, discount, shipping expectation, edit path, and error state screenshots.
Who can change navigation, theme templates, policy access, cart messages, and when to review.
Not saved yet.
Kept in this browser only. Switching device or clearing browser data removes it; download a copy.
No checkpoint finished in this lesson yet. Start with “Go to the exercise”.
Self-check not answered
Your work
- Record · Choose a structure for the buyer’s taskNot saved
- Record · Write four usable storefront handoffsNot saved
- Record · Check the mobile path against your own evidenceNot saved
- Record · Check the mobile path against your own evidenceNot saved
- Note · Check the mobile path against your own evidenceNot copied
Kept in this browser only. Switching device or clearing browser data removes it; download a copy.
Keep the map and choose the next job
The architecture record keeps the model, five evidence checks, classification answer and five text fields. The group below saves the other path selections, quick check and your mobile ticks; the two working-note groups keep the seven page notes. Older browser snapshots cover only the architecture record. Keep a separate copy of any draft of the seven page notes that was left unsaved. These are learning records; store completion still depends on actual evidence.
Path selections, mobile checks and quick answer
Start with item 1; your choices in the exercises above are carried over.
Not saved yet.
Kept in this browser only. Switching device or clearing browser data removes it; download a copy.
Choose the next route from the earliest gap
- Advice
Continue into product trust, first SKUs, media, pricing, and listing rhythm.
- Lesson link
- Advice
Align Shipping, Returns, Privacy, Terms and Contact with actual operations, support explanations and after-sales work. Having the pages alone does not guarantee platform approval or a legal conclusion.
- Lesson link
- Advice
Return to domain, DNS, business email, and sender authentication.
- Lesson link
- Advice
Enter launch QA with mobile path, pre-checkout evidence, notifications, and data events.
- Lesson link
Before copying, locate page jobs, simulator result, four execution blocks, structure map, mobile paths, continue-or-pause decision, owner, latest editor, rollback source and next route. The text below includes current selections and their evidence context. Download it, retain it manually if copying fails, or hand it to the next owner for review.
Store path launch map
Page role and exit: Product page; (to fill in)
Simulator and evidence: US primary market entry; (to fill in)
Selected execution block and proof: Homepage hero entry; (to fill in)
Structure map and proof: Markets entry; (to fill in)
Corresponding admin source: Markets entry; (to fill in)
Current gate and evidence: Page path; (to fill in)
Repair and complete proof: Mobile users cannot find hero products; (to fill in)
Domain checkpoint and evidence: DNS records; (to fill in)
Ownership and review evidence: Navigation and footer; (to fill in)
Continue-or-pause decision: Can navigation continue?; (to fill in)
First evidence for that decision: Can navigation continue?; (to fill in)
Repair target: Can navigation continue?; (to fill in)
Pause rule: Can navigation continue?; (to fill in)
Your mobile-path count: 0
Your selected mobile paths: (to fill in)
Structure model and buyer task: Single-product store; (to fill in)
Architecture evidence count: 0
Architecture classification: (to fill in); No answer selected
Quick check: (to fill in); No answer selected
Next route and advice: Path is clear, product pages are weak; (to fill in)
Buyer task this structure serves first: (to fill in)
Mobile menu labels and level record: (to fill in)
Search, filter, sort, or zero-result decision: (to fill in)
Orientation and accessibility review scope: (to fill in)
Screenshot, path, or repair-evidence location: (to fill in)
Homepage-to-main-collection path: (to fill in)
Collection role and filters: (to fill in)
Product template boundary: (to fill in)
Homepage-to-checkout path drill: (to fill in)
Policy and contact access: (to fill in)
Cart-to-pre-checkout proof: (to fill in)
Path responsibility and review: (to fill in)
Complete feedback index (unfiltered reference): match the actual selected option name above to its explanation below. The selected name and concise next step appear separately; this index keeps every original explanation in copied/downloaded text.
Architecture classification; Choose the model that fits the buyer task first, write real menu labels and one path proof, then decide whether search, filters, or an orientation cue are needed. Correct. Arrange pages around the buyer task, product data, current theme and mobile path, then verify the implementation. List unverified capabilities as follow-up work.
Architecture classification; To avoid missing information, put every collection, policy, promotion, app, and brand page in the first level of the mobile menu. Not correct. Prioritize the entries needed for the current buyer task, then give other content clear levels and a basis for review.
Architecture classification; Assume the theme already supports filters, search, breadcrumbs, and an accessible menu, so send ad traffic first and test later. Not correct. Verify theme, data and component behavior in the current store, on a small screen and for this release. Follow each recorded test item through to a result.
Quick check; Install more trust badge apps: Badges cannot replace real paths. Fix navigation, footer, and trust access near product decisions first.
Quick check; Fix store path and policy access first: Correct. Store structure first solves understanding, trust, and continuation. Decoration hides the problem when the path is broken.
Quick check; Make the homepage story longer: More brand story leaves the missing policy and contact routes unresolved. Clarify category, policy, contact and purchase paths first.
For handoff, include market, theme/template version, URL, screenshot date, owner, latest editor, issue, next review and rollback source. Copy/download reads current content; save each group separately.
Address the earliest evidence gap, then carry the result into Product listing, Policy pages or Launch QA. Return to Store Foundations to review the wider sequence.
Common questions
These answers connect page responsibilities to the actual review. Judge configurations and permissions against the current store, market, theme and authorized test results.
- When do I actually need to work through Shopify store structure and launch setup?
- Use it when the store opens but you cannot prove that a mobile shopper can move from ad click, homepage, main collection, product page, policy access, cart, and pre-checkout without confusion. Use this review to check the path, evidence and responsible people before arranging further design work.
- How should I run a Shopify store structure checklist?
- Choose one real market and one real SKU, then move from homepage or ad entry through navigation, collection, product page, policy access, cart, and pre-checkout. US market is only the sample in this store-path review, not the default for every beginner. Keep a screenshot, pass standard, and repair action for each step.
- What navigation links should a Shopify store have before launch?
- Make the current primary category and core collection understandable. Add search/filter paths where the buyer task, product data and theme support justify them. Keep Shipping, Returns, Privacy, Terms and Contact reachable from the footer. Use buyer-readable top-level labels and test levels and return paths; there is no universal menu quota.
- How should the homepage, collection page, and product page work together?
- The homepage routes a cold shopper to the right path, the collection page explains who the category is for and what to open first, and the product page resolves specs, price, shipping, returns, and add-to-cart doubts. They should hand off to each other, not repeat the same brand story.
- Why should Shipping, Returns, FAQ, and Contact appear near the product decision?
- Buyers judge shipping cost, return safety, fit, timing, and support before they add to cart. If policies only live in the footer, the product page may look shoppable while still missing trust evidence.
- What proof should I collect from cart to pre-checkout?
- In an authorized environment, take the current hero SKU, specified discount conditions, target market and test address through mobile pre-checkout. Check price, where the discount applies, shipping/tax messages, quantity editing, return-to-product and errors. Keep date, version, device and redacted evidence; this does not create an order, payment or fulfillment result in this lesson.
- What should I check first when a theme change breaks the mobile path?
- Start with the mobile menu, homepage CTA, collection first screen, product add-to-cart area, cart drawer, and footer policy links. Then inspect the latest theme template, section, app block, and navigation changes. Restore the path before polishing visuals.
- What should a store-path review record include?
- Include current page role, store path simulator result, four-block drill proof, Store Structure Map, checked mobile paths, Store Path continue-or-pause practice result, responsible lead, latest editor, rollback source, and next lesson route.