Footer columns — what should each one contain?

Themes & Design
, ,
1

My footer feels like an afterthought. Standard 4-column layout but I haven’t really thought through what goes in each column. What’s the conventional structure that customers expect?

2

Standard ecommerce footer structure (4 columns, plus a top mini-section):

Top row (above the columns): newsletter signup. Single email field, clear CTA, ~30 words explaining benefit. Most-engaged footer element.

Column 1 — Shop:

  • Browse all products
  • Featured collections (top 3-4 collections)
  • Best sellers
  • New arrivals
  • Sale

Column 2 — Help:

  • Contact us
  • Shipping & delivery
  • Returns & exchanges
  • FAQ
  • Size guide (if relevant)

Column 3 — About:

  • About us
  • Our story / journal / blog
  • Press / In the media
  • Sustainability (if relevant)
  • Careers (if you hire)

Column 4 — Connect:

  • Social media icons (Instagram, TikTok, Pinterest — whichever you actually use)
  • Customer service hours
  • “Get help” CTA

Bottom row (below the columns):

  • Copyright notice + year (auto-updated by the theme).
  • Legal links (Privacy, Terms, Cookie policy, Accessibility statement).
  • Payment method icons (Visa, Mastercard, PayPal, etc.) — small reassurance signal.
  • Company registration info (legally required in UK and parts of EU).
  • Optional: built-on credits, “Made with [tools]” if you like.

Why this layout:

  • Customer needs are predictable: they’re looking for product info, help info, brand info, or to follow you. Four columns cover those.
  • Search engines like footers with relevant internal links — they help with site structure understanding.
  • Some legal disclosures (registered company info, payment methods) belong in the footer rather than cluttering the main content.

What NOT to put in the footer:

  • Marketing fluff (“Inspiring confidence through quality” — yawn).
  • Repeated brand statements that are already on your About page.
  • Walls of small text that nobody reads (terms-of-service excerpts, etc. — those go on dedicated pages).
  • Excessive social proof (testimonials in footers feel like begging).

Mobile collapsing: on mobile, the 4 columns stack into accordions (collapsed by default). Customers tap to expand. This keeps the mobile page short while preserving the structure.

One tactical tip: include a mailto: link in the Help section (“Email: support@yourshop.com”). Sometimes customers want direct email, not a form. The mailto link converts those customers; without it, they sometimes leave to search for your email elsewhere.

3

Want to amplify the Cloudflare observation @melisa_dimitrov mentioned a few posts up. We’ve seen this enough times that it deserves a quick recap:

If you have your storefront behind Cloudflare with the orange-cloud (proxy) enabled, Cloudflare adds another layer of caching on top of ours. Their cache defaults are pretty aggressive for static-looking responses, and the rules around what they consider cacheable vs. dynamic are heuristic-based.

Two interventions help:

  • Cloudflare page rules: explicitly mark /api/* and any dynamic paths as Cache Level: Bypass. The API responses should never be cached at the Cloudflare layer; we set appropriate Cache-Control headers but Cloudflare doesn’t always respect them.
  • Cache rules for HTML responses: if you’re caching HTML pages, set a short edge TTL (5-60 seconds is reasonable for storefront pages, longer for blog/content pages) and make sure to purge the cache when you make admin changes. There’s a Cloudflare API endpoint that purges by URL — call it from an admin webhook handler for changes that need immediate propagation.

We’ve documented this in the “Cloudflare integration” section of the docs; happy to expand if anyone wants a specific setup walkthrough.

4

Wrapping up my end of this — we’ve been running with the suggested setup for footer layout for three weeks now and the results have been measurable. Specifically: 12% increase in the metric we were optimising, 0 customer complaints (where previously we’d get 1-2/week), no operational overhead added to my team’s daily routine.

I’d recommend this setup to anyone in a similar position. The only caveat I’d add is: do the initial test against a single product or a single customer segment before rolling out broadly. We had one rough day where a misconfigured variant produced a weird checkout experience for a handful of customers, and limiting the blast radius of the test would have caught it before it shipped widely.