Techwave Documentation

Introduction

Everything you need to know before you open your editor — what’s in the box, what it’s built with, and what it expects from your machine.

Welcome

Thanks for picking up Techwave, a multi-page Astro theme for IT service companies, help desks, and SaaS support teams. This guide walks through installing the template, understanding how the project is organized, customizing content and styling, and shipping it to production. It’s written for developers who are comfortable with the command line but new to this specific codebase — if you already know Astro well, feel free to skip ahead using the sidebar.

What’s Included

Features

• Home, Features, Solutions, Why Choose Us, Pricing, About, Careers, and Contact pages, plus Book a Demo, Sign In, Sign Up, Privacy Policy, Terms of Use, and a 404 page
• A full blog: a default blog page with a featured slider and sidebar, 11 more listing styles (Grid 1–5, Masonry, Gallery 1–3, Lateral, Listing), and author, category, tag, and post-format archives
• Five post formats (standard, gallery, audio, video, quote) with hero or classic headers, comments, related posts, and previous/next links — all written in Markdown content collections
• Mega menu, mobile drawer menu, search overlay, and a back-to-top button
• GSAP + ScrollTrigger scroll animations that respect prefers-reduced-motion, and Swiper sliders
• Monthly/yearly pricing table, tabs, accordions, count-up stats, and a lightbox
• Page copy, navigation, footer, pricing, testimonials, and form fields kept in plain JavaScript data files under src/data/
• Canonical URLs, Open Graph and Twitter card tags on every page, and an automatic sitemap

Technology Stack

Techwave is built with .astro components, plain CSS, and vanilla JavaScript — no UI framework, no CSS framework, and no TypeScript source files.

Requirements

Browser Support

The built site targets the last two versions of all evergreen browsers:

Getting Started

From a downloaded ZIP to a running dev server in five steps.

Installation & Extraction

1. Download the template ZIP from your purchase confirmation email or account downloads page.
2. Extract it to a folder on your machine — avoid folder names with spaces or special characters.
3. Open that folder in your terminal and in your code editor.

# Extract on macOS / Linux
unzip techwave-astro-package.zip
cd techwave-astro-package/techwave-astro

Node.js Setup

Check which version of Node.js is currently active:

node --version
# v22.12.0 or later

If you manage multiple Node versions, tools like nvm or fnm make switching painless:

nvm install 22
nvm use 22

Install Dependencies

From the project root, install packages with your preferred package manager:

npm install

pnpm install

yarn install

This reads package.json and downloads every dependency into a local node_modules/ folder. It only needs to be re-run when dependencies change.

Run the Development Server

npm run dev

pnpm dev

This starts Vite’s local dev server with hot module reloading — edits to components, pages, and styles appear in the browser immediately without a manual refresh. By default it’s available at http://localhost:4321; the terminal output will confirm the exact address.

Build for Production & Preview

# Compile an optimized production build into dist/
npm run build

# Serve that build locally to sanity-check it
npm run preview

build validates content collections, bundles and minifies assets, and writes static output to dist/. preview serves that exact output locally so you can verify it before deploying — it does not rebuild automatically, so re-run build after further changes.

Project Structure

A tour of the folders you’ll actually touch, and the ones you generally shouldn’t.

Configuration

The files that control how the project builds, and where to set site-wide values.

package.json

Defines dependencies and the scripts you run from the terminal (dev, build, preview). Add your own script here if you introduce a new tool.

{
  "name": "techwave-astro",
  "type": "module",
  "version": "0.0.1",
  "engines": { "node": ">=22.12.0" },
  "scripts": {
    "dev": "astro dev",
    "build": "astro build",
    "preview": "astro preview",
    "astro": "astro"
  },
  "dependencies": {
    "@astrojs/sitemap": "^3.7.4",
    "@fontsource/inter": "^5.3.0",
    "@fontsource/manrope": "^5.3.0",
    "@fontsource/outfit": "^5.3.0",
    "astro": "^7.3.5",
    "gsap": "^3.15.0",
    "sharp": "^0.35.5",
    "swiper": "^14.3.0"
  }
}

