如何打造像 EnergySage 一樣的太陽能安裝商目錄平台

如果你曾經搜索過「find solar installer near me」，你可能登陸過 EnergySage。它是美國主導的太陽能市場平台，連接房主和經過審核的安裝商，生成有競爭力的報價，每週拉取數百萬個數據點。美國能源部直接資助了它的開發。如果你正在讀這篇文章，你可能想打造類似的東西。

過去幾年，我為能源、家居服務和 B2B 領域的客戶構建了目錄式市場和基於地理位置的服務平台。太陽能安裝商目錄背後的架構並不是火箭科學，但有很多決策會影響項目的成敗。讓我帶你走過整個過程——從數據建模到搜索基礎設施，再到真正推動自然流量的 SEO 策略。

目錄

理解太陽能市場模式

在寫任何一行代碼之前，你需要理解 EnergySage 和 solar.com 等平台作為商業模式的工作原理。它們是具有特定收入模式的雙邊市場：

  1. 房主輸入他們的地址和公用事業信息來請求太陽能報價
  2. 安裝商付費訪問這些線索並在價格和品質上競爭
  3. 平台通過安裝商訂閱、按線索收費或關閉交易提成獲得收益

EnergySage 報告稱他們的市場為房主節省了大約 $0.20–$0.40 每瓦特，相比直接購買——在典型的 5 kW 住宅系統上是 $1,000–$2,000。這種節省來自競爭。當多個安裝商競標同一項目時，價格下降。這是你需要複製的核心價值主張。

2025 年的太陽能市場是美國獨有的 $30 億以上的行業，住宅安裝每年增長約 15-20%。《通貨膨脹減少法》的 30% 聯邦稅收抵免一直運行到 2032 年，所以這個市場不會放緩。

以下是主要參與者的樣子：

平台 模式 收入來源 安裝商網絡
EnergySage 報價市場 線索費用 + 數據許可 500+ 經過審核的安裝商
Solar.com 引導式市場 優先定價佣金 精選網絡
Enphase 安裝商定位器 設備綁定目錄 硬件銷售 認證的 Enphase 安裝商
SolarReviews 評論目錄 線索生成費用 500+ 上市公司
Yelp/Google 通用目錄 廣告 未經審核的列表

你的目錄不需要與 EnergySage 直接競爭。存在細分機會：特定州目錄、僅商業市場、電池儲能專家或專注於特定設備品牌的目錄。

核心架構決策

第一個真實的決策是你要構建靜態目錄、動態市場還是介於兩者之間。每一個都有完全不同的複雜性。

靜態目錄 vs. 動態市場

靜態目錄列出安裝商的聯絡資訊、評論和服務區域。想象一下太陽能的黃頁。複雜性低，構建速度快，通過廣告或特色列表獲利。

動態市場處理整個從報價到成交的工作流程：線索捕捉、安裝商匹配、報價生成、比較工具，有時甚至融資。這就是 EnergySage 做的事。複雜性高，但收入潛力要高得多。

大多數團隊應該從目錄開始，然後在頂部分層市場功能。原因如下：目錄頁面生成自然流量（想象數千個「[城市]的太陽能安裝商」頁面），那個流量為市場漏斗提供動力。

無頭架構

對於這樣的項目，我強烈推薦無頭架構。以下是我會使用的設置：

  • 前端：Next.js 或 Astro 用於面向公眾的網站
  • CMS：無頭 CMS（Sanity、Contentful 或 Payload）用於安裝商個人資料和編輯內容
  • API 層：自定義 Node.js/Express 或 tRPC API 用於搜索、報價和交易邏輯
  • 數據庫：PostgreSQL with PostGIS 用於地理空間查詢
  • 搜索：Algolia 或 Meilisearch 用於即時安裝商搜索

我們使用我們的 Next.js 開發和 無頭 CMS 能力為客戶構建了類似的架構。無頭方法讓你能獨立擴展內容層（數千個位置頁面）和應用層（報價引擎、用戶儀表板）。

