Konfiguration

Konfigurationsdateien

Folgende Konfigurationsdateien werden von smart.finder verarbeitet:

  • WEB-INF/classes/default-application.properties (NICHT EDITIEREN)
    In dieser Datei befinden sich alle Konfigurationsoptionen von smart.finder mit ihren Standardwerten.

  • WEB-INF/classes/custom-application.properties
    Wenn Sie das Arbeitsverzeichnis data.directory.location ändern, müssen Sie diese Datei anpassen. Alle weiteren Anpassungen erfolgen in der nachfolgenden Datei.

  • [data.directory.location]/application.properties
    Das Bearbeiten dieser Datei ist der empfohlene Weg Konfigurationsänderungen vorzunehmen.
    Standardmäßig ist ${user.home}/.smartfinder das Arbeitsverzeichnis data.directory.location von smart.finder. Die application.properties wird nicht automatisch erstellt. Als Vorlage können Sie die Datei WEB-INF/classes/application.properties nutzen. Es wird empfohlen, nur die Einstellungen in der Datei zu belassen, die geändert wurden.

Das Format der Konfigurationsdateien muss dem Java Properties Dateiformat entsprechen.

Beispiel Properties Datei
# Die Dateien müssen UTF-8 kodiert sein, sonst können Umlaute zu Fehlern führen!
# Am sichersten ist die Kodierung von Umlauten in Unicode-Syntax z.B: ä = \u00E4 (vgl. http://0xcc.net/jsescape/)

# Kommentare erfolgen mit vorangestellter Raute

# Allgemeine Syntax:
key = value

# Ein Value kann einen anderen Key referenzieren
key1 = http://${key.with.server}/test
Starten Sie nach Änderungen an einer der Konfigurationsdateien die Web-Applikation oder alternativ den kompletten Tomcat Server neu.

Konfigurationsparameter

In diesem Abschnitt werden die Parameter beschrieben, die am häufigsten in einer Standardinstallation verändert werden müssen. Weitere Parameter sind in der Datei WEB-INF/classes/default-application.properties in Kommentaren beschrieben.

Sowohl im Client als auch im Server liegen diese Konfigurationsdateien vor. In der folgenden Auflistung wird nicht danach unterschieden. Halten Sie sich an die jeweilige default-application.properties, um die Parameter für die jeweilige Web-Applikation zu verändern.
data.directory.location

Arbeitsverzeichnis, in dem map.apps-Daten (z.B. eine HSQL-Datenbank) lokal gespeichert werden.

Für den Fall, dass der Tomcat-Server als Windows-Dienst betrieben wird, liegt der .smartfinder Ordner im Nutzerverzeichnis des Tomcat-Nutzers, der den Dienst gestartet hat. Pfad-Trenner müssen entweder als / oder \\ angegeben werden.

Standardwert: $\{user.home\}/.smartfinder

proxy.allowedServerUrls

Liste von URLs, auf die das Proxy Servlet zugreifen darf.

smart.finder stellt ein integriertes Proxy Servlet bereit. Ein direkter Zugang zu bestimmten Ressourcen, die nur unter einer anderen Domänen erreichbar sind, ist aufgrund von Sicherheitsbeschränkungen innerhalb von JavaScript untersagt. Dieser Parameter definiert entsprechende Ausnahmen. Nach jeder URL muss ein ; gesetzt werden. Jede Zeile, mit Ausnahme der Letzten, endet mit einem \.

finder.service.url

Context-Name des smart.finder Servers.

Wurde der Name bei der Installation des smart.finder Servers geändert, so muss hier der aktuelle Name eingetragen werden.

Standardwert: /smartfinder-search

solr.solr.home

Verzeichnispfad zum solr.home.

Der Pfad kann absolut oder relativ angegeben werden. Es können auch Platzhalter verwendet werden, die durch den Web Container aufgelöst werden.

Beispiel:

solr.solr.home = ${catalina.base}/webapps/smartfinder-search/WEB-INF/solr.home
solr.default.core.name

Der Standardindex des Servers.

Dieser Index wird verwendet, wenn bei der Job-Erstellung im Manager kein Index angegeben wird.

Standardwert: core0

Security

security.mode

Absicherungsmodus des administrativen Bereichs des smart.finders.

Der Zugriff auf die administrativen Bereiche des smart.finder ist geschützt (Standardwert: INTEGRATED). Der Modus ONLY_AUTHN kann nur in Verbindung mit security.manager Enterprise Edition verwendet werden. Der Modus IDENTITY kann nur in Verbindung mit dem Identity Service verwendet werden.

Bitte beachte die zu den Modi gehörenden zusätzliche Parameter.

Erlaubte Werte: INTEGRATED, IDENTITY, ONLY_AUTHN
Standardwert: INTEGRATED

security.responseHeaders.common

Liste von HTTP-Antwortheadern.

Um eine Liste von Antwortheadern zu definieren, verwenden Sie folgende Syntax: <header-name>:<header-value>,<header-name>:<header-value>. Dabei gilt:

  • <header-name> ist der Name eines HTTP-Headers. Dieser muss mit einem Großbuchstaben beginnen

  • <header-value> ist der Wert eines HTTP-Headers

Die Header werden an jede Antwort des smart.finder Backend-Services geschrieben. Die Konfiguration sollte nur bei besonderen Sicherheitsanforderungen verändert werden.

Standardmäßig werden folgende Header ergänzt:

X-Content-Type-Options:nosniff

Definiert, dass der Browser Serverantworten nur auf Basis des Content-Type-Headers interpretieren darf.
Genauere Informationen finden Sie unter X-Content-Type-Options .

Strict-Transport-Security:max-age=604800

Definiert, dass der Browser sich merken soll, dass der Host für 7 Tage (604800 Sekunden) nicht mehr per HTTP angefragt werden darf.
Wird nur angewandt, wenn map.apps via HTTPS aufgerufen wird. Genauere Informationen finden Sie unter Strict-Transport-Security .

Standardwert: X-Content-Type-Options:nosniff,Strict-Transport-Security:max-age=604800

Zusätzliche Parameter für den Modus INTEGRATED

Der Modus INTEGRATED kann über den folgenden Parametersatz näher spezifiziert werden:

security.user.admin.name

Nutzername im Plaintext.

security.user.admin.pw

Passwort des Nutzers.

Diese muss entsprechend der gewählten Kodierung beschrieben sein.

security.user.pwenc

Kodierung des Passworts.

Dieses kann plain (keine Kodierung) oder mittels MD5 (Message-Digest Algorithm 5) bzw. SHA-1 (secure hash algorithm) erfolgen. Es existieren Webdienste, die bei der Erzeugung mittels MD5 oder SHA-1 verschlüsselter Passwörter unterstützen.

Erlaubte Werte: plain, MD5, SHA-1

security.user.use_mapped_pass

Gibt an, ob eine andere Passwortkodierung als plain gewählt wurde.

Erlaubte Werte: true, false

security.ssl.trustAny

Gibt an, ob selbst signierte Zertifikate bei HTTPS-Verbindungen unterstützt werden.

Erlaubte Werte: true, false
Standardwert: false

Zusätzliche Parameter für den Modus IDENTITY

Der Modus IDENTITY kann über den folgenden Parametersatz näher spezifiziert werden:

security.login.base

Basis URL des Identity Service.

esri.api.arcgisPortalUrl

URL auf die verwendete ArcGIS Online Organisation.

Der Wert muss mit der Konfiguration für security.oauth.provider.arcgis.url im Identity Service übereinstimmen.

Zusätzliche Parameter für den Modus ONLY_AUTHN

Der Modus ONLY_AUTHN kann über den folgenden Parametersatz näher spezifiziert werden:

security.administration.url

URL zum security.manager Administration Service

