Website RFP schreiben: Der vollständige Leitfaden für 2026

Ich habe schon auf beiden Seiten des RFP-Tisches gesessen. Als Agentur haben wir auf Hunderte von Website-RFPs geantwortet. Einige waren brillant -- klar, fokussiert und so strukturiert, dass es einfach war, ein genaues Angebot zu machen. Die meisten waren furchtbar. Sie waren entweder so vage, dass wir raten mussten, was der Kunde tatsächlich brauchte, oder so präskriptiv, dass sie technische Entscheidungen vorgaben, die den Experten überlassen hätte werden sollen, die sie einstellten.

Nach Jahren damit habe ich starke Meinungen darüber entwickelt, was ein Website-RFP wirklich funktioniert. Dieser Leitfaden bietet dir eine komplette Vorlage, führt dich durch jeden Abschnitt und teilt die Fehler, die Organisationen Zehntausende von Dollar kosten, bevor eine einzige Codezeile geschrieben wird. Wenn du bereits weißt, was du brauchst und bereit bist, loszulegen, reiche dein RFP ein und wir melden uns schnell bei dir.

Inhaltsverzeichnis

Warum die meisten Website-RFPs scheitern

Das grundlegende Problem bei den meisten Website-RFPs ist einfach: Sie werden von Leuten geschrieben, die alle 3-5 Jahre eine Website kaufen, aber sie werden von Leuten gelesen, die sie jeden Tag bauen. Diese Wissenslücke führt zu einer Diskrepanz, die sich auf drei vorhersehbare Arten zeigt:

  1. Der Umfang ist entweder zu vage oder zu spezifisch. „Wir brauchen eine moderne Website" sagt Anbietern nichts. „Wir brauchen eine React 18-Anwendung mit serverseitigem Rendering, bereitgestellt auf AWS ECS" sagt ihnen, dass du bereits architektonische Entscheidungen getroffen hast, ohne die Kompromisse zu verstehen.

  2. Budget wird als Geheimnis behandelt. Organisationen denken, dass Budgetgeheimhaltung ihnen einen besseren Deal bringt. Das ist nicht der Fall. Es bringt ihnen Angebote, die entweder weit über dem Budget liegen oder so günstig sind, dass sie in 18 Monaten neu aufgebaut werden müssen.

  3. Die Evaluierungskriterien stimmen nicht mit den tatsächlichen Prioritäten überein. Das RFP sagt, dass „Innovation" wichtig ist, aber das Evaluierungskomitee wählt jedes Mal die günstigste Option.

Ein gutes RFP löst alle drei Probleme. Es teilt deine tatsächlichen Anforderungen mit, etabliert realistische Parameter und schafft einen Rahmen für einen Apfel-zu-Apfel-Vergleich.

Was sich 2026 geändert hat

Die Website-Landschaft hat sich in den letzten zwei Jahren erheblich verschoben, und dein RFP muss das widerspiegeln. Hier ist, was anders ist:

Headless-Architektur ist jetzt der Standard

Wenn du immer noch RFPs schreibst, die davon ausgehen, dass ein monolithisches CMS wie WordPress sowohl deinen Inhalt als auch dein Frontend handhabt, bist du bereits hinterher. Die Mehrheit der Enterprise- und Mid-Market-Projekte in 2026 verwenden einen Headless-Ansatz -- ein CMS für Content-Management und ein separates Frontend-Framework für das Benutzererlebnis. Das hat echte Auswirkungen auf dein RFP, da du jetzt zwei technische Entscheidungen evaluierst, nicht eine.

Frameworks wie Next.js und Astro sind erheblich gereift. Wenn du diesen Bereich erkundest, erklären unsere Next.js-Entwicklungs- und Astro-Entwicklungs- Fähigkeitsseiten die Kompromisse in einfacher Sprache.

Core Web Vitals sind Mindestanforderung

Googles Page Experience Signale sind nicht neu, aber die Schwellenwerte wurden Ende 2025 verschärft. Dein RFP sollte spezifische Leistungsanforderungen enthalten -- nicht nur „die Website sollte schnell sein", sondern messbare Ziele wie LCP unter 2,5 Sekunden, CLS unter 0,1 und INP unter 200ms. Jede ernsthaft agierende Agentur kann diese Zahlen erreichen. Wenn ein Anbieter bei Leistungsanforderungen zurückweicht, ist das ein rotes Flagge.

KI-Funktionen brauchen klare Grenzen

Jedes Angebot, das du 2026 erhalten wirst, wird KI erwähnen. Intelligente Suche, Content-Generierung, Personalisierung, Chatbots -- die Liste geht weiter. Dein RFP muss zwischen KI-Funktionen, die du wirklich möchtest, und KI-Buzzwörtern unterscheiden, die Anbieter einwerfen, um höhere Preise zu rechtfertigen. Sei spezifisch: „Wir wollen AI-gestützte Website-Suche, die natürlichsprachliche Abfragen verarbeitet" ist nützlich. „Wir wollen KI-Integration" ist nicht.

Barrierefreiheit ist eine rechtliche Anforderung

Mit der kontinuierlichen Durchsetzung von ADA-Standards für Websites durch das DOJ und dem vollständigen Inkrafttreten des Accessibility Act in Europa ist WCAG 2.2 AA-Konformität nicht optional. Dein RFP muss Barrierefreiheitsanforderungen mit spezifischen Standards enthalten, und du solltest Anbieter fragen, wie sie die Einhaltung testen. Automatisierte Tools erkennen nur etwa 30% der Barrierefreiheitsprobleme -- du möchtest von manuellen Tests und Tests mit Hilfstechnologien hören.

Die komplette Website-RFP-Vorlage

Hier ist die vollständige Vorlage. Kopiere sie, passe sie an, mache sie zu deiner. Ich werde danach jeden Abschnitt erklären.

# Website-Redesign RFP -- [Organisationsname]

## 1. Organisationsübersicht
- Wer du bist (2-3 Absätze)
- Branche und Marktposition
- Aktuelle Website-URL
- Wichtigste Stakeholder und Entscheidungsträger

## 2. Projektübersicht
- Warum du dieses Projekt jetzt machst
- Primäre Geschäftsziele (maximal 3-5)
- Zielgruppen (priorisiert)
- Erfolgsmessungen und KPIs

## 3. Bestandsaufnahme
- Was an deiner aktuellen Website funktioniert
- Was nicht funktioniert
- Aktueller Tech-Stack
- Aktuelle Hosting-Umgebung
- Verkehrsdaten (monatliche Sessions, Top-Seiten)
- Bekannte technische Schulden oder Probleme

## 4. Leistungsumfang
- Geschätzte Anzahl von Seiten-Templates
- Inhaltstypen und -volumen
- Wichtige Funktionen und Eigenschaften
- Third-Party-Integrationen
- Content-Migration-Anforderungen
- Mehrsprachige Anforderungen
- E-Commerce-Anforderungen (falls zutreffend)

## 5. Technische Anforderungen
- CMS-Voreinstellungen oder -Anforderungen
- Barrierefreiheitsstandards (WCAG 2.2 AA Minimum)
- Leistungsziele (Core Web Vitals)
- Sicherheitsanforderungen
- Hosting-Voreinstellungen
- Browser-/Geräteunterstützungsanforderungen

## 6. Design-Anforderungen
- Brandrichtlinien (anhängen oder verlinken)
- Design-System-Erwartungen
- Konkurrenz-Websites, die dir gefallen (und warum)
- Websites, die dir nicht gefallen (und warum)

## 7. Content-Strategie
- Wer erstellt Inhalte?
- Content-Workflow-Anforderungen
- SEO-Anforderungen
- Personalisierungsanforderungen

## 8. Budget und Zeitrahmen
- Budget-Spanne (nicht eine einzelne Zahl)
- Gewünschtes Launch-Datum
- Harte Fristen oder Einschränkungen
- Phasen-Voreinstellungen

## 9. Angebots-Anforderungen
- Was in die Antwort aufgenommen werden soll
- Formatanforderungen
- Einreichungsfrist
- Fragenfrist
- Kontaktinformationen

## 10. Evaluierungskriterien
- Gewichtete Bewertungskriterien
- Auswahlprozess und Zeitrahmen
- Referenzen-Anforderung
- Präsentations-/Pitch-Erwartungen

## 11. Geschäftsbedingungen
- Bevorzugte Vertragsart
- IP-Eigentumserwartungen
- NDA-Anforderungen
- Versicherungsanforderungen

Abschnitt-für-Abschnitt Erklärung

Organisationsübersicht

Kopiere nicht einfach deine Über-Seite hier ein. Teile Anbietern mit, was sie tatsächlich wissen müssen: deine Branche, deine Größe, deine Wettbewerbslandschaft und was deine Organisation von anderen in deiner Branche unterscheidet. Je besser ein Anbieter dein Geschäft versteht, desto relevanter wird sein Angebot sein.

Füge deine aktuelle Site-URL ein und sei ehrlich über ihre Probleme. Ich habe RFPs gesehen, die die aktuelle Website als „veraltet" beschreiben, obwohl sie eigentlich eine Schlampe mit 15 Jahren technischer Schulden ist. Ehrlichkeit hier spart jedem Zeit.

Projektübersicht

Dies ist der wichtigste Abschnitt. Deine Geschäftsziele sollten spezifisch und messbar sein:

  • ❌ „Verbessere unsere Online-Präsenz"
  • ✅ „Erhöhe den organischen Suchverkehr um 40% innerhalb von 12 Monaten nach dem Launch"
  • ❌ „Generiere mehr Leads"
  • ✅ „Erhöhe die Einreichungen des Demo-Request-Formulars von 50/Monat auf 150/Monat"

Beschränke dich auf 3-5 Ziele. Wenn alles eine Priorität ist, ist nichts eine.

Leistungsumfang

Wir treffen dies mindestens einmal im Monat: Ein Kunde sendet ein RFP mit oder ultra-detaillierten Implementierungsspezifikationen oder einem einzelnen Absatz, der sagt „wir brauchen eine neue Website". Beides ist für die Preisgestaltung nutzlos. Du musst spezifisch genug sein, damit Anbieter genau preisen können, aber flexibel genug, damit sie die beste Lösung vorschlagen können.

Hier ist ein nützliches Framework:

Element Sei spezifisch über Sei flexibel über
Seiten-Templates Wie viele unterschiedliche Layouts du brauchst Wie sie technisch gebaut werden
Features Was die Funktion für Benutzer tun sollte Wie es implementiert wird
Integrationen Welche Systeme verbunden sein müssen Die Integrationsmethode
Inhalt Volumen und Inhaltstypen CMS-Architektur
Suche Was Benutzer finden müssen Suchentechnologieauswahl

Wenn du gerade deinen Umfang schreibst und einen Sicherheitscheck möchtest, sende uns dein RFP -- wir sagen dir gerne, ob es bereit zum Versenden ist oder ob es Arbeit braucht.

Technische Anforderungen

Gebe deine Anforderungen an, nicht deine Lösungen. Wenn du ein Headless-CMS brauchst, sag „Wir benötigen ein Headless-CMS, das es nicht-technischen Editoren ermöglicht, Inhalte zu verwalten, ohne die Hilfe von Entwicklern." Sag nicht „Wir wollen Contentful", es sei denn, du hast die Evaluierung bereits durchgeführt und hast eine Lizenz.

Für Teams, die Headless-CMS-Optionen erkunden, behandelt unsere Headless-CMS-Entwicklungs- Seite die großen Plattformen und ihre Kompromisse.

Budget und Zeitrahmen

Ich kann nicht genug betonen: Füge deine Budget-Spanne ein. Hier ist warum:

Wenn dein Budget $50K-$75K ist und das Mindestprojektvolumen eines Anbieters $150K ist, hast du beide gerade zwei Wochen verschwendet. Wenn dein Budget $200K ist, aber du sagst es nicht, wirst du Angebote von $40K bis $300K erhalten und keine Möglichkeit haben, sie zu vergleichen.

Gebe eine Spanne an, keine einzelne Zahl. „$75K-$120K" sagt Anbietern genug, um angemessen zu skalieren, während Platz für kreative Lösungen bleibt.

RFP-Bewertungsmatrix

Improvisiere nicht bei der Evaluierung. Definiere deine Bewertungskriterien im Voraus und füge sie dem RFP bei, damit Anbieter wissen, was dir wichtig ist.

Hier ist eine Bewertungsmatrix-Vorlage:

Kriterium Gewicht Beschreibung
Technischer Ansatz 25% Qualität des vorgeschlagenen Architektur und Technologieauswahlr
Relevante Erfahrung 20% Portfolio-Arbeit in deiner Branche oder mit ähnlichen Anforderungen
Team und Prozess 15% Wer wird die Arbeit tatsächlich erledigen und wie werden sie mit dir arbeiten
Zeitrahmen und Durchführbarkeit 15% Realistischer Projektplan mit klaren Meilensteinen
Kosten 15% Wert im Verhältnis zum vorgeschlagenen Umfang (nicht das Billigste gewinnt)
Strategisches Denken 10% Beweis, dass sie dein Geschäft verstehen, nicht nur deine Anforderungen

Beachte, dass Kosten nur 15% ausmachen. Ich habe Organisationen gesehen, die Kosten zu 40%+ gewichten und konsequent mit dem falschen Anbieter enden. Günstige Websites sind auf lange Sicht teuer.

Häufige RFP-Fehler, die echtes Geld kosten

An zu viele Anbieter senden

Das Versenden deines RFP an 15 Agenturen verschwendet jedem Zeit, einschließlich dir. Du wirst oberflächliche Angebote bekommen, weil gute Agenturen nicht viel investieren, wenn die Chancen gegen sie sind. Shortliste auf maximal 4-6 Anbieter. Mache im Voraus deine Hausaufgaben.

Keine Fragen zulassen

Jedes RFP sollte eine Fragenphase enthalten. Veröffentliche die Fragen und Antworten an alle Anbieter. Die Fragen, die Anbieter stellen, sagen dir viel darüber, wie sie denken. Eine Agentur, die nach deinen Geschäftszielen fragt, ist wertvoller als eine, die nur nach Seitenzahlen fragt.

Festpreisangebote für unklar definierten Umfang verlangen

Wenn dein Umfang Mehrdeutigkeiten hat (und das tut er immer), zwingt ein Festpreis Anbieter dazu, ihre Schätzungen um 30-50% aufzufüllen, um Unbekanntes abzudecken. Erwägen Sie, um eine Kombination zu bitten: Festpreis für gut definierte Arbeit, Zeit-und-Material für Discovery- und Strategiephasen.

Post-Launch-Support ignorieren

Dein RFP sollte ansprechen, was nach dem Launch passiert. Wer handhabt das Hosting? Wer behebt Fehler? Wer macht Content-Updates? Eine 12-monatige Support- und Wartungsvereinbarung sollte Teil der Evaluierung sein.

Ein altes RFP kopieren

Ich habe RFPs 2026 erhalten, die immer noch Internet Explorer-Unterstützung und Flash-Kompatibilität erwähnen. Wenn dein RFP aussieht, als wäre es 2018 geschrieben worden und nur ein paar Daten wurden geändert, werden Anbieter das bemerken und dein Projekt deprioritieren.

Auswahl zwischen Agenturtypen

Nicht alle Web-Development-Partner sind gleich. Dein RFP sollte auf den richtigen Agenturtyp ausgerichtet sein.

Agenturtyp Am besten für Typisches Budget Vorteile Nachteile
Full-Service-Digitalagentur Organisationen, die Strategie + Design + Development + Marketing brauchen $100K-$500K+ Ein Anbieter für alles Höhere Gemeinkosten, kann Development outsourcen
Spezialisierte Dev-Agentur/Studio Organisationen mit klaren Anforderungen und bestehender Brand/Strategie $50K-$250K Tiefe technische Expertise, effizient Du brauchst möglicherweise separate Design/Strategie-Unterstützung
Freelancer/kleines Team Einfache Sites, enge Budgets $10K-$75K Niedrigere Kosten, direkte Kommunikation Key-Person-Risiko, begrenzte Kapazität
Enterprise-Consultancy Große Organisationen mit komplexen Anforderungen $250K-$2M+ Skalierbarkeit, Governance, Enterprise-Erfahrung Teuer, langsamer, Junior-Entwickler in deinem Projekt

Bei Social Animal fallen wir in die spezialisierte Dev-Agentur-Kategorie -- Headless-Architektur ist das, was wir tun, und wir tun es gut. Wir sind nicht für jeden die richtige Wahl, und das ist in Ordnung. Es geht darum, deine Anforderungen dem richtigen Partnertyp zuzuordnen.

Zeitrahmen und Budgeterwartungen

Hier ist, was realistische Zeitrahmen und Budgets 2026 für verschiedene Projekttypen aussehen:

Projekttyp Zeitrahmen Budget-Spanne
Marketing-Website (10-20 Seiten) 8-12 Wochen $30K-$75K
Unternehmens-Website (50-100 Seiten) 12-20 Wochen $75K-$200K
E-Commerce (< 500 SKUs) 16-24 Wochen $100K-$300K
Enterprise-Plattform 24-52 Wochen $200K-$1M+
Web-Anwendung 16-40 Wochen $150K-$500K+

Diese Spannen gehen von einer nordamerikanischen oder westeuropäischen Agentur aus. Offshore-Teams können 40-60% weniger sein, führen aber zu Kommunikations- und Qualitätsmanagemment-Overhead, die die Einsparungen oft aufzehren.

Ein paar Dinge, die Zeitrahmen häufig sprengen:

  • Inhalt. Es ist fast immer der Engpass. Wenn du keinen Inhalt vorbereitet hast, addiere 4-8 Wochen.
  • Stakeholder-Reviews. Jeder zusätzliche Genehmiger verzögert. Definiere, wer die Sign-off-Autorität in deinem RFP hat.
  • Scope Creep. „Können wir auch noch..." ist der teuerste Satz in der Web-Entwicklung.
  • Integrations-Komplexität. Das Verbinden mit Legacy-Systemen dauert immer länger als geschätzt. Immer.

Wie man Angebote bewertet

Sobald Angebote eingehen, hier ist ein Prozess, der funktioniert:

Schritt 1: Compliance-Check

Haben sie deine Anweisungen befolgt? Haben sie rechtzeitig eingereicht? Haben sie alles enthalten, worum du gebeten hast? Das geht nicht darum, starr zu sein -- es ist ein Proxy dafür, wie sie später mit Projektanforderungen umgehen werden. Wenn sie die Anweisungen eines RFP nicht befolgen können, stelle dir vor, wie sie mit einer detaillierten Spezifikation umgehen werden.

Schritt 2: Unabhängige Bewertung

Jeder Evaluator sollte Angebote unabhängig bewerten, bevor irgendeine Gruppendiskussion stattfindet. Nutze deine gewichtete Matrix. Das verhindert Gruppendenken und das Lautest-Voice-im-Raum-Problem.

Schritt 3: Shortlist-Präsentationen

Lade deine Top-2-3-Anbieter zu einer Präsentation ein. Aber hier ist das Wichtigste: Lass sie nicht einfach ihr Angebot an dich zurück präsentieren. Gib ihnen eine kleine Herausforderung oder ein Szenario zu adressieren. So etwas wie: „Unser CEO hat uns gerade gesagt, dass wir in der halben Zeit starten müssen. Wie würdest du das angehen?" Ihre Reaktion sagt dir, wie sie unter Druck denken.

Schritt 4: Referenz-Checks

Rufe die Referenzen tatsächlich an. Stelle spezifische Fragen:

  • Kam das Projekt im Budget ein?
  • Wie handelten sie Scope-Änderungen?
  • Was würdest du anders machen?
  • Würdest du sie erneut einstellen?

Diese letzte Frage ist die einzige, die wirklich wichtig ist.

Schritt 5: Vertragsverhandlung

Unterzeichne nicht einfach den ersten Vertragsentwurf. Wichtige Dinge zu verhandeln:

  • Zahlungsmeilensteine gebunden an Lieferables, nicht Daten
  • IP-Eigentumsrecht (du solltest alles besitzen)
  • Quellcode-Zugriff und Übertragungsbestimmungen
  • Garantiezeitraum (Minimum 90 Tage)
  • Ausstiegsklausel, falls die Dinge schief gehen

FAQ

Wie lang sollte ein Website-RFP sein?

10-15 Seiten ist der Sweet Spot. Alles weniger und du gibst Anbietern nicht genug zu arbeiten. Alles mehr und du spezialisierst dich über oder bist zu präskriptiv, oder du legst Informationen bei, die in ein separates Anforderungsdokument gehören. Das RFP sollte das Was und Warum kommunizieren. Das Wie ist das, was du einen Anbieter einstellen, um herauszufinden.

Sollte ich mein Budget im RFP enthalten?

Ja. Jedes Mal. Füge eine Spanne ein, nicht eine einzelne Zahl. Budgetgeheimhaltung bringt dir keinen besseren Deal -- es bringt dir wild inkonsistente Angebote, die unmöglich zu vergleichen sind. Wenn du dir Sorgen machst, dass Anbieter einfach bis zu deinem Maximum abrechnen, evaluiere basierend auf Wert im Verhältnis zu den Kosten, nicht nur auf Kosten allein.

Wie viele Anbieter sollte ich mein RFP senden?

4-6 ist ideal. Weniger als 3 und du hast nicht genug Optionen. Mehr als 8 und du wirst niederwertige Angebote bekommen, weil Agenturen weniger Anstrengung investieren, wenn die Chancen gegen sie sind. Mache Vor-Qualifikations-Forschung, bevor du das RFP sendest -- überprüfe Portfolios, prüfe Case Studies, verifiziere, dass sie in deiner Branche oder mit ähnlicher Technologie arbeiten.

Was ist der Unterschied zwischen einem RFP, RFI und RFQ?

Ein RFI (Request for Information) ist explorative -- du lernst, was möglich ist. Ein RFP (Request for Proposal) ist das, was dieser Leitfaden abdeckt -- du weißt, was du brauchst und möchtest, dass Anbieter vorschlagen, wie sie es liefern würden. Ein RFQ (Request for Quote) ist für Warenarbeit, wo der Umfang vollständig definiert ist und du nur Preise brauchst. Website-Projekte sind fast nie wirklich RFQ-geeignet, weil es immer strategische und kreative Arbeit gibt.

Sollte ich ein spezifisches CMS oder eine Technologie in meinem RFP verlangen?

Nur wenn du eine echte technische Einschränkung hast, wie bestehende Infrastruktur oder Team-Expertise. Ansonsten gebe deine Anforderungen an und lass Anbieter die Technologie empfehlen. Du stellst Experten ein -- lass sie Experten sein. Das heißt, es ist durchaus sinnvoll zu sagen, dass du einen Headless-CMS-Ansatz bevorzugst oder dass du brauchst, dass das CMS Open Source ist. Schreibe einfach das spezifische Produkt nicht vor, es sei denn, du hast bereits gründliche Evaluierung durchgeführt.

Wie gehe ich mit Anbieter-Fragen während des RFP-Prozesses um?

Setze eine spezifische Frist für Fragen (normalerweise 5-7 Geschäftstage nach RFP-Verteilung). Sammle alle Fragen, anonymisiere sie und sende die Antworten an alle teilnehmenden Anbieter gleichzeitig. Das hält den Prozess fair und stellt sicher, dass jeder die gleichen Informationen hat. Die Qualität der Anbieter-Fragen ist selbst ein nützliches Evaluierungs-Signal.

Was ist, wenn keine Angebote in mein Budget passen?

Das bedeutet normalerweise eins von drei Dingen: Dein Budget ist unrealistisch für deine Anforderungen, dein Umfang ist zu groß oder du sprichst mit dem falschen Agenturtyp. Die Lösung ist, rücksichtslos zu priorisieren. Was ist die minimale viabel Version dieses Projekts? Starten Sie das, erfahren Sie von echten Benutzerdaten, dann iterieren. Phased-Ansätze liefern fast immer bessere Ergebnisse als der Versuch, alles auf einmal zu bauen. Wende dich an uns unter /contact, wenn du einen Sicherheitscheck auf deinem Umfang und Budget möchtest.

Wann sollte ich den RFP-Prozess relativ zu meinem gewünschten Launch-Datum starten?

Arbeite rückwärts. Wenn du Q4 2026 starten möchtest, dauert der RFP-Prozess selbst 6-8 Wochen (Schreiben, Verteilung, Q&A, Evaluierung, Verhandlung). Dann addiere deinen Projektzeitrahmen. Für eine typische Unternehmens-Website sind das 12-20 Wochen. Wenn du also Q4 2026 starten möchtest, solltest du den RFP-Prozess in Q1 oder Anfang Q2 gestartet haben. Wenn du das hier liest und dein Zeitrahmen eng ist, erwägen Sie einen gestuften Ansatz oder einen Anbieter, der schnell mit einem weniger formellen Auswahlprozess umgehen kann. Oder überspringe die Förmlichkeit ganz zusammen und erhalte ein Angebot in 48 Stunden.