astro.config.mjs

Controls integrations, the deployed site URL, and build behavior. Techwave registers only the sitemap integration (the 404 page is left out of the sitemap) and turns off Astro’s dev toolbar. Replace the site value with your real domain before deploying — it is used for canonical URLs, Open Graph image URLs, and the sitemap.

// @ts-check
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

// https://astro.build/config
export default defineConfig({
  // Replace with the production domain; used for canonical URLs, OG images and the sitemap.
  site: 'https://techwave.example.com',
  integrations: [sitemap({ filter: (page) => !page.endsWith('/404/') })],
  devToolbar: { enabled: false },
});

tsconfig.json

The project’s source is plain JavaScript and .astro files; tsconfig.json only extends Astro’s strict preset so your editor understands Astro’s generated types. No path aliases are defined — imports use relative paths such as ../components/Header.astro.

{
  "extends": "astro/tsconfigs/strict",
  "include": [".astro/types.d.ts", "**/*"],
  "exclude": ["dist"]
}

Environment Variables (.env)

Techwave doesn’t read any environment variables out of the box, so no .env file is needed. If you add one later (for example for a form service key), create it in the project root. Variables must be prefixed PUBLIC_ to be readable in client-side code.

# Exposed to the browser — never put secrets here
PUBLIC_SITE_URL=https://example.com

# Server-only — safe for secrets, not readable in browser code
API_SECRET_KEY=your_secret_key

Pages

How routes are created, which pages ship with the template, and how the blog routes are generated.

Creating a New Page

Astro uses file-based routing: any .astro or .md file placed in src/pages/ automatically becomes a route matching its file path. Techwave ships these routes:

src/pages/index.astro                    →  /
src/pages/features.astro                 →  /features
src/pages/solutions.astro                →  /solutions
src/pages/why-choose-us.astro            →  /why-choose-us
src/pages/pricing.astro                  →  /pricing
src/pages/about.astro                    →  /about
src/pages/careers.astro                  →  /careers
src/pages/contact.astro                  →  /contact
src/pages/demo.astro                     →  /demo
src/pages/sign-in.astro                  →  /sign-in
src/pages/sign-up.astro                  →  /sign-up
src/pages/404.astro                      →  not-found page
src/pages/[legal].astro                  →  /privacy-policy, /terms-of-use
src/pages/[post].astro                   →  /<post-slug>  (one per blog post)
src/pages/blog/[...page].astro           →  /blog, /blog/page/2, …
src/pages/[listing]/[...page].astro      →  /grid … /grid-5, /masonry, /gallery … /gallery-3, /lateral, /listing
src/pages/author/[slug]/[...page].astro  →  /author/<slug>
src/pages/category/[slug]/[...page].astro →  /category/<slug>
src/pages/tag/[slug]/[...page].astro     →  /tag/<slug>
src/pages/type/[slug]/[...page].astro    →  /type/<format>  (post-format archive)

To add a page, create a new file in src/pages/ using the layout and structure of an existing, similar page as a starting point. Sections in src/components/sections/shared/ are designed to be dropped onto any page:

---
import Layout from '../layouts/Layout.astro';
import SectionIntro from '../components/sections/shared/SectionIntro.astro';
import CtaBand from '../components/sections/shared/CtaBand.astro';
import { cta } from '../data/home.js';
---
<Layout title="Services – Techwave" description="Managed IT services for growing teams.">
  <SectionIntro heading="Our Services" text="Everything your team needs, in one place." />
  <CtaBand {...cta} />
</Layout>

Editing an Existing Page

