DEV Community: Peakxel Studio

How We Structured Peakxel Studio's Site Architecture (and Why We Added FAQs Everywhere)

Peakxel Studio — Fri, 28 Aug 2026 21:13:07 +0000

How We Structured Peakxel Studio's Site Architecture (and Why We Added FAQs Everywhere)

When we rebuilt Peakxel Studio's own site on Next.js, we didn't just design pages —
we designed a tree. Every page has a clear parent, a clear purpose, and a clear path
back to the homepage. No orphan pages, no dead ends, no pages that exist only for a
sitemap entry. Here's how it's structured, why we built it this way, and why it
matters for both traditional SEO and the newer world of AI answer engines (GEO).

Why a "tree" instead of a flat site

A lot of small business sites are flat: a homepage, a handful of pages linked from
the nav, and everything else buried or missing entirely. That works for a five-page
brochure site. It falls apart the moment you have real depth — multiple services,
multiple locations, a blog, a portfolio.

A tree structure means every page sits under a logical parent:

Homepage
├── Services (hub)
│   └── Individual service pages
├── Areas We Serve (hub)
│   └── State → City-specific pages
├── Blog (hub)
│   └── Individual articles
└── Portfolio (hub)
    └── Individual case studies

This isn't just tidy — it's functional. It means:

Crawlers can find everything through consistent, predictable internal links, not just a sitemap file
Topical authority concentrates. A hub page like /services passes relevance and link equity down to its children, and children link back up, reinforcing the hub
Users (and AI models) can reason about the site's structure just from the URL path — areas-we-serve/colorado/loveland-web-design-seo tells you exactly what that page is before you even click it

Homepage → Services → Specific Service

Our services hub branches into individual,
dedicated pages for each offering. We made a deliberate choice here: no vague
"what we do" blurbs on the hub page with details buried in a PDF or a contact form —
every service gets its own full page, its own URL, its own content built around what
someone searching for that specific service actually wants to know.

The service pages currently live under this branch:

That's 15 individual service pages, each targeting a distinct search intent instead
of competing with each other for the same broad keyword. A visitor searching
specifically for "technical SEO" lands on a page built for that, not a general
services page that half-answers everything.

Homepage → Areas We Serve → Specific Location

Same branching logic, applied geographically. Areas We Serve
sits under the homepage and branches into Colorado
as the state-level hub, which then branches into city-specific pages built for the
towns we actually work in — not auto-generated location pages with the city name
swapped in, but pages built around the actual local market:

This three-level depth (Areas We Serve → Colorado → City) also leaves room to
expand into additional states later without restructuring anything — the tree
already has the shape for it.

Homepage → Blog → Specific Article

Our blog isn't a catch-all content dump. Every
post is written to support a specific service or answer a question our clients
actually ask us before or during a project:

Each article also links back to the relevant service page it supports — the
Next.js/SEO article links to our Next.js Development and Technical SEO service
pages, for example — so the blog isn't a dead-end branch. It feeds authority back
into the commercial pages that actually convert.

Homepage → Portfolio → Case Study

Every entry in our portfolio is a real
project with its own dedicated case study page — not a thumbnail in a gallery grid
with no depth behind it:

Each case study page is also an opportunity to demonstrate the specific services
used on that project, so portfolio pages link back into the services tree too —
reinforcing the same hub pages from a different direction.

Why we added FAQs across the site

Beyond the tree structure itself, we've been rolling out structured FAQ content
across service, location, and resource pages. The reasoning is twofold:

For human visitors — FAQs answer the real, specific questions people have
before they ever fill out a contact form: pricing structure, timelines, what's
included, how support works after launch. Answering these upfront reduces
friction and builds trust before the first conversation even happens.
For AI answer engines (GEO) — This is the newer piece. Tools like ChatGPT,
Google's AI Overviews, and Perplexity increasingly pull direct answers from
structured, clearly-labeled Q&A content rather than long-form prose buried in
paragraphs. A page with a clean question-and-answer format is far easier for
these systems to extract and cite than a page where the same information is
scattered across marketing copy.

A clean site tree gives search crawlers a logical, discoverable path through the
site. Clear FAQ content gives both search engines and AI models direct, quotable
answers once they get there. The two reinforce each other — structure gets you
found, FAQs get you cited.

The takeaway

If you're rebuilding or restructuring your own site, this hierarchy — one hub
page, category pages beneath it, and specific leaf pages at the bottom, each with
its own URL and its own clear purpose — is the simplest model to copy. It scales
cleanly as you add more services, more locations, more content, without ever
turning into a flat pile of disconnected pages.

Happy to talk through how this applies to your own site:
peakxelstudio.com.

Baking Local SEO Into a Next.js Site (Instead of Bolting It On Later)

Peakxel Studio — Wed, 15 Jul 2026 09:30:40 +0000

Most local SEO advice treats it as something you add after a site is built — a plugin, a meta tag pass, maybe some schema markup squeezed in before launch. That approach usually shows.

Here's what I've learned building location-based pages for a Next.js agency site, and why structuring for local search from day one saves a lot of rework later.

The problem with bolting it on

A generic "Locations" page with a list of cities doesn't do much for search. Each location needs to genuinely stand on its own — its own route, its own metadata, its own structured data, and real content that's actually specific to that place, not templated filler with the city name swapped in.

What actually worked

For each location page, we made sure to nail down:

