Google Review NFC Card Setup Guide

Get the right review destination before anything else

The single biggest setup mistake is encoding a review URL the business does not control or that points somewhere slightly wrong. Spend the first hour getting this right; everything else becomes easier. A wrong URL discovered after 5,000 cards are printed is an unrecoverable loss. There is no way to rewrite a printed QR code, and NFC tags that are not physically accessible cannot be re-encoded in bulk.

• The canonical destination is a Google Business Profile review URL generated from the Profile's unique Place ID. It takes the form https://search.google.com/local/writereview?placeid=XXXX or the newer g.page/r/ shortlink. Both work on current iOS and Android, and Google automatically handles the routing to the Google Maps or Google Search review prompt depending on the device and its default apps.
• Do not use a Google Maps listing URL, a search result URL, or a business's homepage. Those paths add friction (one or two extra taps to find the review button), cost conversions at each friction step, and change behaviour across iOS and Android in ways the business cannot anticipate. The direct writereview URL is the only path that lands on the review composer in one step across both platforms.
• Verify ownership of the Business Profile before setup. A card pointing to a profile someone else controls (a former agency, a parent company that has sold the business, a listing claimed by a previous owner) will break the moment ownership changes, and the recovery process through Google Business Profile support takes weeks. Confirm admin access through the official Google Business Profile dashboard before encoding any URL.
• For new locations, create the Business Profile and let it index for at least 48 hours before generating the review link. Fresh listings occasionally redirect unpredictably as Google's index propagates; waiting avoids the 'my card worked yesterday but not today' class of bug during early-days operations.
• Document the exact URL used for each location in a version-controlled source of truth (not just an email thread or an individual's spreadsheet). Six months from now, someone will ask 'which URL is on the cards' and the answer has to be auditable, not vague. The documentation also supports the reprint and refresh process without requiring the original programme owner to be available.
• Place ID discovery tool: Google publishes a Place ID Finder at developers.google.com that accepts a business name and returns the unique Place ID. Use the tool at setup time, save the Place ID alongside the generated review URL, and re-verify once a quarter that the Place ID has not changed (it usually doesn't, but merges and de-duplications do happen).
• Edge case: businesses with multiple categories on Google (restaurant + bar, hotel + spa) sometimes have ambiguous Place ID resolutions. Explicitly test the review URL on the device types customers use, and confirm it lands on the correct composer for the primary category.

Redirect ownership and why it matters

Most multi-location or growing brands end up routing the review URL through a short domain they control. Review.brand.com/shop1. The reason: NFC chips are a fixed payload, so the URL on the card has to stay stable for years while the Google URL format, Place ID and account ownership can all change beneath it. A brand-owned redirect is the insurance policy against every future change.

• Direct link: encode the raw Google review URL on the chip. Simplest, no infrastructure, no tracking, zero operating cost. Breaks if the Google URL format changes or if the business moves to a new Profile. Both of which have happened in the past and will happen again. Acceptable for single-location, short-duration programmes (pop-ups, seasonal events) where longevity is not a concern.
• Self-hosted redirect: encode review.brand.com/shop1 on the chip; the short domain 301-redirects to the Google review URL. Slightly more complex to set up (a DNS record, a small Cloudflare Worker or Nginx rewrite rule), but gives the business control. When Google changes its URL format, the business updates one redirect rule and every printed card keeps working without reprinting.
• Analytics layer: the self-hosted redirect can log taps per location before redirecting, with per-tap fields for timestamp, user agent, referer and IP hash. Useful for conversion attribution in multi-location programmes. The scan-to-review ratio is the most diagnostic metric for pinpointing programme failures (broken routing, low placement visibility, staff prompt decay) that simple review-velocity tracking cannot see.
• Third-party shortener: avoid bit.ly, tinyurl and other consumer shorteners on printed cards. They change behaviour (URL previews, splash pages, forced app launches on mobile), add friction, can expire without warning if the account goes inactive, and some enterprise proxy networks and corporate MDM policies block them outright. A printed card pointing at a dead short-URL is unrecoverable.
• Paid enterprise shorteners (Rebrandly, Bitly Enterprise, Branch): fine and sometimes useful for brands that want branded short links without self-hosting. More expensive than a self-hosted redirect (monthly fees that scale with volume) and still involve a third party in a mission-critical path. Evaluate against the operational simplicity of a self-hosted redirect before committing.
• Best practice for brands with more than one location: self-hosted redirect under a review subdomain. The infrastructure is under a dozen lines of Nginx config or Cloudflare Workers code and pays for itself the first time a Google URL format changes, which happens every few years. The redirect subdomain also becomes a clean first-party analytics boundary for the programme.
• Fallback architecture: when the redirect system is down, the NFC chip should still work through a failover path. One common pattern is to encode a multi-step NDEF record where the primary URL is the branded redirect and a secondary on-device fallback page is included as a static alternative. Simpler: always include a QR code encoding the raw Google URL directly, so the card has a redirect-independent path.

NFC payload choice: keep it simple

NFC chips support several payload types. For a review card, exactly one payload makes sense. Complexity costs reliability, and the most reliable programmes are the ones that resist the temptation to do anything clever with the NFC payload beyond pointing at a URL.

• URI record (web link): this is the correct choice. Encoded as a plain https URL, works on every modern iPhone (iOS 14+ with background NFC reading, iOS 11+ with NFC Tag Reader app) and every modern Android (Android 5+ with stock NFC handler) without any app installation or user setup step. The URI record is the most broadly supported NDEF format by a wide margin.
• NDEF App record (AAR, Android Application Record): avoid. Attempts to launch a specific app on Android and falls back to URL on iOS; breaks when the app is not installed, when the user chooses not to open the app store, when the OS blocks the behaviour, or when enterprise MDM policies prevent app launching. Even the fallback-to-URL behaviour is inconsistent across Android versions.
• Custom MIME record: avoid. Requires a specific reader app that understands the MIME type; kills the experience for 95% of customers who do not have that app installed. Custom MIME is useful for internal-operations tags and payment tags, not for customer-facing review cards.
• Text record: avoid. Displays the URL as text instead of opening it; customers have to copy-paste, which is enough friction to lose 60-80% of the conversion. Text records are useful for sharing written information (an address, a phone number as plain text) but never for calls-to-action.
• Smart Poster record: redundant for review cards because the URI record already covers every function a review card needs; adds encoding complexity (title, action and URI sub-records) without adding reliability. Smart Poster was designed for environments with older reader behaviour; current handsets all handle plain URI records better.
• Lock the tag after encoding. Unlocked NTAG chips can be rewritten by any phone with an NFC writer app, and some customers do this accidentally (many NFC reader apps have a 'write' mode one tap away from the 'read' mode). A locked chip cannot be changed after setup. Which is a feature, not a bug, for branded cards. Locking is irreversible on NTAG21x series, so lock after the final URL is verified, not during setup exploration.
• Password protection (optional): NTAG213/215/216 support a 32-bit password on top of the lock bit. Useful for defence in depth in programmes where malicious rewriting is a realistic concern (event tickets, high-value authentication, reusable credentials). Overkill for a standard review card programme.
• Chip choice: NTAG213 is the baseline for review cards (144 bytes of NDEF storage, enough for any URL under 130 characters). NTAG216 (888 bytes) is needed only if the payload includes an extended URL with tracking parameters longer than the NTAG213 limit. NTAG215 is rarely used for review cards because its intermediate capacity has no review-card-specific advantage.

Multi-device testing: the real phones customers carry

A setup that passes on the team's latest iPhone may fail on an older Android or a phone with NFC disabled. Test across the devices customers actually use, not just the devices the team prefers, because the team's tech-savvy bias produces a testing set that is systematically more forgiving than the real customer population.

• Minimum test set: current-generation iPhone, current-generation Android flagship (Samsung Galaxy or Google Pixel), mid-range Android from three years ago (Samsung A-series or similar), and a mid-tier Android with NFC disabled by default (some markets still ship these in budget tiers, and some enterprise MDM policies disable NFC by default). For multi-location rollouts add a fifth test device matching the dominant customer demographic of the weakest-performing pilot location.
• Test motion: tap the card to the back of the phone at the typical NFC hot-spot location. iPhones have the antenna near the top of the back (close to the Apple logo on most models); many Androids have it in the middle or near the camera. Some Samsung phones place the antenna near the top-right corner. The antenna-location variance is part of why a consistent tap-here icon on the card helps. It tells customers where to position the card, not where to position the phone.
• Test state: phone locked (should still work on most modern devices when background NFC tag reading is enabled), phone unlocked on home screen, phone in-app. Some apps intercept NFC intent (banking, transport, payments); check the most common ones for your market (Apple Pay, Google Wallet, local transit apps) and confirm they do not block the review URL opening. iOS 18 changes Apple Pay default-app behaviour in some regions and is worth re-testing.
• Test fallback: turn NFC off on one test device and confirm the QR code scans reliably from 40 cm under the actual placement lighting. QR has to be a genuine fallback, not a theoretical one. If the QR fails to scan for the NFC-disabled customer, the card's fallback path is imaginary and the programme loses those customers silently.
• Test geography: if the brand operates internationally, test with a phone on a foreign carrier SIM or international data roaming. Some mobile redirects behave differently based on region (Great Firewall in mainland China, carrier HTTP rewriting in certain markets, GDPR-triggered consent banners in the EU), and the review URL might hit an unexpected interstitial.
• Edge case: customers with phone cases covering the NFC antenna. Most thin cases do not interfere; some ruggedised cases, wallet cases, or cases with metal backings do. The card should still tap reliably with common cases; if it does not, the customer blames the card, not the case. Test with the three most common case styles.
• Browser behaviour: the review URL opens in the device's default browser (Safari on iOS, Chrome or Samsung Internet on Android). Confirm the composer loads cleanly in each and does not trigger unexpected app-switch prompts or 'open in Google Maps?' interstitials. In-app browsers (Instagram, TikTok, Gmail preview) sometimes break the review composer. If the card lives in a delivery bag alongside a social-media unboxing moment, test that path too.
• Accessibility: screen readers (VoiceOver on iOS, TalkBack on Android) should announce the NFC URL as a link. Customers who rely on assistive tech should be able to engage with the prompt; the URL should use a clean domain rather than a random-looking shortener, because the screen reader reads the URL aloud.

Multi-location URL strategy

Single-location brands encode one URL. Multi-location brands need a strategy that scales without creating a per-location manual step for every new card batch, and the governance discipline matters. A mis-mapped Place ID discovered at 200 locations is orders of magnitude more painful than the same mistake at one location.

• Per-location URL: each location has its own redirect (review.brand.com/shop1, review.brand.com/shop2, review.brand.com/downtown, etc.) pointing to the location's Google Business Profile review URL. The slug convention is a design decision worth making once. Numeric IDs are neutral and compact; location-name slugs are more memorable and human-debuggable but require re-mapping during location renames or moves.
• Print batch per location: card artwork stays identical, but the NFC payload and the printed QR code both carry the per-location URL. Printing is straightforward with modern variable-data presses, and the per-unit cost premium over identical-URL batches is typically 5-15% depending on vendor. The operational simplicity at point of use pays back the premium within one quarter.
• Central admin: one web app or spreadsheet mapping location ID to Place ID to redirect URL, ideally in version control or a database with audit trails. Source of truth for card printing, onboarding of new locations, and migrations. The admin panel also powers any analytics dashboards that surface per-location scan counts or scan-to-review conversion.
• New location onboarding: create the Google Business Profile, capture the Place ID, add a redirect row in the admin panel, print the card batch from the standard template, ship to the new location with a launch kit. Written SOP prevents mistakes, and the SOP should live in the operations runbook alongside the other new-location launch checklist items.
• Location closures: decommission the redirect URL (404 the short URL, or return a graceful 'this location has closed' page) so residual cards do not drive traffic to a wrong profile. Log the decommission for audit. Abrupt 404s look worse than a branded closed-location page; invest in the graceful fallback.
• Brand-wide URL: never encode a brand homepage or a generic 'find a store' URL. The customer is holding a card at a specific location and expects to review that specific location. Brand-wide URLs produce a scattered review signal (the brand homepage or a generic locator page) that does not improve any single location's map-pack ranking, which defeats the programme's primary purpose.
• URL versioning: when an artwork refresh changes the placement URL scheme (for example, moving from review.brand.com/shop1 to review.brand.com/v2/downtown), keep the old redirect active for at least 24 months so cards in circulation continue to work. Cards printed in 2024 will still be in circulation in 2026; URL retirement needs to match that timeline.
• Franchise migrations: when a franchisee ownership transfer happens, the redirect target may change (new Place ID, new account ownership) without the cards being reprinted. The central admin panel should handle this transparently. The printed URL stays the same; only the destination Place ID changes. This is a practical reason for brand-owned redirect infrastructure.

QR fallback design

QR has to work when NFC fails. Treat it as a first-class part of the setup, not an afterthought, because in practice 30-50% of customers use the QR path (phone cases, NFC disabled, unfamiliarity with the tap motion, or simple preference for the QR they already know from menus and wifi logins).

• Source URL: the QR encodes the same per-location URL as the NFC chip. Both paths lead to the same destination, which means a customer who taps and then scans (or vice versa) never ends up on a different page. Divergent URLs create debugging confusion and waste the scan.
• Size: minimum 2 cm square on the printed card (2.5 cm is safer for mixed-audience venues and low-light placements). Smaller QR codes fail scans from natural reading distance (about 40 cm) and hurt the fallback. The space cost of a 2.5 cm QR is small relative to the conversion cost of scan failures.
• Contrast: dark QR on a light background is most reliable because most phone cameras auto-expose for the brighter background and the dark modules read cleanly. Reverse-contrast (light QR on dark background) works but needs 20% larger sizing and tighter module definition. Avoid low-contrast mid-tone palettes entirely; the scan reliability collapses.
• Quiet zone: at least 4 mm of uninterrupted background around the code. Decorative elements, brand patterns, or other visual elements that bleed into the quiet zone break scans more often than designers expect. The quiet zone is part of the QR's reader-detection pattern; ignoring it is not a style choice, it is a functional failure.
• Gloss interaction: gloss lamination creates glare under overhead lighting (lobby spots, ceiling halogens) that reduces QR scan reliability, particularly at oblique viewing angles. Spot-matte over the QR area helps, or use a matte or soft-touch substrate for the whole card. Testing the scan under the actual placement lighting catches this before print.
• Version choice: QR code version 2 or 3 is plenty for a URL under 60 characters. Higher versions add module density that reduces scan reliability at small sizes. Error correction level M (medium, 15%) is the common default; level Q (25%) or H (30%) gives more robustness against partial occlusion but increases module density. For review cards, M is usually right.
• Embedded logo: some brands embed a small logo in the centre of the QR code. Acceptable up to about 10% of the code area; anything larger breaks error-correction reliability to the point where partially-lit or partially-scuffed cards fail. Most programmes skip the logo because the space cost exceeds the brand value.
• QR URL shortening: the URL encoded in the QR should be short enough that the resulting code is readable at 2 cm. A review.brand.com/shop1 redirect (20-25 characters) produces a clean low-density code; a raw Google review URL with embedded Place ID (60-80 characters) produces a denser code that needs larger sizing to scan reliably.

Step-by-step: Place ID capture and link generation across iPhone, Android and Web

The 7-step workflow below walks the operator from blank Google Business Profile to encoded NFC tag in under 30 minutes for a single location, scaling linearly per additional location through the central admin pattern in the multi-location section. Each step assumes the operator has admin access to the Google Business Profile and a basic NFC writer app installed (NFC Tools by wakdev is the most universally recommended; available on both iOS App Store and Google Play). For iOS 18 users, native Control Center NFC Scan can be used for read-only verification but writing still needs an app.

• Step 1 — Confirm Google Business Profile ownership: log into business.google.com with the account that owns the profile. If the profile shows 'Pending verification' or 'Suggested edit', complete verification (Google sends a postcard with a 5-digit PIN to the business address; this can take 7–14 days for new profiles). Do not encode any card while verification is pending.
• Step 2 — Capture the Place ID: open developers.google.com/maps/documentation/javascript/examples/places-placeid-finder, search for the business by name and address, and copy the alphanumeric Place ID (typically starts with 'ChIJ' followed by 21 characters). Save the Place ID in the central admin spreadsheet alongside the location's slug, address and Place ID capture date.
• Step 3 — Generate the canonical review URL: paste the Place ID into the template https://search.google.com/local/writereview?placeid=YOUR_PLACE_ID. Test the URL by opening it in an incognito browser tab on the operator's desktop; it should load the 'Rate and review' sheet for the correct business. If it loads a different business, the Place ID is wrong (most often because of a duplicated profile or a sibling location with similar name).
• Step 4 — Set up the redirect (multi-location only): create a DNS record for review.brand.com (CNAME to a Cloudflare Workers domain or a small hosting endpoint), add a 301-redirect rule mapping /location-slug to the canonical Google URL from Step 3. Confirm with curl -I https://review.brand.com/location-slug that the response is 301 and the Location header points to the correct Google URL.
• Step 5 — Encode the NFC tag (iPhone path): open NFC Tools on iPhone, tap 'Write', tap 'Add a record', tap 'URL/URI', paste the canonical or redirect URL, then tap 'Write' and present an NTAG213/215 card to the back of the iPhone (above the camera, where the iPhone's NFC antenna sits). Confirmation message appears in the app within 1–2 seconds.
• Step 6 — Encode the NFC tag (Android path): open NFC Tools on Android, tap 'Write', tap 'Add a record', tap 'URL/URI', paste the URL, tap 'OK' then 'Write / 1 record', and present the card to the phone's NFC antenna (location varies; commonly the centre or upper third of the back). Faster than iOS in most cases (<1 second per write).
• Step 7 — Lock the tag and verify: in NFC Tools, choose 'Other' > 'Lock tag' to make the URL irreversible, then test the locked tag by tapping with a different test phone. Tap should open the 'Rate and review' sheet within 1–2 seconds of the tap. If the test passes on iPhone (iOS 14+), Android (5.0+), and the QR fallback also scans correctly from 40 cm at typical lobby lighting, the card is ready for the pilot batch.

Troubleshooting tree: 'My customer says the card doesn't work'

The list below is the diagnostic decision tree the operations team should run when a complaint reaches the help desk. Each branch isolates one variable and either fixes the issue or escalates to the next layer. Most reported failures resolve at branch 1 or 2; structural issues (wrong URL, expired Business Profile, broken redirect) appear at branches 3–5 and require the operator's intervention. Print this list as a one-page laminated job aid for the front-of-house team.

• Branch 1 — Tap location: confirm the customer is tapping the back of their phone to the card. Many customers (especially older demographics and Android users new to NFC) intuitively try tapping the front of the phone. Show them the back of an iPhone (top, near the camera) or Android (varies; centre is the safe default). Resolves ~30% of reported failures.
• Branch 2 — NFC enabled: ask the customer to check if NFC is enabled in their phone's settings. Android: Settings > Connected devices > NFC. iPhone: NFC is always enabled and cannot be disabled, but Express Mode for transit/payment cards can intercept the tap. Have them temporarily disable Express Mode in Wallet settings if Apple Pay opens instead of the review URL. Resolves ~20% of failures.
• Branch 3 — Phone case interference: if the customer has a thick wallet case, magnetic case, or a case with metal backing or embedded card slots, the NFC antenna may be blocked. Have them remove the case briefly and re-tap. Resolves ~15% of failures.
• Branch 4 — QR fallback: if NFC continues to fail, direct the customer to scan the QR code instead. The QR should scan reliably from 40 cm at typical lobby lighting; if the QR also fails, the issue is structural rather than device-specific. Resolves ~10% of failures.
• Branch 5 — Wrong URL or broken redirect: if QR also fails, the operator runs the URL through a desktop browser (incognito). If the URL does not load the correct review composer, the Place ID is wrong (capture again from Place ID Finder), the Business Profile has been suspended (check Business Profile manager for any compliance flag), or the redirect endpoint is down (check the redirect host's status page or run curl -I against the URL). This branch typically requires escalation to the brand-side admin and may require recoding the tag or updating the redirect rule.
• Branch 6 — Carrier or geographic issue: international roaming customers and customers on aggressive corporate VPNs sometimes hit interstitials or get blocked entirely. The Great Firewall blocks google.com search results for mainland China traffic; some EU privacy proxies trigger consent banners that look like errors. Document these as known edge cases rather than per-customer fixes; the central admin can publish a fallback HTML page that lists alternative review channels (Tripadvisor, Yelp, Google via Maps app rather than search) for these geographies.
• Branch 7 — Operator-side data review: if multiple complaints accumulate from the same location within 48 hours, pull the redirect logs (taps per location per hour), confirm the tap-to-Google-review conversion rate is within the expected band (typically 25–40% for hospitality, 15–30% for retail), and escalate to the brand-side admin if the rate has dropped 50%+ from baseline. Most multi-location programmes catch broken setups this way before they spread across the franchise.

Go-live checklist before the first branded print run

A pilot sample is the right place to catch setup mistakes. Running the full go-live checklist on 50 pilot cards prevents printing 5,000 cards with a broken URL, a mis-mapped Place ID, or an unlockable NFC chip. All of which are expensive to recover from once the full batch is in the warehouse.

• URL validation: every URL (NFC payload and QR) resolves to the correct Google review profile on at least three test devices across iOS and Android. Confirm the review composer loads in both the native Google app (if installed) and the device's default browser, because the routing behaviour can differ. A URL that works 'on my phone' is not validated until it works on at least two other phones.
• Redirect chain audit: if using a self-hosted redirect, confirm there is exactly one 301 redirect, not a chain. Chains (review.brand.com → bit.ly → google.com) slow the hop, sometimes break on cellular networks with aggressive proxy rewriting, and add points of failure. Use curl or an online HTTP-trace tool to inspect the full chain before signing off.
• HTTPS: every URL in the chain uses HTTPS. Mixed-content redirects (http → https, or vice versa) break silently on modern iOS and some Android builds, producing a scan that appears to succeed but lands the customer on an error page. The TLS certificate on the redirect host should also be valid and not near expiry.
• Lock status: NFC tag lock bit is set on every shipped card, so the payload cannot be accidentally rewritten by a customer with an NFC writer app. Verify lock status on a sample of the pilot batch using a standard NFC tools app; unlocked chips in a branded batch are a recall risk.
• Print proof review: artwork is correct against the approved template, QR size and contrast meet specification (minimum 2 cm, 4 mm quiet zone, WCAG AA contrast), action copy is readable at 40 cm under warm lobby lighting. Dye-sublimation and variable-data print runs sometimes drift between batches; the proof review is the gate that catches drift.
• Staff rehearsal: at least two staff members tap and scan a pilot card and demonstrate the flow from end to end, including the 'customer arrives at the review composer' screen. If a staff member cannot complete the flow themselves, they cannot coach a customer through it when the time comes.
• Decision: if any check fails, do not place the full print order. The cost of re-printing is much higher than the cost of fixing the setup before scale. A 5,000-card reprint can run into five-figure territory once substrate, variable data, laminate and logistics are counted. The checklist is the cheapest insurance available in the entire programme.
• Post-launch verification: within 72 hours of cards arriving at the first location, the programme owner verifies a random sample of 10 cards from the batch. Cards that fail to tap or scan are logged; patterns in the failures (specific batches, specific locations, specific chip types) get escalated to the vendor for root-cause analysis before the next print wave.

FAQ