Cut and reorder WooCommerce checkout form fields to reduce abandonment

How To Implement

• 1 Identify the live checkout architecture before touching fields

  In WooCommerce, classic and Blocks behave differently. Official Woo docs state that some field customisation guidance applies only to the shortcode checkout, while the Checkout block has its own APIs and editor controls. New stores started after WooCommerce 8.3 use Cart & Checkout Blocks by default, and established stores can still be on the classic shortcode checkout or can be transformed back to it. Check the live checkout page in Pages or Appearance → Editor, confirm whether it contains a Checkout block or a Classic Shortcode placeholder, and document that first.

• 2 Baseline the current checkout before cutting anything

  Record current checkout completion, mobile checkout completion, order errors, and whether any field is actually used in fulfilment. In GA4, make sure begin_checkout, add_shipping_info, add_payment_info, and purchase are flowing cleanly before you change the form, because those events populate the ecommerce reports and funnel work. If you want field-level analysis, add custom events or parameters now and register the ones you need as custom dimensions or metrics before the test starts.

• 3 Cut fields in the right order: remove what is truly low-value, then hide what is occasionally useful

  For most B2C stores, start with billing_company and shipping_company, billing_address_2 and shipping_address_2, and order_comments. Baymard’s research specifically recommends hiding uncommon optional inputs such as address line 2 behind a link rather than forcing everyone to scan past them, and WooCommerce core already treats company and address line 2 as visibility-controlled address fields. Keep phone only if there is a real operational reason, such as carrier delivery contact, customs, fraud review, or customer-service recovery. The UK GDPR data-minimisation principle points the same way: collect what is necessary for the purpose, not more.

• 4 Reorder the remaining fields to fit the customer’s task, not your database

  Put email and name early, keep street address, town/city, postcode, and country in a predictable address sequence, and push rare extras later or behind progressive disclosure. Baymard recommends minimising visible fields and using a single “Full name” field where possible, but international name and address formats vary widely, so do not force a rigid UK-only structure if you ship internationally. WooCommerce also localises address requirements and priorities by country, which is why you should be careful about hard-coding field order or validation logic globally.

• 5 For classic shortcode checkout, use the correct Woo hooks and filters

  Use woocommerce_checkout_fields to remove or relabel checkout fields such as order_comments, and to change field order via field priority. Official Woo docs explicitly show unset( $fields['order']['order_comments'] ) as the pattern for removing order notes. When you need to alter core address-field defaults that Woo loads per country, use woocommerce_default_address_fields; Woo’s own docs call this out for fields such as first_name, last_name, company, address_1, address_2, city, state, and postcode. Put the code in a child theme or a snippets plugin, not a parent theme. If a Woo checkout field editor extension is active, Woo notes that it can override custom field code.

• 6 For classic checkout, preserve or improve field semantics while you edit

  WooCommerce core already sets billing_phone to type="tel" and billing_email to type="email", and it assigns autocomplete tokens such as given-name, family-name, address-line1, address-line2, postal-code, email, and tel. If you relabel or recreate fields, keep those semantics. Google’s form guidance recommends type="email" for email, type="tel" for phone, and avoiding type="number" for values such as phone numbers or payment numbers; for numeric-but-not-mathematical input, use text plus appropriate mobile hints instead.

• 7 For Cart & Checkout Blocks, use the editor and block APIs, not classic snippets

  Official Woo docs are explicit that classic checkout hooks and filters are not supported in the block checkout for core field rendering. To control core address-field visibility in the Checkout block, edit the checkout page, select the Checkout Fields block or linked Shipping Address settings, and use Address Fields in the sidebar to toggle Company, Address Line 2, and Phone, and to control whether address and phone are required. If you want to remove order-notes behaviour, note that woocommerce_enable_order_notes_field does not affect the Checkout block; Woo’s hook-alternatives doc says the block must be removed in the editor.

• 8 For block checkout custom fields, use the Additional Checkout Fields API or a plugin that is genuinely block-compatible

  Woo’s Additional Checkout Fields API supports custom fields in three locations — contact, address, and order — and fields saved there are stored to the customer, order, or both depending on location. The official API currently supports text, select, and checkbox field types, and it supports attributes such as autocomplete, autocapitalize, pattern, title, maxLength, and readOnly. If you need no-code field controls, verify plugin compatibility with Blocks before implementation: Woo says extension compatibility is product-specific; ThemeHigh’s WordPress.org listing currently claims classic and block checkout support, but its block support is narrower than its classic support, with block customisation limited to a smaller field-type set. CartFlows documents field editing in CartFlows → Funnels → [Checkout step] → Checkout Form → Field Editor. FunnelKit’s own documentation is vendor evidence and should be treated as such.

