disallow paging sites for web crawler

content/post/continuous-deployment-hugo/index.md

@@ -4,17 +4,6 @@ date: 2019-02-04T20:30:00+02:00
 draft: false
 author: robert-kaussow
 description: "Static Site Generatoren sind gerade stark im Trend. Doch was voher das Blogsystem automatisch gemacht hat, muss jetzt vom Benutzer selbst durchgeführt werden. Mit Hilfe von Continuous Deployment Strategien lässt sich der Arbeitsaufwand aber auf ein Minimum reduzieren."
-keywords:
-  - open
-  - source
-  - hugo
-  - static site generator
-  - devops
-  - cicd
-  - continuous
-  - deployment
-  - integration
-  - automation
 categories:
   - Open Source
   - Entwicklung
@@ -29,7 +18,7 @@ resources:
 
 Wie bereits in einem früheren Beitrag erwähnt, nutze ich für meinen Blog mittlerweile Hugo, einen Static Site Generator, anstelle einer Blog-Engine oder eines Content Management Systems. Bisher habe ich die Entscheidung nicht bereut, musste aber feststellen, dass sich mein Workflow im ersten Schritt nicht wirklich verbessert hat. Um das zu beheben, muss man sich als Erstes zwei Dinge anschauen: Wie hat es bisher funktioniert und wo will ich eigentlich hin? Dieser Beitrag soll eine Art Retrospektive sein und meinen Weg zu einer Continuous Deployment Strategie mit Hugo und Drone CI betrachten.
 
-Den notwendigen Neuaufbau meiner Infrastruktur habe ich nicht nur zum Anlass genommen, um alles vollständig auf Ansible umzustellen, sondern auch um meinen Softwarestack kritisch zu hinterfragen und aufzuräumen. Jede Software erfüllt natürlich einen Zweck, entscheidend für mich war aber: Wie wartungsintensiv ist die Lösung, wie leicht lässt sie sich automatisch deployen und rechtfertigt der Aufwand den Zweck. Im Fall von meiner Blog-Engine Serendipity (s9y) bin ich zu dem Schluss gekommen, dass ich darauf eigentlich ganz gut verzichten kann. Nebenbei empfand ich mittlerweile die Weboberfläche zur Verwaltung meiner Beiträge als nicht optimal für mich. Ich wollte lieber in einem Artikel meiner Wahl, am besten auch Oflline arbeiten können als in einem Onlineeditor. Außerdem musste man für etwas komplexere Formatierungen dann doch wieder zu HTML und CSS wechseln, weil der WYSIWYG-Editor das nicht hergab und Markdown im Standard da auch relativ beschränkt ist. Damit war die Entscheidung auch schon getroffen, es soll eine neue Lösung her.
+Den notwendigen Neuaufbau meiner Infrastruktur habe ich nicht nur zum Anlass genommen, um alles vollständig auf Ansible umzustellen, sondern auch um meinen Softwarestack kritisch zu hinterfragen und aufzuräumen. Jede Software erfüllt natürlich einen Zweck, entscheidend für mich war aber: Wie wartungsintensiv ist die Lösung, wie leicht lässt sie sich deployen und rechtfertigt der Aufwand den Zweck. Im Fall von meiner Blog-Engine Serendipity (s9y) bin ich zu dem Schluss gekommen, dass ich darauf eigentlich ganz gut verzichten kann. Nebenbei empfand ich mittlerweile die Weboberfläche zur Verwaltung meiner Beiträge als nicht optimal für mich. Ich wollte lieber in einem Artikel meiner Wahl, am besten auch Oflline arbeiten können als in einem Onlineeditor. Außerdem musste man für etwas komplexere Formatierungen dann doch wieder zu HTML und CSS wechseln, weil der WYSIWYG-Editor das nicht hergab und Markdown im Standard da auch relativ beschränkt ist. Damit war die Entscheidung auch schon getroffen, es soll eine neue Lösung her.
 
 Der zweite Schritt war die "Suche" nach einer alternative. Zugegeben, da habe ich es mir tatsächlich etwas einfach gemacht und keinen großen Softwareauswahlprozess durchgeführt. Dass es ein Static Site Generator werden soll, stand für mich fest und [Hugo](https://gohugo.io/) war mir bereits bekannt. Nach den ersten Experimenten mit Hugo, die ohne große Zwischenfälle verliefen, fing ich an ein paar Punkte zu sammeln, die ich mir für die konkrete Umsetzung gewünscht habe:
 

static/robots.txt

@@ -4,4 +4,5 @@ Disallow: /categories/*
 Disallow: /authors/*
 Disallow: /author/*
 Disallow: /tags/*
+Disallow: /page/*
 Sitemap: https://geeklabor.de/sitemap.xml