Monorepo 結構

我會使用 Turborepo 將其組織為 monorepo：

├── apps/
│   ├── web/              # Next.js 公開網站
│   ├── installer-portal/  # 安裝商儀表板 (Next.js)
│   └── admin/            # 內部管理員 (React)
├── packages/
│   ├── database/         # Prisma 架構 + 遷移
│   ├── api/              # 共享 API 路由/tRPC
│   ├── ui/               # 共享組件庫
│   └── geo/              # 地理空間實用程序
└── turbo.json

隨著項目的增長，這保持了組織。geo 包值得調出——你將在多個應用程序中重複使用地理空間邏輯（距離計算、服務區域匹配、地理編碼）。

安裝商目錄的數據庫設計

這是大多數目錄項目要么成功要么創建多年困擾的地方。讓我分享一個行之有效的架構。

核心實體

-- 安裝商公司
CREATE TABLE installers (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name VARCHAR(255) NOT NULL,
  slug VARCHAR(255) UNIQUE NOT NULL,
  description TEXT,
  website_url VARCHAR(500),
  phone VARCHAR(20),
  email VARCHAR(255),
  logo_url VARCHAR(500),
  founded_year INTEGER,
  employee_count_range VARCHAR(50),
  license_number VARCHAR(100),
  is_verified BOOLEAN DEFAULT FALSE,
  verification_date TIMESTAMP,
  avg_rating DECIMAL(2,1) DEFAULT 0,
  total_reviews INTEGER DEFAULT 0,
  total_installations INTEGER DEFAULT 0,
  status VARCHAR(20) DEFAULT 'pending',
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

-- 服務區域 (使用 PostGIS 進行地理查詢)
CREATE TABLE service_areas (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  installer_id UUID REFERENCES installers(id),
  area_name VARCHAR(255),
  geometry GEOMETRY(POLYGON, 4326),
  radius_miles INTEGER,
  center_point GEOMETRY(POINT, 4326),
  is_primary BOOLEAN DEFAULT FALSE
);

-- 認證和憑證
CREATE TABLE installer_certifications (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  installer_id UUID REFERENCES installers(id),
  certification_type VARCHAR(100), -- 'NABCEP', 'Tesla Powerwall', 'Enphase', 等
  certification_number VARCHAR(100),
  issued_date DATE,
  expiry_date DATE,
  verified BOOLEAN DEFAULT FALSE
);

-- 他們安裝的設備/品牌
CREATE TABLE installer_equipment (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  installer_id UUID REFERENCES installers(id),
  equipment_type VARCHAR(50), -- 'panel', 'inverter', 'battery'
  brand VARCHAR(100),
  model VARCHAR(255),
  is_preferred BOOLEAN DEFAULT FALSE
);

-- 位置頁面 (用於 SEO)
CREATE TABLE locations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  state VARCHAR(2) NOT NULL,
  city VARCHAR(255) NOT NULL,
  county VARCHAR(255),
  slug VARCHAR(255) UNIQUE NOT NULL,
  zip_codes TEXT[], -- 涵蓋的郵編陣列
  center_point GEOMETRY(POINT, 4326),
  avg_system_cost DECIMAL(10,2),
  avg_electricity_rate DECIMAL(5,4),
  avg_sun_hours DECIMAL(4,2),
  state_incentives JSONB,
  installer_count INTEGER DEFAULT 0,
  meta_title VARCHAR(70),
  meta_description VARCHAR(160),
  content TEXT, -- Markdown 編輯內容
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

服務區域問題

這是棘手的部分。安裝商不為單點周圍的整齊圓形區域服務。他們服務於形狀奇怪的區域——也許在一個州的三個縣加上邊境另一邊的幾個郵編。你有三個選項：

  1. 基於半徑的：安裝商設置中心點和最大距離。簡單但不準確。
  2. 郵編列表：安裝商選擇特定郵編。準確但對大面積來說繁瑣。
  3. 基於多邊形：在地圖上繪製實際的服務區域邊界。最準確，最好的 UX，但需要 PostGIS 和地圖繪製 UI。

我會實現第 3 個選項，第 1 個作為備用。在入職期間，讓安裝商在 Mapbox/Google Maps 界面上繪製他們的服務區域或只是輸入半徑。使用 PostGIS 的 ST_Contains 和 ST_DWithin 函數進行匹配：

-- 查找服務特定點的安裝商 (房主地址)
SELECT i.* FROM installers i
JOIN service_areas sa ON sa.installer_id = i.id
WHERE ST_Contains(sa.geometry, ST_SetSRID(ST_MakePoint(-71.4128, 41.8240), 4326))
  AND i.status = 'active'
ORDER BY i.avg_rating DESC;

基於地理位置的搜索和位置服務

「find solar installer near me」查詢很重要。它是主要用戶意圖、主要 SEO 目標和核心 UX 流程。你需要做好這一點。

地理編碼管道

當房主輸入他們的地址或郵編時，流程如下：

  1. 客戶端：使用 Google Places API 或 Mapbox Geocoding 自動完成
  2. 地理編碼：將地址轉換為 lat/lng 坐標
  3. 查詢：查找服務區域包含該點的安裝商
  4. 擴充：拉入本地公用事業數據、州激勵、平均太陽輻照度
  5. 排列：按相關性排序（評分、距離、響應時間、驗證狀態）
// 示例：Next.js API 路由用於安裝商搜索
import { db } from '@/packages/database';
import { geocode } from '@/packages/geo';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const zipCode = searchParams.get('zip');
  const lat = searchParams.get('lat');
  const lng = searchParams.get('lng');

  let coordinates = { lat: Number(lat), lng: Number(lng) };

  if (zipCode && (!lat || !lng)) {
    coordinates = await geocode(zipCode);
  }

  const installers = await db.$queryRaw`
    SELECT 
      i.*,
      ST_Distance(
        sa.center_point::geography,
        ST_SetSRID(ST_MakePoint(${coordinates.lng}, ${coordinates.lat}), 4326)::geography
      ) / 1609.34 as distance_miles
    FROM installers i
    JOIN service_areas sa ON sa.installer_id = i.id
    WHERE (
      ST_Contains(sa.geometry, ST_SetSRID(ST_MakePoint(${coordinates.lng}, ${coordinates.lat}), 4326))
      OR ST_DWithin(
        sa.center_point::geography,
        ST_SetSRID(ST_MakePoint(${coordinates.lng}, ${coordinates.lat}), 4326)::geography,
        sa.radius_miles * 1609.34
      )
    )
    AND i.status = 'active'
    ORDER BY i.is_verified DESC, i.avg_rating DESC, distance_miles ASC
    LIMIT 20
  `;

  return Response.json({ installers, coordinates });
}