Page files in src/pages/ are short: they import section components and pass them data from the matching file in src/data/ (for example index.astro reads src/data/home.js, about.astro reads src/data/about.js). To change wording or images, edit the data file; to change layout or markup, edit the section component under src/components/sections/. Sections in sections/shared/ (pricing table, testimonials, CTA band, …) appear on several pages, so a markup change there affects all of them.

Dynamic Routes

Files wrapped in square brackets, such as [post].astro, generate multiple pages from a single template — here, one page per blog post, legal page, listing style, and archive. Astro requires a getStaticPaths() function for these on statically-generated sites. The single-post route reads the blog collection through a helper in src/utils/blog.js:

---
// Blog posts at /<slug>, one per Markdown entry in src/content/blog.
import PostLayout from '../layouts/PostLayout.astro';
import { getPosts } from '../utils/blog.js';

export async function getStaticPaths() {
  const posts = await getPosts();
  return posts.map((post) => ({ params: { post: post.id }, props: { post, posts } }));
}

const { post, posts } = Astro.props;
---

<PostLayout post={post} posts={posts} />

The blog listing styles (titles, posts per page, card layout) are configured in src/data/listings.js; adding an entry there adds a new listing route automatically.

Layouts

Layouts (in src/layouts/) wrap page content with shared structure — the <html> shell, <head> metadata, header, and footer. Every page renders inside Layout.astro via a <slot />; PostLayout and ArchiveLayout build on it for blog posts and archives. Simplified:

---
import '../styles/global.css';
const {
  title = 'Techwave – IT Solutions & Help Desk',
  description = 'Techwave helps businesses grow with managed IT, …',
  image = '/images/logo-dark.svg',
  header = {}, // Header variant props: { topbar, scheme, position, size }
  footer = true, // false on pages with their own minimal footer
} = Astro.props;
---
<html lang="en">
  <head><title>{title}</title> … </head>
  <body id="top">
    <BackToTop />
    <Header {...header} />
    <main id="main"><slot /></main> <!-- page content is injected here -->
    {footer && <Footer />}
  </body>
</html>

Page Metadata & the 404 Page

Pass a title and description into Layout on every page for correct browser tabs and search results (see also SEO); pages that omit them fall back to the defaults above. src/pages/404.astro is served automatically whenever no route matches.

Components

The building blocks pages are assembled from, and how data flows into them.

Reusable Components

Components live in src/components/ and encapsulate one piece of UI — a button, a post card, a navigation bar — so it can be reused across pages without copy-pasting markup. Every component in Techwave is an .astro file, organized in three groups:

Props

Props are the inputs a component accepts, similar to HTML attributes. Techwave components are written in plain JavaScript, so props are read by destructuring Astro.props, with defaults set right there and a comment at the top of the file describing the options. For example, the pill-shaped button used across the site:

---
// Large pill button; on hover the label slides up and a copy slides in from below.
const { href, label, tone = 'accent', size = 'lg', class: className, ...rest } = Astro.props;
---

<a href={href} class:list={['pill-btn', `pill-btn--${tone}`, `pill-btn--${size}`, className]} {...rest}>
  <span data-text={label}>{label}</span>
</a>

In plain language: href and label set the link and its text; tone and size are optional and pick a color/size modifier class (defaulting to accent and lg); any extra attributes (such as target) are passed straight through to the <a>.

Component Composition

Larger sections are composed from smaller components rather than written as one long block of markup. The home page, for example, is just a list of sections:

<Layout>
  <Hero {...hero} />
  <LogoSlider logos={homeLogos} />
  <SectionIntro {...intro} />
  <FeatureTabs tabs={featureTabs} />
  <FeatureRow {...liveChat} />
  <PaymentMethods {...payments} />
  <IconCards {...iconCards} />
  <RevenueStats {...revenue} />
  <BenefitsSlider {...benefits} />
  <PricingTable />
  <Testimonials />
  <CtaBand {...cta} />
</Layout>

Passing Data to Components

