Ask one question first: did the page look faded and refuse to respond to taps? If so it is not broken. Until a visitor answers the cookie banner, the page behind it is deliberately dimmed and inert. Choosing Essential only or Accept brings it to life.
The four that account for most reports
- Faded, greyed out, or 'frozen'
- The cookie banner has not been answered yet. The dimming is honest signalling: nothing behind the banner is meant to be usable until a choice is made.
- Black background with white text
- High contrast is switched on in the Inclusion Bar's Adjust menu. It is a per-visitor accessibility setting, not something you configured. Turning it off in the same menu restores your colours.
- The page is in another language
- The visitor picked one from the Translate control, or is looking at a phone somebody else set. Selecting English clears it instantly.
- Text is enormous and the layout is cramped
- Text size has been stepped up to Large or Larger. It cycles back to Normal from the same menu.
Gates that look like faults
- A screen asking for a PIN means Require PIN to view is on in the Experience's Settings tab. Visitors get a lock screen before any content.
- A card asking for a phone number means a block has Ask visitors to verify their phone first switched on. One code unlocks every gated block across your whole space.
- "This Experience is not available" means it has been unpublished. The content is intact; publish it again.
- "Allow cookies to continue" appears when someone taps a question or a capture block without having accepted. Nothing is lost: they accept, and the tap works.
Half-finished blocks
Some blocks tell you plainly when they are missing a setting, and that message is visible on the live page. If a visitor describes a grey box with instructions in it, that is one of these:
- "Add a phone number to finish this Call Action."
- "Upload a file to finish this File Action."
- "Upload a .usdz (iPhone) and a .glb (Android) to finish this AR Action."
- "Payments not connected yet": the Pay or Donate block renders, but nothing can be charged until Stripe is connected on Account.
Reproduce what they saw
- 1
Use the public address, not the preview
Open
getnearfield.com/view/{hash}on a phone. The builder preview deliberately skips the cookie banner and the PIN lock, so it cannot show you either of the two most-reported problems. - 2
Use a private window
A normal window remembers your own cookie choice, language and text size, so you will never see what a first-time visitor sees.
- 3
Reproduce the setting
Open the Inclusion Bar's Adjust menu and turn on the thing they described (high contrast, or larger text) then look at the page again.
- 4
Check it on both phones
Test an iPhone and an Android. Differences in how a video, a PDF or a saved contact card behaves are almost always platform behaviour rather than a fault.
Example
Harbour Point Aquarium: the 'blank' school-group page
A teacher reported the school-group Experience was blank. She had tapped, seen the cookie banner, put the phone in her pocket, and come back to a dimmed page she assumed had crashed. Nothing was wrong. The aquarium now mentions the one-time cookie choice in its pre-visit email.
If none of that worked
Ask for a screenshot. It answers the question faster than any description, and it tells us immediately whether we are looking at a setting or a fault. Send it with the Experience name and the Support PIN from your Account page.
Can I stop the cookie banner appearing?
No, and you would not want to. It is what makes the analytics and the personalisation lawful to run. It appears once per device and remembers the answer.
Why can visitors not pinch to zoom?
Pinch zoom is switched off on Experience pages on purpose, and the Inclusion Bar's text size control replaces it. Pinch zoom on a page with a fixed bottom bar produces a layout nobody can escape from.
The page looks fine to me but wrong to them. Same phone model.
Then it is a per-visitor setting. High contrast and text size are stored on their device, not on your Experience.