security.keystore.location

Pfad zur Keystore-Datei

Dies ist der Pfad zur Keystore-Datei, welche von security.manager und smart.finder genutzt wird.

Mailing

mailing.host

Rechnername, auf dem ein SMTP Server für das Versenden von E-Mails zur Verfügung steht.

mailing.port

SMTP Port auf dem SMTP Host-Rechner.

mailing.username

Nutzername für den SMTP Server.

mailing.password

Passwort für den SMTP Server.

mailing.senderaddress

Antwortadresse für den E-Mail Versand.

mailing.locale

Spracheinstellung für das Versenden von E-Mails.

Erlaubte Werte: de, en

Logging

Es stehen folgende Konfigurationsparameter zur Anpassung des Loggings zur Verfügung:

logging.logger.level

Detailgrad des Logs.

Mögliche Werte: TRACE, DEBUG, INFO, WARN, ERROR
Standardwert: INFO

logging.output.location
Ersetzt seit 2.0.8
Verwenden Sie stattdessen logging.file.location
logging.file.location

Ort, an dem die Log-Datei gespeichert wird.

Der Standardwert entspricht dem logs Verzeichnis des Tomcat. Mit dem Wert ${data.directory.location}/logs wird die Log-Datei im Arbeitsverzeichnis von smart.finder erzeugt.

Standardwert: ${catalina.base}/logs

logging.file.prefix

Dieser Parameter definiert den Namen der Log-Dateien.

Um den Log-Dateien den URL-Kontextpfad der ct-smartfinder-Installation voranzustellen (zum Beispiel smartfinder), verwenden Sie den Wert ${webcontext.name}.

Standardwert: ct-smartfinder

Weitere Logging-Parameter sind in der Datei default-application.properties beschrieben, z.B. zum Aktivieren oder Deaktivieren des Loggings in die Konsole, in Log-Dateien oder mittels GELF.

Ab der Version 2.4.0 wird Wildcard- und Phrasensuche durchgängig unterstützt. Per Default ist diese aktiviert.

Änderung des Speicherorts des Index

In der Standardauslieferung werden die Indexe von smart.finder unter folgendem Pfad abgelegt:

%TOMCAT%\webapps\smartfinder-search\WEB-INF\solr.home

In der hier lokalisierten Unterverzeichnissen werden die Indexe der einzelnen Cores gespeichert. Um den Speicherort der Indexe zu ändern, müssen Sie den Wert der Variable solr.solr.home in der Datei application.properties anpassen.

solr.solr.home=[absoluter Pfad]

Nach einem Neustart werden die Indexe in diesem Verzeichnis abgelegt.

Suchergebnisse sortieren

In der Standardkonfiguration wird das Ergebnis einer Suchanfrage an den Index anhand der Trefferwahrscheinlichkeit Score sortiert. Sollen Ergebnisse im Gegensatz dazu nach einem Feld (z.B. Titel) alphabetisch sortiert werden, so muss die Schema-Konfiguration dieses Feldes eindeutig sein. Das heißt, Felder, die von Analyzern benutzt werden (unter anderem alle Felder vom Typ text), können nur für die Sortierung von Suchergebnissen benutzt werden, wenn der Analyzer genau einen einzigen Ausdruck generiert. Weitere Einschränkungen für das Sortieren finden Sie in der Solr Dokumentation . Um dennoch auf solchen Feldern sortieren zu können, müssen diese Felder im Schema mittels copyField in ein neues Feld mit einem anderen Typ kopiert werden.

Nachfolgend ein Beispiel für das Feld name:

  1. Ändern Sie die schema.xml

    Angepasste schema.xml
    <fields>
    [...]
    <field name="name" type="text" indexed="true" stored="true" required="false" multiValued="false"/>
    <copyField source="name" dest="name_string"/>
    <field name="name_string" type="string" indexed="true" stored="true" required="false" multiValued="false"/>
    [...]
</fields>

  2. Speichern Sie die Datei.

  3. Starten Sie den smart.finder Server oder Apache Tomcat neu, damit die Änderungen wirksam werden.

Konfiguration von Synonymen der Facettenwerte

Manchmal sind die in der Datenbank verwendeten Begriffe für eine Sache nicht einheitlich. Sie sollten Synonyme entsprechend der unten stehenden Anleitung zusammen fassen.

Beispielsweise beziehen sich die Werte shape und Shapefile beide auf dasselbe Format. Sie können die Werte der Facette Format immer als SHP in der Nutzeroberfläche anzeigen lassen.

Um dies zu konfigurieren sind zwei Schritte nötig.

Schritt 1: Abbildung von Werten auf Synonyme

Pflegen Sie die Synonyme in der Konfigurationsdatei /smartfinder-search/WEB-INF/solr.home/core0/conf/lang/synonyms.txt ein.

Für das obige Beispiel müssen Sie die folgende Zeile ergänzen: shape, Shapefile => SHP

Die Werte vor dem Pfeil werden zusätzlich im Index abgelegt. Sie können nach shape, Shapefile sowie SHP suchen. Im Attributfilter wird immer SHP angezeigt. Ein Filter auf dem Wert SHP schließt dann alle seine Synonyme mit ein.

Schritt 2: Synonym-Index-Verknüpfung

Verknüpfen Sie nun die Synonyme mit dem Feld im Index.
Öffnen Sie dazu die Datei /smartfinder-search/WEB-INF/solr.home/core0/conf/schema.xml und suchen das Feld, für dessen Werte Sie die Synonyme definieren.

In unserem Beispiel handelt es sich um das Feld format:

<field name="format" type="string" indexed="true" stored="true" required="false" multiValued="true"/>

Legen Sie darunter nun ein neues Feld mit dem Typ text_synonym, beispielsweise dem Namen format_facet und den folgenden Attributen an:

<field name="format_facet" type="text_synonym" indexed="true" stored="true" required="false" multiValued="true"/>

Weisen Dokumente beim Indexieren einen Wert für das Feld format auf, wird dieser auch in das Feld format_facet kopiert. Dieses Feld kann als Facette genutzt werden und muss dann auch in der Client-Konfiguration facetFields konfiguriert werden, siehe Auswahl und Reihenfolge von Filterattributen.

Optimierung für Suchmaschinen (SEO)

Dokumente, die im Index gespeichert sind, können für Internet-Suchmaschinen wie Google oder Bing auffindbar gemacht werden. In diesem Abschnitt werden die erforderlichen Schritte für die Konfiguration von smart.finder beschrieben.

Erzeugung einer Sitemap

Um Web Crawlern zu ermöglichen, Detailinformationen zu Dokumenten in smart.finder zu finden, müssen ihnen die URLs bekannt sein, die zu den Webseiten mit diesen Informationen führen. Da diese Seiten im smart.finder dynamisch erzeugt werden, werden Sitemaps verwendet, um diese zu listen.

Sitemaps sind XML-Dateien, in denen die URLs zu den Detailseiten abgelegt sind. Diese Dateien können von Suchmaschinen ausgelesen werden. Ist die Sitemap-Funktion aktiviert, erzeugt smart.finder diese XML-Dateien automatisch und speichert diese auf dem Server, auf dem smart.finder betrieben wird.

Eine Übersicht über das Protokoll, das für Sitemaps verwendet wird, finden Sie hier .

Konfigurationsparameter

Die Konfiguration der Sitemap-Erzeugung erfolgt über folgende Parameter:

sitemap.enabled

Aktiviert/Deaktiviert die automatische Erzeugung der Sitemap.

Mögliche Werte: true, false
Standardwert: false

sitemap.executionTime

Ein Cron-String der festlegt, zu welchen Zeiten die Sitemap mit den aktuellen Dokumenten neu erzeugt wird.

Standardwert: 0 0 6 * * ? (Bedeutung: Jeden Tag um 6 Uhr morgens)

sitemap.coreName

Der Name des Index, für den die Sitemap erstellt werden soll.

Standardwert: ${solr.default.core.name}

sitemap.queryString

Ein optionaler Filterausdruck, der angewendet wird, um die Menge der Dokumente einzuschränken, die in die Sitemap aufgenommen werden sollen. Dieser Filter wird zur Abfrage der smart.finder search Komponente bei der Erzeugung der Sitemap ausgeführt. Alle Dokumente, die dem Filter entsprechen, werden in die Sitemap aufgenommen. Die Syntax des Filterausdrucks entspricht dem des Standard Query Parsers von Apache Solr.

Standardwert: *:*

sitemap.lastModifiedFields

Eine sortierte Liste mit Namen der Attribute, die das Datum der zuletzt erfolgten Änderung eines referenzierten Dokuments enthalten.

In der XML-Datei der Sitemap kann zusätzlich zu jeder URL das optionale Element lastmod mit angegeben werden, welches einen Datumswert enthält. Dieses Datum drückt die Aktualität der Ressource aus. Es gibt eine Reihe von Feldern im Index, die als Quelle für dieses Datum infrage kommen, z.B. created oder modified. Welches Feld für das Aktualitätsdatum verwendet werden soll, hängt vom konkreten Inhalt des Index ab.

Beispiel: Der Wert des Parameters sitemap.lastModifiedFields lautet created, modified. Bei der Erstellung der Sitemap wird im aktuellen Dokument zunächst geprüft, ob das Feld created vorhanden ist. Ist dies der Fall, wird dessen Wert für das Element lastmod in der Sitemap verwendet. Ist das Feld nicht vorhanden, wird auf das zweite Feld in der Liste (hier: modified) geprüft usw. Ist keines der Felder vorhanden, wird das Element lastmod in der Sitemap für das aktuelle Dokument nicht erzeugt.

sitemap.maxEntries

Maximale Anzahl von URLs pro Sitemap-Datei.

Jede Sitemap Datei darf maximal 50.000 Einträge beinhalten oder im unkomprimierten Zustand 50 MB groß sein. Wird die hier angegebene maximale Anzahl von Einträgen in einer Sitemap überschritten, wird automatisch eine neue Sitemap-Datei für die weiteren Einträge erzeugt. Bei mehr als einer Sitemap-Datei wird zudem eine Datei sitemap_index.xml im gleichen Verzeichnis angelegt, welche auf die einzelnen Sitemap-Dateien verweist.

Standardwert: 45000

sitemap.baseUrl

Gibt die Basis-URL des Servers an, welcher die Sitemap-Dateien ausliefert. In der Regel ist dies die URL, unter der der smart.finder Client zu erreichen ist, z.B. https://[HOST]:[PORT]/smartfinder.

sitemap.storageLocation

Der Speicherort der Sitemap-Datei im Dateisystem. Es bietet sich an, nach Möglichkeit hier direkt das Root-Verzeichnis der smart.finder Applikation anzugeben, damit die Dateien direkt über ${sitemap.baseUrl} erreichbar sind.

Sicherstellung gleichbleibender Bezeichner (IDs)

Für den Zugriff auf Dokumente im Index ist ein fester Bezeichner essenziell. Werden Ressourcen indexiert, die keine eindeutige ID haben, wird diese von smart.finder während der Indexierung automatisch erzeugt.

Damit bei jedem Indexierungsdurchgang derselbe Bezeichner für ein Dokument erzeugt wird, muss in der solrconfig.xml des betreffenden Cores die ConditionalIdProcessorFactory auf den Algorithmus fieldhash eingestellt sein. Dieser Algorithmus berechnet für eine gegebene Anzahl von Feldern einen eindeutigen Hash-Wert. Dieser ändert sich nur, wenn sich die Werte der Felder ändern. fieldhash ist die Standardeinstellung im Index "core0".

Wird kein Feld für ein Dokument gefunden, wird eine Zufalls-ID erzeugt.

Bereitstellung der robots.txt-Datei

Um einem Web Crawler mitzuteilen, welche Inhalte der Webseite durchsuchbar sein sollen und welche nicht, kann eine sogenannte robots.txt-Datei verwendet werden. In dieser Datei wird außerdem die URL zur Sitemap-Datei angegeben. Eine Einführung in die Syntax finden Sie z.B. hier .

Im Root-Verzeichnis der Web-Applikation smartfinder finden Sie eine vorbereitete Datei robots.txt.sample, welche die grundlegenden Einstellungen beinhaltet. Ändern Sie diese Datei entsprechend den Anforderungen an das Web Crawling Ihrer Seite. Ersetzen Sie in jedem Fall [SITEMAP_URL] durch die absolute URL auf die von smart.finder erzeugte Sitemap.

Beispiel:

Sitemap: https://example.com/smartfinder/sitemap-1.xml.gz

Wurde mehr als eine Sitemap-Datei und somit auch eine sitemap_index.xml.gz-Datei erzeugt, fügen Sie hier die URL zu dieser Sitemap-Index-Datei ein.

Beispiel:

Sitemap: https://example.com/smartfinder/sitemap_index.xml

Benennen Sie die Datei anschließend in robots.txt um. Wenn ein Web Crawler Ihre Webseite besucht, schaut er zunächst nach der robots.txt-Datei und beginnt dann die Inhalte Ihrer Webseite entsprechend der Einstellungen in dieser Datei zu indexieren.

Dynamisches Rendern für smart.finder

Die smart.finder Benutzeroberfläche basiert zu einem großen Teil auf JavaScript. Viele Internetsuchmaschinen, die diese Webseiten abrufen und die Inhalte auslesen, stellt dies vor Probleme, da sie JavaScript nur eingeschränkt unterstützen.

Um dieses Problem zu umgehen, kann smart.finder eine Seite im Voraus rendern, wenn die Seite von einer Suchmaschine angefragt wurde. Der JavaScript-Code der Webseite wird also bereits auf dem Server ausgeführt und nur noch der generierte HTML-Code an die Suchmaschine ausgeliefert. Normalen Besuchern der Webseite wird weiterhin der JavaScript-Code ausgeliefert, sodass sich für sie nichts ändert.

Für das dynamische Rendern der Webseiten muss Rendertron auf dem Server installiert sein. Rendertron ist eine Serveranwendung und basiert auf Node.js und Puppeteer. Es benötigt eine auf dem Server installierte Instanz von Google Chrome.

Installation von Rendertron

Folgen Sie den Anweisungen auf der Rendertron-Webseite, um Rendertron auf Ihrem System zu installieren. Wenn Rendertron installiert wurde und ausgeführt wird, nimmt es Anfragen auf dem Port 3000 entgegen. Der Rendertron-Dienst muss vom smart.finder-Backend erreichbar sein und sollte nicht öffentlich zugreifbar sein.

Konfiguration von smart.finder

Die Konfiguration von smart.finder unterscheidet sich je nach der Variante, in der Sie smart.finder installiert haben (Standalone oder in einer vorhandenen map.apps-Instanz).

Konfiguration von smart.finder bei Verwendung der Standalone-Variante

Wenn Sie smart.finder mit der mitgelieferten smartfinder.war-Datei in der Standalone-Variante installiert haben, gehen Sie folgendermaßen vor:

  1. Stellen Sie für die folgende Konfigurationseigenschaft in der application.properties-Datei der "smartfinder"-Webapp die URL ein, unter der der Rendertron-Dienst für das smart.finder Backend erreichbar ist:

    seo.dynamicRendering.url=http://localhost:3000/render

  2. Starten Sie anschließend den Tomcat-Server neu, sodass smart.finder mit der neuen Einstellung geladen wird.