In Astro, props are passed the same way as HTML attributes and read via Astro.props. Most pages import an object from src/data/ and spread it into the section:

---
import PillButton from '../components/ui/PillButton.astro';
import CtaBand from '../components/sections/shared/CtaBand.astro';
import { cta } from '../data/home.js';
---
<PillButton href="/" label="Back to home" />
<CtaBand {...cta} tone="coral" />

Styling

Where to change colors, type, and spacing without fighting the build.

Global Styles & CSS Variables

Techwave is styled with plain CSS — no Tailwind or Sass. Site-wide values (color palette and font families) are defined once as CSS custom properties in src/styles/global.css, which Layout.astro imports on every page. Change a value here and it updates across the whole site:

:root {
  --color-primary: #171c47;    /* navy: headings */
  --color-secondary: #5d607e;
  --color-text: #63667f;
  --color-body: #57597a;       /* body copy */
  --color-accent: #e1534a;     /* coral: accent buttons, eyebrow labels */
  --color-white: #ffffff;
  --color-blush: #fceeed;
  --color-lavender: #f0e8fd;
  --color-mint: #e6f7f1;
  --color-sky: #e6eeff;
  --color-periwinkle: #e9ebf9;

  --font-heading: 'Manrope', sans-serif;
  --font-body: 'Satoshi', sans-serif;
  --font-button: 'Inter', sans-serif;
}

Component Styles

Astro components support scoped <style> blocks — CSS written there only applies to that component, so class names never collide across files. Almost all of Techwave’s layout CSS lives this way, at the bottom of each component file, and reads the shared variables:

<style>
  .pill-btn {
    padding: 17.5px 44px;
    border-radius: 50px;
    font-family: var(--font-heading);
    font-weight: 700;
  }
</style>

Responsive Design, Typography & Spacing

The heading scale (h1–h6, all Manrope 700) and the body text size are set in global.css, with smaller h1/h2 sizes below 767px. Each component’s scoped styles then adjust its own layout at the template’s breakpoints — 1366px, 1200px, 1024px, 880px, and 767px (max-width media queries). Prefer adjusting the shared values in global.css over overriding sizes on individual elements, so the site keeps a consistent rhythm as you edit it.

Images & Assets

Where the template’s images live, and how to swap them for your own.

Replacing Images

Swap the file in place (keeping the same filename), or put your file in public/images/ and update the path where it’s set. Most image paths, with their width and height, live in the data files under src/data/:

export const hero = {
  heading: 'IT Solutions That Keep Your Business Grow',
  // …
  art: {
    image: { src: '/images/home/hero.png', width: 597, height: 685 },
    // …
  },
};

Blog post images are set in each post’s front matter (image, listImage, and media) in src/content/blog/. If your replacement has a different aspect ratio, update the width/height values too so the page doesn’t shift while loading.

Supported Formats & SVGs

Images are rendered with plain <img> tags, so any format the browser supports works — the template ships PNG, JPG, and SVG files. UI icons are not image files: they are inline SVGs drawn by src/components/Icon.astro (see Fonts & Icons), so they inherit color via currentColor.

Image Optimization

Because images are served from public/, the build does not resize or re-encode them — compress your images (for example to WebP or optimized JPG) before adding them. The sharp dependency is only used at build time to read image dimensions for the blog list layouts.

Fonts & Icons

Swapping typefaces and icon sets without touching every component.

Fontsource Fonts (Manrope, Inter, Outfit)

Techwave loads no fonts from Google Fonts or any other CDN — every font is self-hosted. Manrope (headings), Inter (buttons), and Outfit (the About page’s story tabs) come from the Fontsource npm packages and are imported per weight. Manrope and Inter are imported in the shared layout:

import '@fontsource/manrope/400.css';
import '@fontsource/manrope/500.css';
import '@fontsource/manrope/600.css';
import '@fontsource/manrope/700.css';
import '@fontsource/inter/600.css';
import '@fontsource/inter/700.css';

To switch typeface, install its package (npm install @fontsource/<font>), replace these imports, and update the matching --font-heading / --font-button variable in src/styles/global.css. Outfit is imported directly in src/components/sections/about/StoryTabs.astro.

Local Fonts (Satoshi)

The body font, Satoshi, is self-hosted from public/fonts/satoshi/ (400, 500, and 700 weights) and declared with @font-face at the top of global.css. Layout.astro also preloads the 500 weight:

@font-face {
  font-family: 'Satoshi';
  src: url('/fonts/satoshi/satoshi-500.woff2') format('woff2');
  font-weight: 500;
  font-style: normal;
  font-display: swap;
}

If you replace Satoshi, update the @font-face rules, the --font-body variable, and the <link rel="preload"> path in Layout.astro.

Icon Libraries

No icon library is installed. UI icons are inline SVGs defined in one component, src/components/Icon.astro, which holds a small set keyed by name — chevron-down, search, close, arrow-up, envelope, mobile, link, clock, heart, and social icons (facebook, facebook-circle, instagram, linkedin, linkedin-in, twitter, x-twitter, pinterest, google, vimeo, whatsapp). Decorative illustrations and feature icons are image files in public/images/.

Replacing & Adding Icons

Use an icon by name; extra attributes (such as width, height, or class) pass through to the <svg>, and the icon inherits the surrounding text color:

<Icon name="envelope" width="16" height="16" />

To add an icon, open Icon.astro and add an entry to the icons object with the SVG’s viewBox and inner markup as body (set stroke: true for outline icons).

Content Editing

The fastest, lowest-risk way to make the site say what you want it to say.

Headings, Paragraphs & Buttons

Page text in Techwave lives in data files, not in the page markup. Open the file in src/data/ named after the page (home.js, features.js, solutions.js, why-choose-us.js, pricing-page.js, about.js, careers.js, contact.js, forms.js for demo/sign-in/sign-up), find the section, and edit the text between the quotes:

// before
export const hero = {
  heading: 'IT Solutions That Keep Your Business Grow',
  text: 'Partner with a trusted provider delivering managed IT, secure networks, and expert technical support.',
  button: { label: 'Explore Solutions', href: '/solutions' },
  // …
};

// after
export const hero = {
  heading: 'Help Desk Support Your Team Can Count On',
  text: 'Fast, friendly IT support for small and growing businesses.',
  button: { label: 'Book a call', href: '/contact' },
  // …
};

Keep the quotes and commas intact. If a piece of text contains an apostrophe, use a curly one (’) as the existing copy does, or wrap the string in double quotes.

Navigation & Footer

Menu links are kept in src/data/navigation.js and footer content (newsletter, tagline, social links, link columns, copyright) in src/data/footer.js, so you edit each label and URL once rather than hunting through every page. See Navigation for the full pattern.

Cards, Testimonials & Pricing

Repeating content blocks are driven by data rather than hand-written per card, so adding or removing an item is a matter of editing a list. Testimonials are in src/data/testimonials.js and the pricing plans (shown on every page with the pricing table) in src/data/pricing.js:

const features = ['Support', 'Free Updates', 'Custom Domain', 'Unlimited Storage', '12 Add-Ons'];

export const pricing = {
  heading: 'Plans and Pricing',
  periods: [
    { id: 'monthly', label: 'Monthly', plans: [plan('Free', '0'), plan('Basic', '19'), plan('Premium', '59', true), plan('Enterprises', '119')] },
    { id: 'yearly', label: 'Yearly', plans: [plan('Free', '0'), plan('Basic', '14'), plan('Premium', '39', true), plan('Enterprises', '109')] },
  ],
  // …
};

Each plan(name, amount, featured) call is one pricing card; the third argument highlights it. Change the shared features list, or the defaults inside the plan helper at the top of the file, to change what every card lists.

Blog Content & Contact Information

