Fanout-CSV in Google Sheets importieren: Strings und Laufdaten erhalten
Wähle in Google Sheets Datei → Importieren → Hochladen, füge ein neues Tabellenblatt ein und setze das Trennzeichen auf Komma. Schalte vor dem Import Text in Zahlen, Daten und Formeln konvertieren aus. Unser Test vom 10. Oktober 2026 erhält so alle 110 Zellen der eigenen Fanout-CSV unverändert; die automatische Konvertierung hatte zuvor Nullen, Datumstext und Formeltext verändert.
Für die Weiterverwendung eines Auswahl-Exports in Google Sheets. Der Test verwendet synthetische Lehrstrings und die tatsächlichen Exportfunktionen der Website, keine neuen Provider-Ausgaben. Geprüft wurde die Weboberfläche mit Tabellen-Locale de_DE.
Die passende Auswahl exportierenWähle Queries aus einem beschrifteten Ergebnis aus und behalte den ursprünglichen Lauf separat. Die Testdatei unten funktioniert auch ohne neuen Lauf.Kostenloses Fanout-Tool öffnenDie Originaldatei und ihren Umfang erkennen
Der Query-Auswahl-Export hat elf Spalten: keyword, provider, model, observed_at, country, language, evidence_status, query_index, query, intent und reason. Er enthält die ausgewählten Strings und ihren Laufkontext. Quellenbeziehungen und vollständiger Response-Status stehen nicht in dieser Auswahl-CSV; bewahre den vollständigen Lauf separat auf, wenn du diese Angaben brauchst.
Für den nächsten Schritt nutze die Export-Anleitung mit Feldumfang.
Unsere Testdatei enthält neun eigene Fälle: Unicode mit Komma, Anführungszeichen, einen eingebetteten Zeilenumbruch, 00123, 2026-10-10 sowie die harmlosen Texte =1+1, +1+1, -1+1 und @SUM(1,1). Der Zeilenumbruch gehört in eine Zelle. Physische Dateizeilen zählen deshalb nicht zuverlässig die Datensätze. Ein unabhängiger CSV-Reader findet neun Datensätze und elf Felder.
Die Modellangabe synthetic-model/no-provider-call kennzeichnet die Übung. Sie wurde durch dieselben Exportfunktionen wie ein echter Auswahl-Export erzeugt. Auch der native Evidenzwert dient hier nur dem Feldtest; er macht die erfundenen Lehrstrings nicht zu beobachteten Suchen. Native intent- und reason-Felder bleiben leer. Bewahre die UTF-8-Datei mit Komma unverändert, statt sie für eine lokale Trennzeichenerwartung umzuschreiben.
Warum eine lesbare Tabelle noch kein korrekter Import ist
Im ersten Test wurde die CSV automatisch in eine native Google-Tabelle konvertiert. Unicode, Kommas, Anführungszeichen, Zeilenumbruch und Laufdaten blieben erhalten. Drei Prüffälle verloren jedoch ihren Texttyp: 00123 wurde zur Zahl 123, 2026-10-10 zu einem Datum mit internem Wert 46305 und =1+1 zu einer Formel mit Ergebnis 2.
Das sichtbare Datum sah weiterhin richtig aus. Die nativen Zellwerte zeigten den Unterschied zwischen Datum und Originalstring. Eine Suchphrase, die wie ein Datum aussieht, soll als Phrase erhalten bleiben. Ebenso darf ein Query-Text nicht allein wegen seines ersten Zeichens berechnet werden.
Nachträgliche Formatierung als Text stellt verlorene Zeichen nicht wieder her. Wenn ein Prüffall beschädigt ist, beginne erneut mit der unveränderten Datei und korrigiere die Importoptionen vor dem Laden. Der Test belegt diese konkrete Konvertierung; er behauptet nicht, jede Datei oder Locale verhalte sich gleich.
Drei Fälle, die wir tatsächlich geprüft haben
Google Sheets, Locale de_DE, 10. Oktober 2026. Der zweite Import erhält Textwerte.
| Originalstring | Automatische Konvertierung | Import ohne Konvertierung |
|---|---|---|
| 00123 | Zahl 123 | 00123 |
| 2026-10-10 | Datum, interner Wert 46305 | 2026-10-10 |
| =1+1 | Formel, Ergebnis 2 | =1+1 |
Die geprüften Importoptionen setzen
Öffne eine Google-Tabelle. Wähle Datei → Importieren → Hochladen und lade die CSV hoch. Wähle Neues Tabellenblatt einfügen, damit du den ersten Import für einen Vergleich behalten kannst. Setze das Trennzeichen ausdrücklich auf Komma.
Entferne den Haken bei Text in Zahlen, Daten und Formeln konvertieren, bevor du Daten importieren anklickst. Im englischen Dialog heißt die Option Convert text to numbers, dates, and formulas. In unserem zweiten Test wurden dieselbe Datei und diese Einstellungen verwendet; die Zellen wurden danach nicht repariert.
Das Ergebnis umfasst zehn Tabellenzeilen einschließlich Kopfzeile und elf Spalten, also 110 Zellen. Alle Werte stimmen mit dem CSV-Original überein. Alle nicht leeren nativen Zellwerte sind Strings; es gibt keine Zahlen-, Datums- oder Formeltypen. Auch query_index bleibt zunächst Text. Erst in einer getrennten Arbeitskopie wandelst du Felder gezielt um, wenn deine Auswertung das erfordert.
Die Übernahme abnehmen, dann Queries auswerten
Vergleiche zuerst Kopfzeile, Datensatzanzahl und Spaltenanzahl. Prüfe danach Café, München, die Anführungszeichen, den Zeilenumbruch innerhalb einer Zelle, die führende Null, die Datumsphrase und die Formeltexte. Unser Erwartungen-JSON enthält alle Originalzellen, nicht nur die drei auffälligen Fälle. Leere intent- und reason-Felder müssen leer bleiben; fehlende Werte dürfen beim Import nicht durch Labels ersetzt werden.
Kontrolliere auch observed_at, country, language, model und evidence_status. Ein optisch identischer Wert kann intern einen anderen Typ haben. Unsere Abnahme verglich deshalb native Zellwerte und Typen mit einem unabhängigen CSV-Reader. Der veröffentlichte Prüfbericht nennt den tatsächlich ausgeführten Weg und die fehlgeschlagene automatische Konvertierung.
Für den nächsten Schritt nutze die Anleitung zum Ergebnis-Schema.
Ein bestandener Import belegt Datenübernahme, keine Suchnachfrage. Behalte die Evidenzkennzeichnung beim Clustering oder GSC-Abgleich bei. Ein synthetischer String bleibt synthetisch. Entscheide erst nach einem Nachfrage- und Seitenabgleich, ob eine bestehende Seite ergänzt werden sollte. Die Tabellenkopie ist kein neuer Provider-Lauf und kein gültiger Handoff allein aufgrund ähnlicher Spalten.
Für den nächsten Schritt nutze das Clustering-Arbeitsblatt.
Für den nächsten Schritt nutze den getrennten GSC-Nachfragecheck.
Häufige Fragen
Diese kurzen Antworten bündeln wiederkehrende Fragen aus Tool-Nutzung und Quellenprüfung. Sie sind keine behaupteten Suchvolumen-Daten.
- Warum fehlen intent und reason bei nativen Queries?
- Die Auswahl enthält die tatsächlich offengelegten Strings. Sie erfindet keine Absicht oder Begründung. Im synthetischen Feldtest bleiben diese Spalten ebenfalls leer.
- Ist die Testdatei ein echter Provider-Lauf?
- Sie ist eine eigene synthetische CSV-Übung mit dem tatsächlichen Exportproduzenten. Die Modellangabe und das Prüfprotokoll kennzeichnen sie; es wurde kein neuer Provider-Aufruf ausgeführt.
Verwendete Quellen
Diese Quellen stützen die beschriebenen Funktionen und Grenzen. Sie belegen keine darüber hinausgehenden Aussagen.
- Betreiber-Prüfung des Sheets-CSV-Imports und nativer ZellwerteQuelle öffnen
Tatsächlicher selectedQueriesCsv-Produzent mit synthetischen Lehrstrings; Sheets-Webimport mit Komma, deaktivierter Konvertierung und Locale de_DE. Unabhängiger Vergleich bestätigt 110 Zellen und native Texttypen. Fehlgeschlagene automatische Konvertierung erhalten. Kein Provider-Aufruf oder Nachweis für andere Programme.
- Aktuelle Website-Exportverträge und ReferenzvalidierungQuelle öffnen
Draft-2020-12-Referenz für aktuelle native/modellierte Vollruns, Query-Auswahlen und lokale Vergleiche. Geprüft gegen tatsächliche Service-/Exportfunktionen mit synthetischen Provider-Stubs und negativen Semantiktests. Vollruns erhalten keine erfundene root-schemaVersion; ältere Planner- und Handoff-Formate bleiben getrennt.