搜索基礎設施

對於即時搜索（按名稱、認證、設備品牌篩選），PostgreSQL 單獨在你超過幾千個安裝商後會變得緩慢。在頂部分層 Algolia 或 Meilisearch：

功能 Algolia Meilisearch PostgreSQL 全文搜索
延遲 <50ms <50ms 100-500ms
地理篩選 內置 內置 需要 PostGIS
分面搜索 優秀 良好 手動
拼寫容差 是 是 否
定價 (2025) $1/1K 請求 免費 (自託管) 免費
設置複雜性 低 中等 低

Algolia 每 1,000 次搜索請求 $1 對大多數目錄來說是合理的。如果預算緊張，在 $20/月 VPS 上自託管 Meilisearch。

構建報價請求系統

這是將目錄與市場區分開來的。報價系統是你的收入引擎。

報價請求流程

  1. 房主輸入地址 → 自動檢測公用事業提供者和費率
  2. 屋頂評估 (來自 Google Solar API 或 Aurora Solar 的衛星影像)
  3. 基於使用和屋頂空間的系統大小建議
  4. 與該地區 3-8 名合格安裝商匹配
  5. 安裝商在 48 小時內提交競爭報價
  6. 房主在標準化儀表板上比較報價

Google Solar API（於 2023 年推出，現已廣泛可用）是一個巨大的捷徑。它為美國 320+ 百萬棟建築提供太陽能潛力數據，包括：

  • 屋頂分段分析
  • 年陽光時數
  • 估計能源生產
  • 最佳面板放置
// Google Solar API - 建築洞察
const response = await fetch(
  `https://solar.googleapis.com/v1/buildingInsights:findClosest?` +
  `location.latitude=${lat}&location.longitude=${lng}` +
  `&requiredQuality=HIGH&key=${GOOGLE_SOLAR_API_KEY}`
);

const data = await response.json();
// data.solarPotential.maxArrayPanelsCount
// data.solarPotential.maxSunshineHoursPerYear
// data.solarPotential.financialAnalyses

這消除了初始報價階段手動現場勘測的需求，大大減少了報價時間。

報價數據模型

每個報價需要捕捉足夠的細節以進行有意義的比較：

interface SolarQuote {
  id: string;
  requestId: string;
  installerId: string;
  systemSizeKw: number;
  panelBrand: string;
  panelModel: string;
  panelCount: number;
  inverterBrand: string;
  inverterType: 'string' | 'micro' | 'hybrid';
  batteryIncluded: boolean;
  batteryBrand?: string;
  batteryCapacityKwh?: number;
  grossCost: number;
  federalTaxCredit: number;
  stateIncentives: number;
  utilityRebates: number;
  netCost: number;
  estimatedAnnualProduction: number;
  warrantyYears: number;
  estimatedPaybackYears: number;
  financingOptions: FinancingOption[];
  validUntil: Date;
}

本地太陽能頁面的 SEO 架構

這是大多數太陽能目錄要么贏要么輸的地方。EnergySage 從程序化位置頁面生成大量自然流量——他們為每個州的每個城市都有頁面，結構為 /local-data/solar-companies/{state}/{county}/{city}/。

URL 結構

以下是我推薦的 URL 層次結構：

/solar-installers/                        # 國家樞紐
/solar-installers/rhode-island/           # 州頁面
/solar-installers/rhode-island/providence/ # 城市頁面
/installer/blue-sky-solar/                # 個別安裝商個人資料
/solar-costs/rhode-island/                # 按州的成本數據

程序化頁面生成

使用 Next.js App Router，你可以在構建時生成數千個位置頁面：

// app/solar-installers/[state]/[city]/page.tsx
export async function generateStaticParams() {
  const locations = await db.location.findMany({
    select: { state: true, slug: true }
  });
  
  return locations.map((loc) => ({
    state: loc.state.toLowerCase().replace(/\s+/g, '-'),
    city: loc.slug,
  }));
}

export async function generateMetadata({ params }: Props) {
  const location = await getLocation(params.state, params.city);
  return {
    title: `Best Solar Installers in ${location.city}, ${location.state} (2025)`,
    description: `Compare ${location.installerCount} vetted solar companies in ${location.city}. Average system cost: $${location.avgSystemCost}. Get free quotes today.`,
  };
}

對於具有 10,000+ 位置頁面的網站，請考慮 Astro 而不是 Next.js。Astro 的靜態生成對於內容繁重的網站來說快得多——我們為大型程序化頁面集看到構建時間從 45 分鐘下降到 5 分鐘以下。

位置頁面的內容策略

不要只生成空白模板頁面。每個位置頁面都需要獨特、有用的內容：

  • 該地區活躍安裝商的數量
  • 該市太陽能系統的平均成本 (從你的報價數據中拉取)
  • 本地公用事業費率和淨計量政策
  • 州和地方激勵 (這些差異很大)
  • 平均太陽輻照度 / 陽光時數
  • 具有真實評論的最高評分安裝商
  • 最近報價的比較表

例如，EnergySage 的普羅維登斯、羅德島頁面列出了 8 個市場安裝商，詳細說明經驗、認證和設備偏好。這是你競爭的深度。

安裝商驗證和信任信號

信任就是整個遊戲。EnergySage 驗證安裝商在加入之前有 2-3 年的經驗和多個成功安裝。Solar.com 談論「淘汰垃圾」。你需要一個驗證管道。

驗證清單

  • 營業執照：通過 API 驗證州承包商執照 (許多州有公開查詢 API)
  • 保險：需要通用責任保險 ($1M+) 和工人賠償證明
  • NABCEP 認證：太陽能安裝商的黃金標准——針對 NABCEP 數據庫驗證
  • 營業年限：與州企業登記交叉引用
  • 安裝歷史：請求已完成項目的組合
  • 背景調查：對投標住宅項目的公司
  • 評論：從 Google、Yelp、BBB 和你自己的平台彙總

信任 UI 元素

在安裝商個人資料上突出顯示驗證狀態：

<div className="flex items-center gap-2">
  <VerifiedBadge />
  <span className="text-sm text-green-700">
    Verified: License #12345 • NABCEP Certified • 
    Insured to $2M • {yearsInBusiness} years experience
  </span>
</div>

在每個頁面上包含「Why you can trust us」部分 — EnergySage 這樣做並且有效。透明地解釋你的審查過程。

技術棧建議

以下是我在 2025 年實際會使用的東西：

層 技術 原因
前端 Next.js 15 (App Router) SSR + ISR 用於動態頁面，RSC 用於性能
樣式設計 Tailwind CSS + shadcn/ui 快速迭代、可訪問組件
CMS Payload CMS (自託管) 開源、適合自定義集合
數據庫 PostgreSQL 16 + PostGIS 地理空間查詢、可靠性
ORM Prisma + 原始 SQL 用於地理 兩全其美
搜索 Meilisearch (自託管) 免費、快速、地理感知
地圖 Mapbox GL JS 在規模上比 Google Maps 更好的定價
地理編碼 Mapbox 地理編碼 API $0.75 每 1,000 次請求
託管 Vercel (前端) + Railway (API + DB) 輕鬆部署、合理定價
認證 Clerk 或 NextAuth.js 分離房主和安裝商的流程
監控 Sentry + Plausible Analytics 錯誤跟踪 + 隱私友好分析
電子郵件 Resend 報價通知的交易電子郵件

處理 ~10,000 月度用戶的 MVP 的總基礎設施成本：大約 $150-300/月。大規模 (100K+ 月度用戶)，預期 $800-2,000/月，不考慮 API 成本。

性能基準和成本估計

以下是現實的開發時間表：

階段 範圍 時間表 成本範圍
MVP 目錄 安裝商列表、地理搜索、位置頁面 8-12 週 $30K-60K
報價系統 線索捕捉、安裝商匹配、報價比較 6-8 週 $25K-45K
安裝商門戶 儀表板、線索管理、分析 4-6 週 $15K-30K
房主儀表板 保存的報價、消息、項目跟踪 4-6 週 $15K-25K
支付集成 安裝商訂閱、線索支付 2-3 週 $8K-15K
總計 MVP 市場 24-35 週 $93K-175K

這些是經驗豐富的團隊進行高品質構建的現實數字。我見過機構報價 $250K+ 以上的類似範圍，我見過團隊試圖以 $15K 完成，最後得到在真實流量下崩潰的東西。

性能目標你應該達到：

  • 位置頁面加載：< 1.5s (LCP) — 這些是你的 SEO 金錢頁面
  • 搜索結果：< 200ms 從按鍵到結果
  • 地理查詢：< 100ms 用於「[郵編]附近的安裝商」
  • 核心網絡生命週期：全綠色
  • 構建時間：< 10 分鐘用於 5,000+ 靜態頁面

常見問題

構建像 EnergySage 一樣的太陽能安裝商目錄需要多少成本？ 帶有地理搜索和安裝商個人資料的基本目錄可以以 $30K-60K 構建。具有報價比較、安裝商儀表板和支付處理的完整市場通常運行 $93K-175K，具體取決於功能範圍。EnergySage 本身由美國能源部撥款資助，籌集了超過 $10M 的風險投資，所以不要期望在微薄預算上複製其完整功能集。

我應該為太陽能市場使用什麼技術棧？ 我推薦 Next.js 15 用於前端 (SSR 功能對 SEO 至關重要)、PostgreSQL with PostGIS 用於地理空間查詢，以及 Algolia 或 Meilisearch 用於即時搜索。對於 CMS 層，Payload CMS 或 Sanity 適用於管理安裝商個人資料和編輯內容。在 Vercel 上託管前端，在 Railway 或 Render 上託管你的數據庫和 API。

像 EnergySage 這樣的太陽能市場平台如何賺錢？ EnergySage 使用線索生成模式，安裝商支付費用訪問合格房主線索。他們還向投資公司、學術研究人員和政府機構許可他們廣泛的太陽能定價數據。Solar.com 採用略有不同的方法，採用首選定價佣金。大多數目錄網站從特色列表費用 ($50-500/月 每個安裝商) 開始，隨著規模擴展到按線索定價 ($20-100 每個合格線索)。

我如何獲得太陽能安裝商數據來填充我的目錄？ 從公開數據開始：州承包商執照數據庫、NABCEP 的認證安裝商目錄和製造商定位器 (如 Enphase 的安裝商網絡)。然後構建一個入職流程，安裝商可以聲稱和增強他們的個人資料。早期，你需要手動聯繫安裝商——提供免費列表以播種市場。冷啟動問題是真實的；沒有人想加入空市場。

SEO 對太陽能安裝商目錄的重要性有多大？ 它本質上是你整個增長策略。針對「[城市]的太陽能安裝商」查詢的程序化位置頁面是 EnergySage 推動大部分流量的方式。你會想要為每個主要城市和州的獨特頁面，每個都有真實本地數據 (平均成本、激勵信息、安裝商數量)。沒有強大的自然搜索性能，你會通過付費購置預算來燃燒，試圖競爭。

我應該為地圖功能使用 Google Maps 還是 Mapbox？ 在大多數情況下使用 Mapbox。Google Maps 定價變得很快變得昂貴——Maps JavaScript API 在 $200/月免費信用之後按每 1,000 個加載 $7 收費。Mapbox 每 1,000 個地圖加載收費 $0.60，有慷慨的每月 50,000 個免費加載。對於可能在數千個位置頁面上呈現地圖的目錄，Mapbox 每月可以為你節省數千美元。但是，使用 Google 的 Solar API 進行建築洞察數據——沒有其他東西接近。

我如何處理安裝商驗證和審查？ 構建一個多步驟驗證管道：檢查州承包商執照數據庫 (許多有公開 API)、驗證 NABCEP 認證、需要保險證明，並交叉引用業務登記記錄。EnergySage 需要 2-3 年的經驗和多個已完成的安裝。自動化你能做的，但期望進行一些手動審查。在安裝商個人資料上突出顯示驗證徽章——它們直接影響房主轉化率。

我可以使用 Google Solar API 估計太陽能潛力嗎？ 是的，你應該。Google 的 Solar API 涵蓋美國 320+ 百萬棟建築，並提供屋頂分段分析、年陽光數據和估計能源生產。它每 1,000 次建築洞察請求成本 $10。當房主輸入他們的地址時，使用它預先填充系統大小估計——這大大改善了報價請求體驗，在安裝商甚至參與之前設置了現實期望。