Blog posts are Markdown files in src/content/blog/, one per post, published at /<slug>. Edit the front matter and body directly; to add a post, copy an existing file and change its slug. The available front-matter fields are defined in src/content.config.js:

---
title: "A closer look at connected living"
slug: "a-closer-look-at-connected-living"
date: "2022-05-20T12:24:49"
excerpt: "Our most successful engagements have been …"
author: "techwave"        # key in src/data/authors.js
categories: ["Article", "Digital", "Technology"]
# also: updated, tags, image, listImage, likes,
# headerStyle ('hero' | 'classic'), format ('standard' | 'gallery' | 'audio' | 'video' | 'quote'), media
---

Authors are in src/data/authors.js, demo comments in src/data/comments.js, and the blog sidebar content in src/data/sidebar.js. The privacy policy and terms of use are Markdown files in src/content/legal/.

Contact details — office address, support email and phone, and social links — are in the enquiry.sidebar list in src/data/contact.js. Footer social links and the copyright line are in src/data/footer.js. The shipped email (hello@example.com) and phone number are placeholders; replace them with your own.

Navigation

Header, mobile menu, and footer links, in one predictable place.

Header Navigation

Primary nav links are defined as the primaryMenu array in src/data/navigation.js, so adding, removing, or reordering a link doesn’t require touching markup. An item with a mega object opens a mega menu (the “Pages” and “Blog” menus, whose link columns are defined higher up in the same file), and an optional badge adds a small colored label:

export const primaryMenu = [
  { label: 'Home', href: '/' },
  {
    label: 'Pages',
    href: '#',
    badge: { text: 'New', tone: 'lavender' },
    mega: { layout: 'links-promo', columns: pagesColumns, promo: { /* … */ } },
  },
  { label: 'Pricing', href: '/pricing' },
  { label: 'Contact', href: '/contact' },
  {
    label: 'Blog',
    href: '/blog',
    mega: { layout: 'titled', align: 'end', columns: blogColumns },
  },
];

The same file also holds the announcement bar text (announcement), the header’s Login and “Book a Demo” buttons (headerButtons), and the mobile drawer’s buttons (drawerButtons). Badge tones map to .badge--<tone> colors in src/styles/global.css.

Mobile Menu & Dropdown Menus

The mobile menu toggle and dropdown behavior require client-side JavaScript, which Techwave handles with small vanilla <script> blocks — there are no React islands. Desktop mega menus are rendered by src/components/MegaMenu.astro and open on hover or keyboard focus; the script in src/components/Header.astro keeps aria-expanded in sync and lets Esc close an open panel. At 1024px and below, the header’s menu button opens the off-canvas drawer in src/components/MobileMenu.astro, which reads the same primaryMenu data, so both menus always stay in sync.

Footer Navigation

Footer link groups follow the same data-driven pattern as the header, in src/data/footer.js: footerColumns (the Company, Useful, Links, and Community columns), bottomLinks (the bottom bar), brand.socials (social icons), and miniFooterLinks (the minimal footer on the demo, sign-in, and sign-up pages).

Internal vs. External Links

Internal links should be root-relative (/about, not the full domain) so they keep working across environments. External links should open safely in a new tab:

<a href="/about">About</a>
<a href="https://partner-site.com" target="_blank" rel="noopener noreferrer">Partner</a>

Forms

What ships out of the box, and what still needs a backend.

Contact Forms

The template has plain HTML forms with no JavaScript submit handler, so connecting one is a matter of setting its action URL in the data file:

export const enquiry = {
  heading: 'Enquiry form',
  form: {
    action: 'https://formspree.io/f/your-form-id', // was '#'
    subjects: ['Subject', 'Astro', 'Shopify', 'Application'],
    submitLabel: 'Submit Form',
  },
  // …
};

The fields of the demo, sign-in, and sign-up forms are also defined in src/data/forms.js (name, label, type, required), so you can add or remove fields without editing markup. The sign-in and sign-up pages are front-end only — there is no authentication backend.

