WooCommerce CRO Technique

How to add address autocomplete and postcode lookup to WooCommerce checkout

Add predictive address search to WooCommerce checkout, then validate the result without breaking native browser autofill or trapping valid edge-case addresses. It helps most when mobile or guest users are spending too long in the shipping/contact step, when postcode and address-entry errors are common, or when fulfilment teams are correcting avoidable address mistakes after the order is placed.

Summary

Bottom Line: On modern WooCommerce, the cleanest route is to use the native address-autocomplete provider architecture introduced in WooCommerce 10.3 and plug in a compatible provider such as Google Places or a postcode-lookup provider.

  • Since WooCommerce 10.3, core checkout can work with address-autocomplete providers in both the classic shortcode checkout and the Checkout Block; you no longer have to build a separate checkout UI just to support autocomplete.
  • If you want a near-native no-code route, Woo’s Universal Address Autocomplete extension exposes providers such as Google Places, Ideal Postcodes, Fetchify, PostcodeSoftware and Loqate from WooCommerce → Settings → Advanced → Address Autocomplete, then enables predictive search from WooCommerce → Settings → General.
  • Browser autofill is separate from Google or postcode lookup. It depends on correct autocomplete values plus stable name and id attributes, so a careless checkout rebuild can make autofill worse even if address suggestions appear.
  • Do not replace the whole address form with one opaque search box. Baymard found that when suggestions fail, many users fall back to manual entry; in one study, 69% manually completed the address when lookup did not return the right match.
  • Autocomplete is not the same as deliverability validation. Google’s own checkout guidance separates Place Autocomplete from Address Validation, and recommends “Fix”, “Confirm”, or “Accept” logic rather than a hard reject loop.

How To Implement

  • Choose the WooCommerce checkout surface first

    If you are on native Woo checkout, WooCommerce 10.3 introduced provider-based address autocomplete for both shortcode and block checkout. If you are on the Checkout Block, remember that older legacy field hooks are not the extension path: WooCommerce explicitly notes that previous checkout_fields patterns do not apply in the new block checkout, and extensions that render extra checkout markup usually need block-specific integration.

  • Use the native no-code route when possible

    Install Universal Address Autocomplete, then go to WooCommerce → Settings → Advanced → Address Autocomplete, enable one or more providers, enter credentials, save, and then go to WooCommerce → Settings → General and tick Enable predictive address search. If you enable multiple providers, set the preferred one there too. This is the most future-friendly route for stores that want native checkout rather than a separate builder.

  • Pick the provider by address problem, not brand familiarity

    If you need broad international suggestion coverage, Google Places is the obvious candidate inside the Woo extension stack. If the buyer’s expectation is specifically UK postcode lookup, use a provider with explicit UK postcode support such as Ideal Postcodes, Fetchify or PostcodeSoftware in Universal Address Autocomplete, or the older WooCommerce Address Validation extension with UK postcode providers from WooCommerce → Settings → Address Validation. Woo’s older Address Validation extension also notes compatibility with Cart & Checkout Blocks as of WooCommerce 10.8.

  • If you need custom Google integration, build it on Woo’s provider API rather than hacking field replacements

    WooCommerce’s developer docs show the server-side provider registered through woocommerce_address_providers, and the client-side provider registered with window.wc.addressAutocomplete.registerAddressAutocompleteProvider(...). The client search function receives the query, country and address type, and the selected result must return Woo field names such as address_1, address_2, city, state, postcode and country. Woo also recommends only loading the JS on checkout and only when address autocomplete is enabled.

  • Use Google’s newer autocomplete stack on new builds

    Google documents that legacy google.maps.places.Autocomplete is not available to new customers from 1 March 2025 and recommends PlaceAutocompleteElement instead. Google’s newer widget also adds better localisation, accessibility and mobile support. If you are reviewing an older Woo plugin or theme snippet that still depends on the legacy widget, flag that as a technical-debt item before rollout.

  • Pair autocomplete with postal validation logic if address quality matters downstream

    Google’s ecommerce guidance recommends a three-part flow: capture with autocomplete, validate with the Address Validation API, then handle outcomes as Fix, Confirm, or Accept. Critically, Google also says you should let the customer proceed even if validation is imperfect, ideally flagging the order for review rather than trapping them in an infinite loop; that matters for unusual but valid addresses and new-build addresses that may not yet exist in postal datasets. Measurement note: instrument custom events such as address_lookup_used, address_validation_fix, address_validation_confirm, address_force_proceed, and address_manual_override before you switch the feature on sitewide.

  • Preserve native browser autofill deliberately

    Keep the standard Woo address fields present and editable, do not set autocomplete="off" on normal address inputs, and preserve browser-readable HTML semantics. web.dev recommends appropriate autocomplete values plus stable name and id attributes, and explicitly notes using prefixes like shipping postal-code and billing postal-code when the form contains both address types. If you add extra fields in the Checkout Block, Woo’s Additional Checkout Fields API supports the autocomplete attribute directly; for classic shortcode checkout, you alter fields via woocommerce_checkout_fields or woocommerce_default_address_fields, but those hooks are shortcode-specific.

  • Keep manual entry fallback visible

    Baymard’s research is blunt here: best-performing address lookup still keeps all address fields visible, because users often need to correct or complete the address manually. In the Checkout Block editor, the Checkout Fields block lets you control visibility for Company, Address Line 2 and Phone under Address Fields. For classic checkout, avoid theme or plugin customisations that collapse the whole address into a single search field.

  • Debounce search, but delay blocking validation until the customer finishes the step

    Search suggestions can appear while typing, but blocking validation should wait until the user has selected a suggestion, left the field, or pressed Next / Continue / Review Order. Baymard warns against premature validation before the user has had a chance to complete the field, and NN/g calls early error display a hostile pattern. If you use Woo’s Universal Address Autocomplete extension, it exposes universal_address_autocomplete_search_delay, which defaults to 300ms after the user finishes typing before the API request is made.

  • If you already run a builder checkout, configure inside that builder instead of core Woo settings

    FunnelKit documents Google Address Autocomplete under its checkout global settings and Google Maps section, while CartFlows documents setup under CartFlows → Settings → Integrations and then a per-checkout-step toggle inside the Checkout Form settings. Treat these as builder-specific routes, not native Woo checkout settings.