Dedicated dynamic routes per city (/areas-we-serve/colorado/[city]) rather than query params — better for both crawlability and clean URLs
Unique <title> and meta description per page, written for that specific location, not a shared template
LocalBusiness / Service schema (JSON-LD) scoped to each page, not just a single sitewide Organization schema
Genuinely distinct body content — this is the one most people skip. Three example pages that follow this: our Fort Collins page, our Loveland page, and our Windsor page — same service, same company, deliberately different content because the local context is different.

Why this matters more now

With AI-generated search summaries increasingly deciding what gets surfaced before a user even scrolls, thin, templated location pages are getting easier for both search engines and AI systems to detect and deprioritize. Specificity isn't just a nice-to-have anymore — it's becoming the baseline for being found at all.

Curious how others are structuring location-based routing in Next.js — App Router dynamic segments, or a CMS-driven approach? Would love to hear what's worked for you.

Why Most Small Business Websites Fail at the Basics (And What to Do About It)

Peakxel Studio — Wed, 03 Jun 2026 18:15:09 +0000

I've been auditing small business websites in Fort Collins, Colorado for a while now. And the same problems keep showing up — not complex architecture failures, not exotic bugs. Just the basics, ignored.

This post is for developers who consult for small businesses, and for any business owner who wants to understand why their site isn't performing.

The tools I use for a quick audit

You don't need an expensive platform. These free tools cover 90% of what matters:

Google PageSpeed Insights — shows Core Web Vitals instantly
Screaming Frog — crawls for broken links, missing meta tags, and redirect issues (free up to 500 URLs)
WAVE by WebAIM — surfaces accessibility violations in one pass
Google Search Console — if the client gives you access

A thorough audit for a site under 50 pages takes about 90 minutes. Here's what I almost always find.

1. Images are destroying load speed

The single biggest performance killer on small business sites is unoptimized images. Hero images served at 3–4MB, no modern formats like WebP, no lazy loading on below-the-fold content, and missing width and height attributes that cause layout shift.

One image optimization pass routinely cuts load times in half. That alone is often the difference between ranking locally and not ranking at all.

2. No local schema markup

Almost no small business site has LocalBusiness structured data. This is free metadata you add to the page that tells Google exactly who you are, where you are, and what your hours are. It takes about 10 minutes to add and directly improves eligibility for rich results in local search.

3. Redirect chains and dead links from old redesigns

A site redesign happened a few years ago, old URLs were never properly redirected, and now there are chains of redirects — or straight 404s on pages Google still has indexed. Screaming Frog catches all of these in one crawl. The fix is a proper redirect map before any migration, which most agencies skip because clients don't ask for it.

4. Duplicate or missing meta descriptions

Meta descriptions aren't a direct ranking factor, but click-through rate is. A blank or auto-generated description on a local business homepage is leaving real organic traffic on the table. Each page needs a unique, location-specific description that tells the searcher exactly what they'll find.

5. No HTTPS — still

Still finding HTTP-only sites in 2026. Every major browser flags them as "Not Secure." Google has used HTTPS as a ranking signal for over a decade. Free SSL certificates are widely available. There is no excuse.

If you want to see what a complete local web audit looks like in practice, the team at Peakxel Studio has solid resources and a detailed breakdown of what Fort Collins web design and SEO requires in today's landscape.

6. Accessibility issues that create legal risk

ADA web accessibility lawsuits have increased significantly. At minimum, every site you ship should pass WCAG 2.1 AA. The most common failures are missing image alt text, form inputs without labels, insufficient color contrast, and interactive elements that aren't keyboard-accessible. Run WAVE before any handoff.

7. Mobile that's responsive but not actually usable

Responsive does not mean good mobile UX. I see sites that technically reflow on mobile but have tap targets that are too small to press, text that becomes unreadable at mobile widths, and fixed headers that eat up a third of the screen. Test on a real device, not just browser DevTools. The difference is significant.

Final thought

Most small business websites aren't failing because of bad engineering. They're failing because no one with technical knowledge has ever looked at them critically. A 90-minute audit and a plain-English report with a prioritized fix list can genuinely change the trajectory of a local business.

If you're a developer, this is one of the highest-value services you can offer. If you're a business owner in Colorado, start with Google PageSpeed Insights today — most issues it surfaces are fixable without a full rebuild.

How We Optimized a Next.js Website to Score 100 on PageSpeed Insights

Peakxel Studio — Wed, 20 May 2026 17:48:48 +0000

We recently optimized a client’s Next.js website that had terrible mobile performance despite looking visually great.

The main issues were:

oversized images
heavy animations
unnecessary JavaScript
blocking third-party scripts

Here are the 3 fixes that made the biggest difference.

Using next/image

Some images were over 2MB.

Switching to optimized WebP assets with Next.js image optimization improved loading speed immediately.

import Image from "next/image";

Lazy Loading Components

Several below-the-fold sections loaded instantly even when users never reached them.

Dynamic imports reduced the initial bundle size significantly.

const Testimonials = dynamic(() => import("./Testimonials"));

Delaying Third-Party Scripts

Analytics and chat widgets were hurting performance badly.

Using lazy loading for non-essential scripts reduced Total Blocking Time almost completely.

Final Results
Metric Before After
Mobile Score 61 98
Desktop Score 82 100
LCP 4.8s 1.3s

Most Next.js performance issues are not caused by the framework itself — they usually come from bad asset optimization and unnecessary JavaScript.

We now use this workflow in our production builds at https://peakxelstudio.com/