Newsletter Forms

The footer newsletter form is not pre-wired to any email provider. Set newsletter.action in src/data/footer.js to your provider’s form endpoint (Mailchimp, ConvertKit, Formspree, …); the form posts a single email field.

Form Validation

Required fields and email format are checked in the browser before submission using standard HTML attributes (required, type="email"), giving users immediate feedback without a round trip to a server. Validate again on the receiving end — browser checks alone can be bypassed.

Third-Party Form Services

If you’d rather not run your own backend, services like Formspree, Web3Forms, Getform, or Basin accept form submissions directly from static HTML and forward them to your email — typically a one-line change to the form’s action value in the data files above. If you deploy to Netlify, Netlify Forms can also capture them (add the data-netlify="true" attribute to the <form> tag in the component).

The header’s search overlay (src/components/SearchOverlay.astro) submits to /search, which doesn’t exist yet. Add a search page (for example with Pagefind) or remove the search button if you don’t need it.

API & Data

Only relevant if your template fetches data from an external source — skip this section otherwise.

API Configuration

If you add an API, read its URLs and keys from environment variables (see Configuration) rather than hard-coding them, so the same code can point at a staging or production API depending on environment:

PUBLIC_API_URL=https://example.com/api
PUBLIC_API_KEY=your_api_key

Fetch Requests

const res = await fetch(`${import.meta.env.PUBLIC_API_URL}/products`, {
  headers: { Authorization: `Bearer ${import.meta.env.PUBLIC_API_KEY}` },
});
const data = await res.json();

Data Structures

The only structured data the template defines is its two content collections, validated with Zod schemas in src/content.config.js:

• blog — title, slug, date (required); optional updated, excerpt, image, listImage; author (default 'techwave'), likes, categories, tags, headerStyle ('hero' | 'classic'), format ('standard' | 'gallery' | 'audio' | 'video' | 'quote'), and a media object (image, gallery, galleryNav, audio, video as a YouTube id, quote).
• legal — title, updated, and variant ('privacy' | 'terms').

If you move posts to an external CMS, map its response onto these same fields so the existing layouts and listing pages keep working. A front-matter value that doesn’t match the schema fails the build with a message naming the file and field.

Error Handling

try {
  const res = await fetch(apiUrl);
  if (!res.ok) throw new Error(`Request failed: ${res.status}`);
  const data = await res.json();
} catch (err) {
  // show a fallback UI state instead of a blank page
  console.error(err);
}

SEO

Per-page metadata, social previews, and the machine-readable files search engines expect.

Page Title & Meta Description

Pass a unique title and description into Layout on every page — these drive both the browser tab and the snippet shown in search results. Pages that omit them fall back to the defaults in src/layouts/Layout.astro, and blog posts take theirs from front matter.

<Layout
  title="Services – Techwave"
  description="Managed IT services and help desk support for growing teams."
  image="/images/og/services.jpg"  <!-- optional: Open Graph image path -->
>

Canonical URL, Open Graph & Twitter/X Cards

Already set inside Layout.astro’s <head> for every page, using the site value from astro.config.mjs to build absolute URLs:

<link rel="canonical" href={canonical} />
<meta property="og:type" content={type} />
<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
<meta property="og:url" content={canonical} />
<meta property="og:image" content={ogImage} />
<meta name="twitter:card" content="summary_large_image" />

The default Open Graph image is /images/logo-dark.svg. Most social networks don’t render SVG previews, so add a 1200×630 JPG or PNG to public/images/ and change the image default in Layout.astro (or pass image per page). Blog posts set og:type to article and use their front-matter image as the preview, and their excerpt as the description.

Sitemap & Robots.txt

The template includes Astro’s official sitemap integration (@astrojs/sitemap), which generates sitemap-index.xml automatically at build time from the site value, leaving out the 404 page. No robots.txt is included — create public/robots.txt to control crawler access and point it at the sitemap:

User-agent: *
Allow: /
Sitemap: https://techwave.example.com/sitemap-index.xml

Structured Data & Semantic HTML

Use landmark elements (<header>, <nav>, <main>, <article>) and a single <h1> per page so both search engines and screen readers can parse the page’s structure. The template ships no JSON-LD; add structured data in Layout.astro’s <head> for rich results (e.g. Organization or Article schema) where relevant to your content.

Deployment

Platform-by-platform steps. Confirm your rendering mode first — it changes the build output you deploy.

Vercel

1. Push the project to a GitHub, GitLab, or Bitbucket repository.
2. In Vercel, choose Add New → Project and import that repository.
3. Build command: npm run build · Output directory: dist (Astro static) — Vercel’s Astro preset detects this automatically in most cases.
4. If you’ve added a .env file, add its variables under Project Settings → Environment Variables (the template itself needs none).
5. Click Deploy.

Netlify

[build]
  command = "npm run build"
  publish = "dist"

Connect the repository in the Netlify dashboard, confirm these build settings, add any environment variables you’ve introduced under Site configuration → Environment variables, and deploy. The template ships no netlify.toml; create one with the content above if you want the settings in the repository.

Cloudflare Pages

Connect the repository, set the build command to npm run build and the output directory to dist. For SSR Astro sites, use the official @astrojs/cloudflare adapter instead of the static preset.

GitHub Pages

Set site and base in astro.config.mjs to match your repository URL, then build and publish the dist/ folder to the gh-pages branch (via the official astro build + a deploy action, or manually). GitHub Pages only serves static output — it cannot run an SSR adapter.

Traditional Hosting

For a static build, upload the contents of dist/ to your host’s public web root via FTP/SFTP or your host’s file manager. Because Techwave is static, ordinary shared hosting works — no Node.js is needed on the server. (Only if you later switch to SSR with an adapter would the host need to run node continuously.)

Build & Production

What happens when you run build, and a checklist before you ship.

npm run build     # validate content, bundle, and write dist/
npm run preview   # serve dist/ locally, exactly as it will run in production

Build Output

The build writes one static HTML page per route (including every blog post, listing page, and archive page), hashed CSS/JS bundles, the files from public/, and sitemap-index.xml to dist/. This folder is disposable and regenerated by every build — the template’s .gitignore already keeps it out of Git.

Environment Variables in Production

Techwave needs no environment variables out of the box. If you add some, note that variables from your local .env are not deployed automatically — each hosting platform requires you to set them again in its dashboard (see Deployment). A missing production variable is one of the most common causes of a build that works locally but fails, or behaves unexpectedly, once deployed.

Production Checklist

• Run npm run build locally and confirm it completes with no errors.
• Run npm run preview and click through the main pages.
• Replace https://techwave.example.com in astro.config.mjs with your real domain.
• If you added a .env file, set every variable from it in your hosting platform’s dashboard.
• Point every form action (contact.js, forms.js, footer.js) at a real endpoint instead of '#'.
• Replace the placeholder contact email and phone in src/data/contact.js, the '#' social links in src/data/footer.js, and the copyright line.
• Verify favicon, Open Graph image, and meta descriptions are your own, not the template defaults.
• Add a /search page or remove the header search, and replace the demo blog posts and images.

Troubleshooting

The most common problems, in the order you’re likely to hit them.

FAQ

Quick answers to the questions we hear most.

Changelog

Every notable change, newest first. Add a new entry above the last one for each release.

Support

Stuck on something this guide didn’t cover? Here’s how to reach us.

What to Include in a Support Request

The fastest way to get a useful answer is to include the details below in your first message:

When contacting support, please include:

- Template name and version
- Browser (and version)
- Operating system
- Node.js version (node --version)
- The exact error message
- Steps to reproduce the problem