The default Hugo target directory for your built website is
public/. However, you can change this value by specifying a different
publishDir in your site configuration. The directories created at build time for a section reflect the position of the content’s directory within the
content folder and namespace matching its layout within the
permalinks option in your site configuration allows you to adjust the directory paths (i.e., the URLs) on a per-section basis. This will change where the files are written to and will change the page’s internal “canonical” location, such that template references to
.RelPermalink will honor the adjustments made as a result of the mappings in this option.
For example, if one of your sections is called
post and you want to adjust the canonical path to be hierarchical based on the year, month, and post title, you could set up the following configurations in YAML and TOML, respectively.
YAML Permalinks Configuration Example
permalinks: post: /:year/:month/:title/
TOML Permalinks Configuration Example
[permalinks] post = "/:year/:month/:title/"
Only the content under
post/ will have the new URL structure. For example, the file
date: 2017-02-27T19:20:00-05:00 in its front matter will render to
public/2017/02/sample-entry/index.html at build time and therefore be reachable at
Permalink Configuration Values
The following is a list of values that can be used in a
permalink definition in your site
config file. All references to time are dependent on the content’s date.
- the 4-digit year
- the 2-digit month
- the name of the month
- the 2-digit day
- the 1-digit day of the week (Sunday = 0)
- the name of the day of the week
- the 1- to 3-digit day of the year
- the content’s section
- the content’s title
- the content’s slug (or title if no slug is provided in the front matter)
- the content’s filename (without extension)
For people migrating existing published content to Hugo, there’s a good chance you need a mechanism to handle redirecting old URLs.
Luckily, redirects can be handled easily with aliases in Hugo.
Let’s assume you create a new piece of content at
content/posts/my-awesome-blog-post.md. The content is a revision of your previous post at
content/posts/my-original-url.md. You can create an
aliases field in the front matter of your new
my-awesome-blog-post.md where you can add previous paths. The following examples show how to create this filed in TOML and YAML front matter, respectively.
TOML Front Matter
+++ aliases = [ "/posts/my-original-url/", "/2010/01/01/even-earlier-url.html" ] +++
YAML Front Matter
--- aliases: - /posts/my-original-url/ - /2010/01/01/even-earlier-url.html ---
Now when you visit any of the locations specified in aliases—i.e., assuming the same site domain—you’ll be redirected to the page they are specified on. For example, a visitor to
example.com/posts/my-original-url/ will be immediately redirected to
Example: Aliases in Multilingual
On multilingual sites, each translation of a post can have unique aliases. To use the same alias across multiple languages, prefix it with the language code.
--- aliases: - /es/posts/my-original-post/ ---
How Hugo Aliases Work
When aliases are specified, Hugo creates a directory to match the alias entry. Inside the directory, Hugo creates an
.html file specifying the canonical URL for the page and the new redirect target.
For example, a content file at
posts/my-intended-url.md with the following in the front matter:
--- title: My New post aliases: [/posts/my-old-url/] ---
example.com, the contents of the auto-generated alias
.html found at
https://example.com/posts/my-old-url/ will contain the following:
<!DOCTYPE html> <html> <head> <title>https://example.com/posts/my-intended-url</title> <link rel="canonical" href="https://example.com/posts/my-intended-url"/> <meta name="robots" content="noindex"> <meta http-equiv="content-type" content="text/html; charset=utf-8"/> <meta http-equiv="refresh" content="0; url=https://example.com/posts/my-intended-url"/> </head> </html>
http-equiv="refresh" line is what performs the redirect, in 0 seconds in this case. If an end user of your website goes to
https://example.com/posts/my-old-url, they will now be automatically redirected to the newer, correct URL. The addition of
<meta name="robots" content="noindex"> lets search engine bots know they they should not crawl and index your new alias page.
You may customize this alias page by creating an
alias.html template in the
layouts folder of your site (i.e.,
layouts/alias.html). In this case, the data passed to the template is
- the link to the page being aliased
- the Page data for the page being aliased
Important Behaviors of Aliases
- Hugo makes no assumptions about aliases. They also do not change based on your UglyURLs setting. You need to provide absolute paths to your web root and the complete filename or directory.
- Aliases are rendered before any content are rendered and therefore will be overwritten by any content with the same location.
Hugo’s default behavior is to render your content with “pretty” URLs. No non-standard server-side configuration is required for these pretty URLs to work.
The following demonstrates the concept:
content/posts/_index.md => example.com/posts/index.html content/posts/post-1.md => example.com/posts/post-1/
If you would like to have what are often referred to as “ugly URLs” (e.g., example.com/urls.html), set
uglyurls = true or
uglyurls: true in your site’s
config.yaml, respectively. You can also use the
--uglyURLs=true flag from the command line with
If you want a specific piece of content to have an exact URL, you can specify this in the front matter under the
url key. The following are examples of the same content directory and what the eventual URL structure will be when Hugo runs with its default behavior.
See Content Organization for more details on paths.
. └── content └── about | └── _index.md // <- https://example.com/about/ ├── post | ├── firstpost.md // <- https://example.com/post/firstpost/ | ├── happy | | └── ness.md // <- https://example.com/post/happy/ness/ | └── secondpost.md // <- https://example.com/post/secondpost/ └── quote ├── first.md // <- https://example.com/quote/first/ └── second.md // <- https://example.com/quote/second/
Here’s the same organization run with
. └── content └── about | └── _index.md // <- https://example.com/about/index.html ├── post | ├── firstpost.md // <- https://example.com/post/firstpost.html | ├── happy | | └── ness.md // <- https://example.com/post/happy/ness.html | └── secondpost.md // <- https://example.com/post/secondpost.html └── quote ├── first.md // <- https://example.com/quote/first.html └── second.md // <- https://example.com/quote/second.html
By default, all relative URLs encountered in the input are left unmodified, e.g.
/css/foo.css would stay as
canonifyURLs field in your site
config has a default value of
true, all relative URLs would instead be canonicalized using
baseURL. For example, assuming you have
baseURL = https://example.com/, the relative URL
/css/foo.css would be turned into the absolute URL
Benefits of canonicalization include fixing all URLs to be absolute, which may aid with some parsing tasks. Note, however, that all modern browsers handle this on the client without issue.
Benefits of non-canonicalization include being able to have scheme-relative resource inclusion; e.g., so that
https can be decided according to how the page was retrieved.
To find out the current value of
canonifyURLs for your website, you may use the handy
hugo config command added in v0.13.
hugo config | grep -i canon
Or, if you are on Windows and do not have
hugo config | FINDSTR /I canon
Override URLS with Front Matter
In addition to specifying permalink values in your site configuration for different content sections, Hugo provides even more granular control for individual pieces of content.
url can be defined in individual front matter. For more information on content destinations at build time, see Content Organization.
By default, all relative URLs are left unchanged by Hugo, which can be problematic when you want to make your site browsable from a local file system.
true in your site configuration will cause Hugo to rewrite all relative URLs to be relative to the current content.
For example, if your
/post/first/ page contains a link to
/about/, Hugo will rewrite the URL to