Konfiguration von smart.finder bei Verwendung einer vorhandenen map.apps-Instanz

Wenn Sie die smart.finder-Bundles in einer bereits vorhandenen map.apps-Instanz installiert haben, ist die Einrichtung des dynamischen Renderns etwas aufwändiger:

  1. Kopieren Sie die Datei resources/seo/ct-finder-seo-filter-%version%.jar aus der smart.finder-Auslieferung in den Ordner %TOMCAT%/webapps/mapapps/WEB-INF/lib (der Ordner mapapps hat in Ihrer Installation möglicherweise einen abweichenden Namen).

  2. Öffnen Sie die Datei %TOMCAT%/webapps/mapapps/WEB-INF/classes/spring-filter-config.xml in einem Texteditor.

  3. Suchen Sie in der Datei das Element <ref bean="jsonTojspDispatcherFilter"/> und fügen Sie wie im Folgenden gezeigt das Element <ref bean="prerenderFilter"/> hinzu.

    <list>
    ...
    <ref bean="jsonTojspDispatcherFilter"/> <!-- Bereits vorhandenes Element -->
    <ref bean="dynamicPrerenderFilter"/> <!-- <- Fügen Sie dieses Element neu hinzu -->
</list>

  4. Fügen Sie im unteren Bereich derselben Datei noch innerhalb des äußeren beans-Elements das folgende bean-Element hinzu:

    <beans>
    <!-- ... -->
    <!-- Bereits vorhandenes Element -->
    <bean id="propertiesReplacementFilter" class="de.conterra.config.support.rest.PropertiesReplacementFilter">
        <property name="propertiesResolver" ref="configPropertiesResolver"/>
        <property name="acceptPath" value="/,/account/login/,/manager/,/manager/3.x/*,/*.html,**/index.html,**/boot.js,**/*init.js,**/*.json,/js/sample/,/js/sample/**/*.html,/js/tests/test-apps/,/js/**/tests/**/*.html"/>
        <property name="excludePath" value="/resources/**,/event/**,/proxy/**,**/$raw/**"/>
    </bean>

    <!-- +++++++++++++++++++ -->
    <!-- Fügen Sie das folgende bean-Element neu zur Datei hinzu -->
    <bean id="dynamicPrerenderFilter" class="de.conterra.finder.seo.DynamicRenderingFilter">
        <constructor-arg name="renderer">
            <bean class="de.conterra.finder.seo.DefaultRenderer">
                <constructor-arg name="baseURL" value="${seo.dynamicRendering.url}"/>
                <constructor-arg name="httpClientFactory" ref="defaultHttpClientFactory"/>
            </bean>
        </constructor-arg>
        <constructor-arg name="searchBotSniffer">
            <bean class="de.conterra.finder.seo.SearchBotSniffer">
                <constructor-arg name="userAgentRegEx">
                    <array value-type="java.lang.String">
                        <value>.*bingbot.*</value>
                        <value>.*Googlebot.*</value>
                    </array>
                </constructor-arg>
            </bean>
        </constructor-arg>
    </bean>
</beans>

  5. Öffnen Sie die application.properties-Datei der map.apps-Instanz und ergänzen Sie die folgende Einstellung:

    seo.dynamicRendering.url=http://localhost:3000/render

    Stellen Sie hier die URL ein, unter der der Renderer-Dienst für das map.apps-Backend erreichbar ist. Rendertron verwendet standardmäßig den Port 3000.

  6. Starten Sie anschließend den Tomcat-Server neu, sodass map.apps mit den neuen Einstellungen geladen wird.

Anmeldung bei Suchmaschinen

Im letzten Schritt sollten Sie Ihre Website bei den gewünschten Suchmaschinen anmelden. In Google ist dies zum Beispiel über die Google Search Console möglich. In Bing können Sie die Anmeldung über die Bing Webmaster Tools vornehmen.