Layer3 is a Wellington managed IT and security provider. Their site had grown page by page, and several of its dynamic sections only half worked. We rebuilt it as a structured WordPress site in Breakdance, with ACF Pro modelling every piece of content that repeats. Staff, partners, offices, downloads and case studies are now records the team edits in the WordPress admin, and the pages rebuild themselves.
Structured with ACF Pro
Every content type on the site is an ACF-registered custom post type, so they all live in one admin screen: team members, partners, customers, downloadable resources, case studies, notices and locations. Seven post types sit alongside their field groups and two ACF options pages for site-wide settings. Each section follows the same pattern:
- Custom post type holds the records.
- ACF field group gives each record its structure.
- Breakdance card block lays out one record, bound to its fields.
- Loop queries the records and repeats the card on the page.
Adding a partner, a staff member or an office is data entry, not page editing.
The team
The About page shows the team in two groups, leadership and the wider team, each driven by its own loop over the same card. Each person has a name, role, photo, team, start date and display order. Two details are worth calling out:
- Ordering is numeric on purpose. The builder’s own field ordering sorts as text, so 100 would sort before 20 the day a tenth person joins. The loops use a numeric meta query instead, and display order goes up in tens so someone can be slotted in without renumbering.
- “Years at Layer3” is computed, never stored. A small must-use plugin derives it from the start date whenever the field is read, so it can’t go stale on an anniversary and needs no scheduled job. It reads “12 years at Layer3”, “Joined 2026” for anyone under a year, and disappears entirely when no date is set. The field is read-only in the admin, and the plugin keeps ACF’s internal reference in place so the value also works anywhere else on the site that reads the field by name.
Locations: 14 pages, three kinds
The biggest ACF build. Layer3 has three offices, a set of areas covered under their service agreement, and places they’ll travel to by arrangement. Pages like these easily become thin, near-identical location pages, which search engines penalise, so the three kinds are deliberately different in structure, not just in wording:
- A
location post type with a location-type taxonomy whose only job is to choose which of three templates a page uses.
- A 19-field group with shared fields (lead copy, the clients served there, related services, up to four industry notes in a repeater) and per-kind fields: street address, coordinates, hours and maps link for offices; coverage and on-site basis for service areas; arrangement and remote scope for the rest.
- Relationships between records. Each area points at the office that covers it, links to real customer records and to the service pages that apply. Templates reach across those relationships to show, for example, the covering office’s address on an area page.
- Nothing that can’t be backed up. There is deliberately no on-site response-time field, because Layer3 doesn’t promise one.
Partners
Each technology partner is a record with name, heading, description, logo and vendor URL, plus a link to the Layer3 service pages that use it. Partner pages show a “Where we use it” section looped straight off that relationship, and a partner without a vendor URL simply drops the outbound link. An earlier version stored a computed permalink through a custom plugin. It turned out to be fragile when pages were renamed or moved, so it was replaced with a native relationship query, and the plugin and its stored data were removed.
Structured data generated from the fields
Search engines get the same facts the pages show, generated from the ACF data rather than typed in by hand. A must-use plugin extends the SEO plugin’s schema graph, so the site keeps one connected graph:
- Offices are published as local businesses with full postal addresses and coordinates.
- Service areas are published as services with an area served and never an address. That asymmetry is the point: an area isn’t an office.
- Each office’s area served is built by looking up every location that points back to it.
- Opening hours are only published while the hours field still matches the confirmed hours. If someone edits them, that line drops out of the structured data instead of going stale.
- Articles get BlogPosting markup, and FAQ sections are turned into FAQPage markup automatically.
One detail says a lot about the approach. A hand-written first draft of the schema had an office postcode wrong. The ACF records had it right, and so did everything generated from them.
Gated downloads
The Resources library offers practical documents Layer3 uses itself, such as an SMB1001 Bronze to Gold guide and an AI operating policy written for New Zealand law. Each resource is an ACF record with an on/off switch, a display name, a standfirst, the file itself, a “require contact details” toggle and a “notify on update” toggle.
- Gated or open, per document. When contact details are required, the resource page shows a download form. Submitting it emails the team, stores the submission in WordPress, adds the contact to the Mailchimp audience, and opens the file straight away, all behind reCAPTCHA. When the toggle is off, the page shows a plain download button instead. The resource name carries through to the email subject, the stored record and the Mailchimp entry, so the team can see what was downloaded.
- Two inherited bugs fixed. The on/off switch had never actually hidden anything, because the listing didn’t filter on it. The gate never opened either: it tested whether a true/false field was empty, and “false” is stored as 0, which isn’t empty. The form always showed. Both now work, verified by flipping each switch on a live resource.
- Generated covers. Each document got a generated A4 cover in Layer3’s brand, built server-side with ImageMagick using the brand fonts. The text block is anchored from the bottom, so one-line and two-line titles sit in the same place.
Video
The home page and the Private Cloud Hosting page open on full-bleed hero video, edited and encoded for the web as WebM. The hero uses the builder’s native background-video layer, so headline and buttons sit cleanly over the footage. Video is held back on phones, where a still image stands in, to save data and battery.
Pizza Dodge
Not lead generation, just personality: a small arcade game hidden on the site. You move a pizza slice to catch toppings and dodge phishing, malware and ransomware. It’s a proper WordPress plugin rather than a script pasted into a page, with its own database tables, REST API and admin screen.
- Endless difficulty. Spawn rate, fall speed and the share of threats all ramp with play time and never plateau, so a round ends when you finally miss, not when a timer runs out. Collision checks the whole distance an item travelled in a frame, so fast items can’t pass straight through the paddle.
- Weekly and all-time leaderboards. The weekly board resets every Friday, and Settings → Pizza Dodge lets staff browse past weeks, remove entries and edit a blocked-initials list.
- Anti-cheat without logins. Each round gets a one-time session token. Every catch is reported to the server as it happens, and the server works out the score itself, so the browser never gets to claim one. A tester found a way to post a score without playing, and that’s what led to this design. Scores are also capped by what’s physically possible in the elapsed time, and submissions are rate-limited.
- Built for phones. Drag, arrow keys or tilt-to-move using the phone’s motion sensor, calibrated to however you’re holding it. The canvas stays sharp on high-density screens, motion effects respect reduced-motion settings, and a demo plays behind the start screen.
- Kept out of search, three independent ways, so it stays an easter egg.
Results
- Rebuilt in August 2026: About and the team, case studies, locations, resources, partners, and the service pages, including Private Cloud, Azure and Microsoft 365.
- Full SEO audit of all 128 published URLs. Afterwards every title was under 60 characters, every description between 120 and 160, every page had exactly one H1, and every page carried valid structured data.
- Structured data on every page: the organisation and its address on all 128, plus local-business markup for 3 offices, BlogPosting for 57 articles and FAQPage on 20 pages.
- Internal links to the office pages rose from 2 to between 4 and 6 each.
- A strict design system: one self-contained style family per page type, zero border radius, no shadows, no gradients.
