SEO Tools unter OS X und macOS: Systemanforderungen selbst prüfen

Die Suche nach „SEO Tools OS X" führt fast immer zu Bestenlisten. Die eigentliche Frage ist aber eine andere und sie kommt zeitlich vorher: Läuft dieses Werkzeug auf diesem Mac überhaupt, und wenn ja, unter welchen Bedingungen? Das ist keine Geschmacksfrage, sondern eine Systemfrage mit überprüfbaren Antworten. Wer sie beantworten kann, braucht keine Empfehlung, sondern nur die Herstellerseite und ein Terminalfenster.

Diese Seite behandelt ausschließlich die Plattformseite: Namensverwirrung, Bereitstellungsmodell, Prozessorarchitektur, Rosetta 2, Installationsformate, Gatekeeper, Terminalarbeit und die Auswege, wenn ein Programm macOS gar nicht unterstützt. Werkzeuge tauchen hier nur als Beleg für Plattformverhalten auf, nicht als Auswahlvorschlag.

OS X und macOS sind dasselbe System in zwei Namensphasen

Apple hat den Namen OS X mit der 2016 vorgestellten Version 10.12 Sierra in macOS geändert. Systemanforderungen, die noch von „OS X" sprechen, meinen deshalb dasselbe Betriebssystem, stammen aber aus einer älteren Phase. Der Name ist damit kein Kompatibilitätssignal, sondern ein Altersindiz.

Praktisch heißt das: Eine Angabe wie „OS X 10.11 oder neuer" wurde formuliert, als es weder Apple Silicon noch die heutige Notarisierungspflicht gab. Sie sagt nichts darüber, ob das Programm auf einem aktuellen Mac startet. Bei jeder Angabe in dieser Schreibweise gehören drei Zusatzfragen dazu: Wann erschien der Build, wann wurde er zuletzt aktualisiert, und welche Prozessoren nennt der Hersteller ausdrücklich?

Die erste Frage lautet nicht „welches Tool", sondern „wo läuft es"

Ob macOS überhaupt eine Rolle spielt, entscheidet das Bereitstellungsmodell. Es gibt drei relevante Klassen und sie stellen völlig unterschiedliche Anforderungen.

Browserbasierte Anwendungen. Hier läuft die Verarbeitung auf den Servern des Anbieters, der Mac liefert nur die Anzeige. Google Search Console und Google Analytics sind genau so gebaut: Beide laufen vollständig im Browser und setzen weder eine Installation noch ein bestimmtes Betriebssystem voraus. Auch Lighthouse gehört in diese Klasse, weil es in die Entwicklertools von Google Chrome integriert ist und unter macOS ohne separate Installation für Performance- und SEO-Audits genutzt werden kann. Die technische Grenze ist in allen drei Fällen die Browserversion, nicht die Systemversion. Das erklärt, warum ein großer Teil des SEO-Marktes gar keine Plattformfrage kennt.

Native Desktop-Programme. Erst hier wird macOS zur harten Bedingung. Der Screaming Frog SEO Spider zeigt das Muster gut: Er wird neben Windows auch als macOS-Version angeboten und ist damit einer der wenigen verbreiteten SEO-Desktop-Crawler mit nativem Mac-Build. Wichtig ist die Trennung der Grenzen. Dass die kostenlose Version maximal 500 URLs pro Website crawlt, ist eine Lizenzgrenze und hat mit dem Betriebssystem nichts zu tun. Plattformgrenzen und Produktgrenzen werden in Testberichten regelmäßig vermischt, bei der Systemprüfung dürfen sie es nicht.

Kommandozeilenwerkzeuge. Sie haben keine grafische Oberfläche, werden über die Shell gestartet und lassen sich in Skripte einbinden. Ihre Kompatibilität hängt selten an macOS selbst, sondern an Laufzeitumgebung, Bibliotheken und Architektur.

Linux spielt in diesem Zusammenhang nur insofern eine Rolle, als viele dieser Kommandozeilenwerkzeuge dort ebenfalls laufen. Für die Mac-Prüfung ändert das nichts.

Intel oder Apple Silicon: die härteste Grenze

Apple kündigte im Juni 2020 den Wechsel der Mac-Prozessoren von Intel auf eigene Apple-Silicon-Chips an, die ersten Macs mit M1 kamen im November 2020 auf den Markt. Seitdem ist „für Mac" keine eindeutige Aussage mehr. Downloads werden typischerweise so benannt:

• x86_64 oder Intel für ältere Macs
• arm64 oder Apple Silicon für Macs mit M-Chip
• Universal oder Universal 2 für Builds, die beide Architekturen enthalten

Die eigene Seite der Gleichung klärt ein Befehl:

uname -m
sw_vers -productVersion

Die erste Zeile liefert arm64 auf Apple Silicon und x86_64 auf Intel, die zweite die exakte Systemversion. Beide Werte gehören notiert, bevor die Herstellerseite geöffnet wird. Bei einem bereits installierten Programm lässt sich die Gegenprobe machen:

lipo -archs "/Applications/Beispiel.app/Contents/MacOS/Beispiel"

Ausgegeben werden die tatsächlich enthaltenen Architekturen. Das ist verlässlicher als die Marketingzeile auf der Downloadseite, die bei älteren Produkten oft seit Jahren unverändert steht.

Rosetta 2 übersetzt, aber es repariert nichts

Rosetta 2 übersetzt für Intel-Prozessoren kompilierte Mac-Programme automatisch, damit sie auf Apple Silicon ausgeführt werden können. Die Übersetzung läuft im Hintergrund, beim ersten Start eines betroffenen Programms bietet macOS die Installation an. Das nimmt der Architekturfrage viel Schärfe, aber es hebt sie nicht auf.

Rosetta 2 löst genau ein Problem: den Befehlssatz. Alles andere bleibt bestehen. Ein Programm scheitert weiterhin, wenn es eine entfernte Systemschnittstelle nutzt, alte Systemerweiterungen oder Treiber voraussetzt, mitgelieferte Intel-Komponenten nicht findet oder vom Hersteller für die aktuelle macOS-Version nicht mehr freigegeben ist. Eine ausdrückliche Herstellerangabe „läuft unter Rosetta 2" ist deshalb etwas völlig anderes als die eigene Vermutung, dass Intel-Software schon irgendwie starten wird.

Für Prozesse, die dauerhaft laufen sollen, ist die Zusatzfrage entscheidend: Gibt es inzwischen einen nativen oder universellen Build? Übersetzte Programme kosten Startzeit und Rechenleistung, und ihr Support endet erfahrungsgemäß früher.

DMG, PKG und ZIP sind Verpackungen, keine Kompatibilitätsaussage

Mac-Downloads kommen als DMG, PKG oder ZIP. Diese Formate beschreiben den Installationsweg, nicht die Lauffähigkeit. Ein DMG-Image ist ein einbindbares Speicherabbild, das im Finder wie ein zusätzliches Laufwerk erscheint; die App wird daraus in den Ordner „Programme" gezogen, danach kann das Abbild ausgeworfen und die Datei gelöscht werden. Ein PKG-Paket führt durch einen Installationsdialog, legt Dateien an mehreren Stellen im System ab und verlangt dafür häufig ein Administratorkennwort. Ein ZIP-Archiv wird nur entpackt, das Verschieben in den Programme-Ordner bleibt Handarbeit.

Für die Prüfung folgt daraus: Vor dem Öffnen zählen Dateiname, Anbieter, Downloadquelle und eine gegebenenfalls veröffentlichte Prüfsumme. Ein DMG ist nicht deshalb vertrauenswürdig, weil es das übliche Mac-Format ist. Und ein PKG verdient mehr Aufmerksamkeit als ein DMG, weil es tiefer ins System schreiben darf.

Gatekeeper und Notarisierung: warum ein legitimes Tool blockiert wird

Gatekeeper prüft, ob aus dem Internet geladene Software von einem identifizierten Entwickler stammt. Seit macOS 10.15 Catalina verlangt Apple für außerhalb des Mac App Store verteilte Software eine Notarisierung, nicht notarisierte Programme werden standardmäßig blockiert. Das trifft SEO-Werkzeuge überdurchschnittlich oft, weil viele davon von kleinen Anbietern oder aus Einzelprojekten stammen.

Eine Blockade ist deshalb kein Schadsoftwarebefund. Sie bedeutet zunächst nur, dass der Build den Apple-Prozess nicht durchlaufen hat. Das ändert nichts daran, dass die Meldung nicht reflexhaft weggeklickt werden sollte. Sinnvoll sind fünf Fragen: Stammt die Datei direkt von der offiziellen Herstellerseite? Ist der Download für die eigene macOS-Version vorgesehen? Ist der Entwickler in den Dateiinformationen erkennbar? Gibt es aktuelle Installationshinweise des Herstellers? Wurde die Datei möglicherweise über eine Drittseite verteilt?

Der Systemstatus lässt sich auch direkt abfragen:

spctl --assess --type execute --verbose "/Applications/Beispiel.app"
codesign -dv --verbose=2 "/Applications/Beispiel.app"

Der erste Befehl zeigt, wie Gatekeeper das Programm bewertet, der zweite, wer es signiert hat. Gatekeeper global abzuschalten ist keine Lösung, sondern der Verzicht auf die Prüfung. Eine gezielte Einzelfreigabe über die Systemeinstellungen bleibt kontrollierbar und nachvollziehbar.

Welche SEO-Arbeit tatsächlich im Terminal stattfindet

Das Terminal ist unter macOS kein Notbehelf, sondern für einen Teil der technischen SEO-Arbeit der direkteste Weg: Statuscodes und Weiterleitungsketten prüfen, Header lesen, DNS abfragen, große Exportdateien filtern, wiederholbare Prüfungen als Skript ablegen.

curl -I https://www.example.com/
curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://www.example.com/

Die erste Zeile liefert die Antwortheader einer einzelnen URL, die zweite folgt der gesamten Weiterleitungskette und gibt am Ende Statuscode und Zieladresse aus. Vor jedem Skript lohnt der Blick auf die vorhandenen Laufzeitumgebungen:

python3 --version
java -version
node --version

Nicht jede davon ist auf einem frischen Mac vorhanden, und manche Werkzeuge verlangen eine bestimmte Hauptversion. Homebrew ist ein Paketmanager für macOS, über den sich solche Kommandozeilenwerkzeuge nachinstallieren lassen. Zwei Punkte gehören dabei geprüft: ob das jeweilige Projekt Apple Silicon unterstützt, und in welches Verzeichnis installiert wird. Auf Apple-Silicon-Systemen nutzt Homebrew üblicherweise einen anderen Präfixpfad als auf Intel-Macs, was Skripte mit fest verdrahteten Pfaden zuverlässig zerlegt. Und Installationsbefehle von fremden Seiten, besonders solche mit sudo, gehören gelesen, bevor sie ausgeführt werden.

Wenn es keine macOS-Version gibt

Fehlt ein Mac-Build, gibt es drei Auswege mit klar unterschiedlichen Kosten.

Ein Webzugang des Anbieters umgeht die Plattformfrage vollständig, verschiebt sie aber auf andere Ebenen: lokale Dateipfade, Zugriff auf interne Systeme und Datenschutz müssen dann getrennt betrachtet werden.

Eine virtuelle Maschine führt ein anderes Betriebssystem innerhalb von macOS aus. Auf Apple Silicon ist dabei die Architektur des Gastsystems entscheidend, denn ein für Intel kompiliertes Programm startet nicht in jeder ARM-basierten virtuellen Umgebung ohne zusätzliche Übersetzungsschicht. Diese Kombination gehört vor der Lizenzentscheidung getestet, nicht danach.

Ein entfernter Rechner verlagert das Problem an einen Ort, an dem es nicht existiert. Das Programm läuft auf einem anderen System, der Mac ist nur Zugangspunkt. Rechenleistung, Lizenz, Datenhaltung und Netzzugriffe liegen dann dort, was für Crawler mit hohem Ressourcenbedarf oft der stabilere Aufbau ist.

Kompatibilitätsschichten sind der unsicherste Weg, besonders bei Software mit Treibern, enger Systemintegration oder automatischen Updates. Für produktive Abläufe gilt: dokumentieren und nach jedem Update erneut prüfen.

Die Systemprüfung in acht Schritten

1. Eigene macOS-Version mit sw_vers -productVersion feststellen.
2. Architektur mit uname -m bestimmen.
3. Bereitstellungsmodell klären: Browser, Desktop oder Terminal.
4. Auf der Herstellerseite Mindestversion und ausdrücklich genannte Architektur suchen.
5. Prüfen, ob der Build nativ, universal oder nur für Intel vorliegt, und ob Rosetta 2 offiziell genannt wird.
6. Laufzeitumgebungen und deren geforderte Versionen ermitteln.
7. Installationsformat, Signierung und Notarisierung kontrollieren.
8. Vor dem produktiven Einsatz einen kleinen, begrenzten Testlauf durchführen.

Damit wird aus einer Suchanfrage eine Prüfung mit einem eindeutigen Ergebnis. Über die Eignung eines Werkzeugs für den Mac entscheidet nicht seine Bekanntheit, sondern wo es ausgeführt wird, für welche Architektur es gebaut wurde, welche Systemversion es verlangt und ob sein Installationsweg nachvollziehbar ist.