How To Measure

Key KPI: address-step completion, read as the rate from begin_checkout to add_shipping_info for users who reach checkout. Google defines add_shipping_info as the event that signifies a user has submitted shipping information in an ecommerce checkout process, which makes it the right anchor for the shipping/contact step. Use a GA4 Funnel exploration to compare begin_checkout → add_shipping_info → purchase, segmented by device category, country, logged-in vs guest, and ideally provider used vs manual entry.

Secondary metrics: median field-completion time from first interaction in the shipping/contact step to add_shipping_info; validation-error rate using custom events such as address_validation_fix or field-error events; invalid-address rate as the share of orders that required force-proceed or post-order correction; mobile drop-off at the address step; and downstream delivery-failure rate from fulfilment or support logs. web.dev’s autofill guidance is especially useful here because it lets you distinguish autofilled, autofilled-then-modified, only-manual, and empty states per field, which helps you detect when a new autocomplete rollout accidentally pushes more users back into manual entry.

What success looks like: more users reaching add_shipping_info and purchase, shorter address-entry time, fewer validation prompts, and fewer orders flagged for address correction, without a drop in autofill usage or a spike in manual overrides.

Guardrail metrics: RPV, overall conversion rate, checkout completion, AOV, the share of fields in only-manual or autofilled-then-modified state, and checkout-page LCP / INP / CLS. Core Web Vitals remain Google’s user-experience metrics for loading, responsiveness and visual stability, so extra third-party scripts on checkout should not be allowed to worsen them.

Pitfalls

  • Myth: “Autocomplete means the address is validated.” It does not. Google separates Place Autocomplete from Address Validation, and Woo’s provider architecture can return suggested addresses without proving postal deliverability.
  • Hiding all standard fields behind one search input. Baymard found this fails when the suggestion list misses the desired address, because users then need conventional fields to finish the job manually.
  • Over-aggressive validation while the customer is still typing. Baymard says input should not be checked before the user has had a chance to type a correct value, and NN/g warns against prematurely displaying errors.
  • Breaking native browser autofill by changing field semantics. web.dev recommends correct autocomplete values and stable field names/IDs; replacing standard inputs with opaque custom UI or turning autofill off on normal address fields can quietly raise friction.
  • Trapping unusual but valid addresses. Google explicitly recommends a force-proceed path after repeated validation failures, and W3C’s international-address guidance warns against strict format assumptions because countries vary widely, some do not use postcodes, and address order can differ.
  • Using an older Google autocomplete widget on a new build. Google recommends the newer PlaceAutocompleteElement; legacy google.maps.places.Autocomplete is not available to new customers as of 1 March 2025.

Examples

FAQs

Sources & Further Reading

Want us to implement this for you?

We run measured CRO consultancy for WooCommerce. If you want help prioritising, testing & implementing these improvements, tell us about your store.

Book Pilot

About This Page

  • Written By: Eliot Webb – Founder & WooCommerce CRO Consultant
  • Last Reviewed: 5 Jun 2026
  • Last Updated: