> For the complete documentation index, see [llms.txt](https://speedyindex-1.gitbook.io/speedyindex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://speedyindex-1.gitbook.io/speedyindex-docs/de/wie-viele-neue-backlinks-pro-tag-einen-verteilungsplan-aufstellen.md). # Wie viele neue Backlinks pro Tag? Einen Verteilungsplan aufstellen Wie viele neue Backlinks pro Tag? Warum es keine offizielle Zahl gibt und wie man neue Links trotzdem sinnvoll über mehrere Tage verteilt und kontrolliert. Die Frage taucht in fast jedem Linkbuilding-Projekt auf: Ist es riskant, 300 neue Links an einem Tag zu veröffentlichen oder zur Indexierung einzureichen? Gibt es eine „sichere" Zahl pro Tag? Die ehrliche Antwort lautet: Google nennt keine solche Zahl. Trotzdem gibt es gute, praktische Gründe, neue Links über mehrere Tage zu verteilen. Dieser Leitfaden erklärt, welche das sind, und wie ein einfacher Plan aussieht. ## Was Google tatsächlich sagt Die Spam-Richtlinien von Google definieren Linkspam sinngemäß als das Erstellen von Links, deren Hauptzweck die Manipulation von Suchrankings ist. Als Beispiele nennt Google unter anderem: * Links gegen Geld, Waren oder Leistungen tauschen, wenn sie Ranking-Signale weitergeben, * übermäßigen Linktausch oder Partnerseiten, die nur der Querverlinkung dienen, * automatisierte Programme oder Dienste, die Links zur eigenen Website erstellen. Bezahlte Links sind nach diesen Richtlinien zulässig, wenn sie mit `rel="nofollow"` oder `rel="sponsored"` gekennzeichnet sind. Daraus folgt: Entscheidend ist **wie** Links entstehen, nicht nur **wie schnell**. Ein langsam verteilter Linkkauf bleibt ein Linkkauf. Ein Tempo-Plan ist deshalb kein Trick gegen Google, sondern ein Werkzeug, um die eigene Arbeit kontrollierbar zu machen. ## Warum eine Verteilung trotzdem sinnvoll ist **Kontrolle.** Wenn 20 Links pro Tag live gehen, lässt sich jede Platzierung prüfen: Ist die Seite erreichbar, steht der Link im Text, stimmt das `rel`-Attribut? Bei 300 Links an einem Tag bleibt das meist liegen. **Messbarkeit.** Wer Links in Paketen einreicht, kann pro Paket nachverfolgen, wie viele davon nach zwei und nach vier Wochen im Index sind. So erkennt man schwache Quellen früh. **Budget und Limits.** Index-Checks und Indexierungsdienste haben Tageslimits oder Kosten pro URL. Eine Verteilung hält die Ausgaben planbar. **Natürlichere Muster.** Neue Inhalte, Erwähnungen und Gastbeiträge entstehen in der Realität auch nicht alle am selben Tag. Ein gleichmäßiger Plan spiegelt eher wider, wie echte Projekte wachsen. ## So stellt man einen Plan auf 1. **Liste bereinigen.** Duplikate, tote Seiten und Links mit Tracking-Parametern zuerst entfernen. 2. **Nach Domain gruppieren.** Mehrere Links von derselben Domain nicht am selben Tag einplanen. 3. **Zeitraum festlegen.** Zum Beispiel 14 Tage für 280 Links ergibt 20 pro Tag. 4. **Prioritäten setzen.** Die stärksten Platzierungen an den Anfang, damit sie zuerst geprüft werden. 5. **Feste Prüftermine einplanen.** Für jedes Tagespaket einen Check nach 14 und nach 28 Tagen notieren. Statt das in einer Tabelle von Hand zu rechnen, kann man mit einem kleinen Planer [neue Links über mehrere Tage verteilen](https://indexfixtools.com/de/drip-feed-planner/) und den Zeitplan als Liste exportieren. ## Beispiel | Zeitraum | Links gesamt | Pro Tag | Prüfung | | --------- | ------------ | ------- | ---------------------------------- | | Woche 1–2 | 280 | 20 | Tag 14 und Tag 28 nach Einreichung | | Woche 3–4 | 140 | 10 | Tag 14 und Tag 28 nach Einreichung | Die Zahlen sind kein Richtwert von Google, sondern ein Beispiel für einen Plan, der sich mit vertretbarem Aufwand prüfen lässt. ## Typische Fehler * **Nach einer „magischen Zahl" suchen.** Es gibt keine offiziell sichere Menge pro Tag. * **Tempo mit Qualität verwechseln.** Schwache oder gekaufte Links werden durch Verteilung nicht besser. * **Ohne Nachkontrolle einreichen.** Ohne Prüftermine weiß man nach einem Monat nicht, welche Pakete funktioniert haben. * **Mehrere Links derselben Domain bündeln.** So fällt eine schwache Quelle gleich mehrfach ins Gewicht. ## Kurze Checkliste * [ ] Linkliste bereinigt und nach Domain gruppiert * [ ] Zeitraum und Tagesmenge festgelegt * [ ] Stärkste Platzierungen zuerst eingeplant * [ ] Prüftermine nach 14 und 28 Tagen notiert * [ ] Nur Links, die den Spam-Richtlinien entsprechen ## Quellen * Google Search Central: [Spam-Richtlinien für die Google-Websuche](https://developers.google.com/search/docs/essentials/spam-policies?hl=de) * Google Search Central: [Ausgehende Links für Google kennzeichnen](https://developers.google.com/search/docs/crawling-indexing/qualify-outbound-links?hl=de) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://speedyindex-1.gitbook.io/speedyindex-docs/de/wie-viele-neue-backlinks-pro-tag-einen-verteilungsplan-aufstellen.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.