docs: AI-discovery pass (sitemap, FAQ, metadata, positioning)

packages/docs/.vitepress/config.mts

@@ -3,9 +3,14 @@ import { defineConfig } from "vitepress";
 // https://vitepress.dev/reference/site-config
 export default defineConfig({
   title: "Sidequest.js",
-  description: "Robust distributed job processing for Node.js",
+  description:
+    "Redis-free background jobs for Node.js. Persist jobs in your existing PostgreSQL, MySQL, SQLite, or MongoDB. A durable, distributed BullMQ alternative.",
   lang: "en-US",
   cleanUrls: true,
+  srcExclude: ["README.md"],
+  sitemap: {
+    hostname: "https://docs.sidequestjs.com",
+  },
   head: [
     ["link", { rel: "icon", href: "/logo-modern.png" }],
     ["script", { async: "", src: `https://www.googletagmanager.com/gtag/js?id=${process.env.VITE_GA_TAG}` }],

packages/docs/guide/queues/concurrency.md

@@ -1,3 +1,9 @@
+---
+outline: deep
+title: Queue Concurrency
+description: Control how many jobs run in parallel per queue in Sidequest with the concurrency setting, and how it interacts with the global maxConcurrentJobs limit.
+---
+
 # Queue Concurrency in Sidequest
 
 This document provides a detailed explanation of **queue concurrency** in Sidequest, its purpose, how it works, and best practices for configuring concurrency effectively.
@@ -28,7 +34,7 @@ queues: [
 ];
 ```
 
-In this example, at most 2 jobs from the `default` queue, 5 jobs from `critical`, and 1 job from `low` can run concurrently, provided the `maxConcurrentJobs` limit (a global Sidequest Engine configuration) limit is not exceeded.
+In this example, at most 2 jobs from the `default` queue, 5 jobs from `critical`, and 1 job from `low` can run concurrently, provided the `maxConcurrentJobs` limit (a global Sidequest Engine configuration) is not exceeded.
 
 ## Best practices for concurrency
 

packages/docs/guide/queues/index.md

@@ -1,7 +1,7 @@
 ---
 outline: deep
 title: Queues
-description: Queues guide for Sidequest.js
+description: Manage queues in Sidequest. Configure concurrency, priority, and states to control how background jobs are processed.
 ---
 
 # Queues in Sidequest

packages/docs/guide/queues/priority.md

@@ -1,3 +1,9 @@
+---
+outline: deep
+title: Queue Priority
+description: Configure queue priority in Sidequest to control which queues get worker capacity first when jobs compete for resources.
+---
+
 # Queue Priority in Sidequest
 
 This document provides a detailed explanation of **queue priority** in Sidequest, its purpose, how it works, and best practices for configuring priorities effectively.

packages/docs/guide/queues/states.md

@@ -1,3 +1,9 @@
+---
+outline: deep
+title: Queue States
+description: Understand queue states in Sidequest, what they mean, and how to manage them for reliable job processing.
+---
+
 # Queue States in Sidequest
 
 This document provides a detailed explanation of **queue states** in Sidequest, their meanings, use cases, and operational considerations. Understanding and managing queue states properly is essential to maintaining a reliable job processing system.

packages/docs/index.md

@@ -1,10 +1,12 @@
 ---
 # https://vitepress.dev/reference/default-theme-home-page
 layout: home
+description: Redis-free background jobs for Node.js. Persist jobs in your existing PostgreSQL, MySQL, SQLite, or MongoDB. A durable, distributed BullMQ alternative with a built-in dashboard.
 
 hero:
   name: "Sidequest.js"
-  text: "Robust distributed job processing for Node.js"
+  text: "Redis-free background jobs for Node.js"
+  tagline: "Persist jobs in the PostgreSQL, MySQL, SQLite, or MongoDB you already run. Durable, distributed, and a drop-in BullMQ alternative, with a dashboard included."
   image:
     src: /logo-modern.png
     alt: Blue hexagonal molecular network icon with three circular nodes, featuring a strong gradient with a bright, light-blue highlight, on a transparent background.
@@ -20,10 +22,10 @@ hero:
       link: /resources/faq
 
 features:
-  - title: 🌎 Cloud & Database Agnostic
-    details: Deploy anywhere – use PostgreSQL, MySQL, SQLite, and soon MongoDB. Migrate clouds or infra with zero friction. No vendor lock-in, ever.
+  - title: 🚫 No Redis Required
+    details: Store jobs in PostgreSQL, MySQL, SQLite, or MongoDB. No extra stateful service to provision, secure, or pay for. Portable across any cloud or on-premises, no vendor lock-in.
   - title: 🚀 Production-Ready & Scalable
-    details: Reliable job processing, distributed by design, with robust scheduling and retries. Trusted for mission-critical workloads, from startups to enterprise.
+    details: Distributed by design. Jobs are claimed atomically (SELECT ... FOR UPDATE SKIP LOCKED), so each runs exactly once across nodes. Robust scheduling and retries, from startups to enterprise.
   - title: 📊 Beautiful Web Dashboard Included
     details: Monitor, reprocess, and debug jobs in real time with a modern dashboard – Ready to use out of the box, no hidden paywalls.
   - title: 🛠️ Open Source & Developer-First

packages/docs/introduction/why.md

@@ -31,7 +31,7 @@ Sidequest persists jobs in your existing Postgres, MySQL, SQLite, or MongoDB dat
 
 ## Who this is for
 
-Sidequest is aimed at startups and small product teams who want reliable background processing without the operational overhead of an additional service. If you are already running Postgres (and most teams are), adding Sidequest requires zero extra infrastructure.
+Sidequest is aimed at teams that already run a database and want reliable background processing without the operational overhead of an additional service, from startups to larger product teams. If you are already running Postgres (and most teams are), adding Sidequest requires zero extra infrastructure.
 
 This is the same thesis as [Solid Queue](https://dev.37signals.com/introducing-solid-queue/) in Rails and [Oban](https://getoban.pro/) in Elixir: use the database you already trust, leverage its guarantees, and keep your system simple.
 

packages/docs/recipes/index.md

@@ -5,8 +5,6 @@ description: Common Sidequest patterns and real-world examples.
 
 # Recipes
 
-> **Work in progress.** Recipes are being written.
-
 Practical examples for common background job patterns:
 
 - [Sending Emails](/recipes/emails)

packages/docs/resources/faq.md

@@ -1,7 +1,7 @@
 ---
 outline: deep
 title: FAQ
-description: Frequently Asked Questions for Sidequest.js
+description: "FAQ: Does Sidequest need Redis? Does it run on Bun? Is it production-ready? How does it compare to BullMQ and pg-boss? Common questions answered."
 ---
 
 # Frequently Asked Questions (FAQ)
@@ -10,7 +10,23 @@ This page offers answers to some of the most common questions about Sidequest.js
 
 ## What is Sidequest.js?
 
-Sidequest is an open-source, modern, scalable distributed background job processor for Node.js applications.
+Sidequest is an open-source, production-grade, distributed background job processor for Node.js. Instead of requiring Redis, it persists jobs in the database you already run (PostgreSQL, MySQL, SQLite, or MongoDB). It is a [BullMQ](https://docs.sidequestjs.com/getting-started/migrating-from-bullmq) and pg-boss alternative, with a built-in web dashboard.
+
+## Does Sidequest need Redis?
+
+No. That is the whole point. Most Node.js job queues (Bull, BullMQ, Bee-Queue) require Redis. Sidequest stores jobs in your existing SQL or document database instead, so there is no separate Redis service to provision, secure, pay for, or monitor. See [Why Sidequest](/introduction/why).
+
+## Does Sidequest run on Bun?
+
+Not yet. Sidequest targets **Node.js (>= 22.6.0)**. Bun support is [tracked here](https://github.com/sidequestjs/sidequest/issues/72). It is not a Bun-only or Bun-first library.
+
+## Is Sidequest production-ready, or only for small apps?
+
+It is built for production. Jobs are durably persisted in your database and claimed atomically (`SELECT ... FOR UPDATE SKIP LOCKED` on Postgres/MySQL), so each job runs exactly once even across multiple instances. The engine runs in a forked process and executes jobs in worker threads. It scales from a single node to a distributed multi-node deployment. PostgreSQL is recommended for production; SQLite is intended for local development and tests.
+
+## How does Sidequest compare to BullMQ, pg-boss, Solid Queue, or Oban?
+
+Sidequest shares the "skip Redis, reuse your database" thesis of [Solid Queue](https://dev.37signals.com/introducing-solid-queue/) (Rails) and [Oban](https://getoban.pro/) (Elixir). Compared to **BullMQ** (Redis-based), Sidequest removes the dedicated Redis instance; BullMQ has a higher throughput ceiling on a dedicated cluster, while Sidequest optimizes for operational simplicity. Compared to **pg-boss** (Postgres-only) and **Agenda** (Mongo-only), Sidequest supports multiple databases, ships a dashboard, and isolates jobs in worker threads. See the [comparison](https://sidequestjs.com/vs-bullmq) and the [migration guide](https://docs.sidequestjs.com/getting-started/migrating-from-bullmq).
 
 ## What is a Queue?