• 9 Use conditional visibility instead of blanket removal when the field is only needed in some cases

  If a field is relevant only for local pickup, fragile goods, B2B orders, or particular countries, hide it until the condition is met instead of showing it to everyone. Woo’s current tutorial for conditional visibility in additional checkout fields requires WooCommerce 9.9.0 or later. That is usually better than forcing every shopper through an irrelevant field.

• 10 Handle full name with caution

  Baymard and GOV.UK both support a single full-name field in many user-facing contexts because names do not always fit a Western first-name/last-name model, and a single field reduces perceived work. However, WooCommerce core address fields and customer/order schemas still store separate first and last names. That means a full-name field is only safe if you have tested how orders, exports, labels, invoices, emails, and external systems consume first_name and last_name. The safest route on stores with downstream dependencies is often to keep split fields and optimise them, not to merge them visually.

• 11 Re-check version-specific behaviour after WooCommerce upgrades

  In WooCommerce 9.6, Woo changed block checkout field-visibility settings for phone, company, and address line 2 so they are stored globally and used across blocks, shortcodes, My Account, and the Store API. Woo’s advisory also notes different defaults: block checkout defaults are optional phone, optional address 2, and hidden company, while shortcode defaults are required phone, optional address 2, and optional company. After upgrading, visually verify the live checkout, not just the editor.

• 12 Keep custom save and order-meta logic HPOS-safe

  If you add or transform checkout data, use WooCommerce CRUD methods and official object APIs. Woo’s HPOS guidance says CRUD-based interactions continue to work as expected, while direct assumptions about posts and postmeta are the riskier path. That matters if you are saving derived values from merged fields or custom block fields.

How To Measure

Pitfalls

• Myth: fewer fields always means a better checkout. It usually helps, but only if you remove fields that are genuinely unnecessary. If you remove data your carrier, customs flow, or fulfilment team needs, you can improve frontend completion and still damage delivery success or operational cost.
• Classic snippets do not fix block checkout. Many stores waste time adding woocommerce_checkout_fields code to a Checkout block and then wonder why nothing changed. Woo’s block docs and hook-alternatives docs are clear that classic field hooks are not supported for block core fields.
• Removing address fields globally can backfire internationally. Address formats vary widely by country, and WooCommerce already changes address-field behaviour by locale. Do not assume UK-only rules if you ship abroad.
• A single full-name field is not a free lunch. It can reduce friction, but reliable automatic splitting is hard, and WooCommerce plus downstream systems still expect separate first and last names.
• Do not use type="number" for phone numbers or similar identifiers. Google’s form guidance explicitly warns against that for data such as telephone or payment card numbers; use tel or text with the right mobile hints instead.
• Do not judge success on conversion alone. If field cuts increase checkout completion but also increase address-quality errors, failed shipments, or manual order fixes, the change did not really improve the checkout.

Examples

FAQs

Sources & Further Reading

• Checkout Optimization: 5 Ways to Minimize Form Fields in Checkout – Baymard’s current benchmark for average vs lean checkout field and form-element counts, plus specific reduction tactics such as full name and hidden address line 2. Date: 26 June 2024.
• Reasons for Cart Abandonment — Why 70% of Users Abandon Their Cart – Baymard’s current abandonment-reason benchmark, including checkout that feels too long or complicated. Date: 14 January 2025.
• Checkout UX Best Practices 2025 – Current Baymard guidance on hiding uncommon optional inputs such as company and address line 2. Date: 25 November 2025.
• Usability Testing of Inline Form Validation: 31% Don’t Have It – Useful for the field-error guardrail and why error recovery should improve alongside field reduction. Date: 9 January 2024.
• Customizing checkout fields using actions and filters – Official Woo developer doc for classic shortcode checkout, including woocommerce_checkout_fields, woocommerce_default_address_fields, and the order_comments removal example. Last updated: 3 June 2026.
• Additional checkout fields – Official Woo developer doc for block checkout custom fields, supported locations, field types, and attributes. Last updated: 3 June 2026.
• Hook alternatives – Official reference showing which classic cart and checkout hooks are not supported in Cart & Checkout Blocks. Date: Undated in page chrome; accessed 3 June 2026.
• Checkout block – Official merchant doc showing the Checkout block’s Address Fields controls for company, address line 2, and phone. Date: Undated in page chrome; accessed 3 June 2026.
• Developer advisory: Block Checkout field entities – Important version note on WooCommerce 9.6 global field-visibility behaviour and differing block vs shortcode defaults. Date: 16 January 2025.
• WooCommerce Code Reference: WC_Countries::get_default_address_fields() – Source of WooCommerce’s default address fields, types, autocomplete tokens, and visibility logic for company, address line 2, phone, and email. Generated: 28 May 2026.
• Measure ecommerce – Official GA4 ecommerce event implementation guide. Date: 4 May 2026.
• Set up event parameters – Official GA4 guidance on registering event parameters as custom dimensions or metrics for reporting. Date: 4 May 2026.

About This Page

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