Build Settings

• Destination URL
• Preview URL
• Additional URLs
• Additional paths
• Exclude URLs
• Additional redirects

The Build Settings play a crucial role in defining the scope and structure of your WordPress site’s static version. They allow you to specify which content is included or excluded, and how content links are handled.

Destination URL

The Destination URL is where your static site will be hosted, such as https://www.mydomain.com/. For instance, if your dynamic WordPress installation is located at https://wordpress.mydomain.com/, Staatic will transform all references from https://wordpress.mydomain.com/ to https://www.mydomain.com/ to match the destination URL.

You have the flexibility to use either an absolute URL or a relative URL for the destination. Relative URLs, like //mydomain.com/ or simply /, enable your site to be served across different schemes (http or https) or domains. If you specify a path other than /, Staatic will prepend this path to all URLs, facilitating the deployment of your site within a subdirectory structure.

By default, the Destination URL is set to /. It can also be configured with the STAATIC_DESTINATION_URL environment variable.

For cases where you need to access your site offline, such as local browsing without a web server, or for specific configuration needs, you can opt for the Offline URL setting. Choosing this option adjusts all site URLs to be path relative, ensuring they can properly resolve without requiring an active server environment. This feature is particularly useful for testing, development, or presentations where direct internet access to the hosted site is not available.

Preview URL

The Preview URL determines how links are constructed for preview publications. This allows a deployment method that supports preview publications, such as Staatic Cloud, to use a separate URL for previewing changes before they are published to the live destination.

By default, the Preview URL is set to /. It can also be configured with the STAATIC_PREVIEW_URL environment variable.

Note: This setting is only shown when the selected deployment method supports preview publications.

Additional URLs

To create a static version of your website, Staatic initiates the process by accessing your WordPress site’s front page. It systematically follows the links found on this initial page, crawling through your site to process every accessible page and asset. However, pages or assets not linked from anywhere within your site will be omitted from the final static version unless they are explicitly added to the list.

By default, Staatic follows links that belong to your site and adds discovered pages and assets to the static build. Additional URLs are useful for URLs that are valid but not linked from crawlable pages.

In the raw setting, each line uses this format:

<url> [flags]

The optional flags are:

Relative URLs are resolved against the WordPress site URL. Absolute URLs must use the same authority as the site; otherwise Staatic comments the line out during validation and does not include it.

Here are some examples of common additional URLs:

• /wp-sitemap.xml
• /robots.txt
• /favicon.ico

By default, Staatic includes /wp-sitemap.xml. For sites published from the domain root, /robots.txt is included by default as well.

Note: In cases where an XML sitemap is present, it is recommended to include it in this list. Not only does it make sure all content is included in the static version of your site, it also provides a better indication of the progress while the publication process is running.

Additional Paths

Additional paths function similarly to Additional URLs, with the key difference being that these refer to paths on the filesystem, which are converted into URLs for inclusion in the static site.

In the raw setting, each line uses this format:

<filesystem-path> [url-base-path] [flags]

Relative filesystem paths are resolved from the WordPress installation directory. Paths must be readable and cannot point to the WordPress installation directory itself.

The optional flags are:

Directories are scanned recursively by default. If you omit url-base-path but need flags, keep the empty middle field, for example /path/to/assets FSR.

It’s advisable to include your WordPress uploads directory (e.g., /wp-content/uploads) to ensure all static assets are included in your static site.

By default, Staatic includes the WordPress uploads directory. If the filesystem path does not map directly to the uploads URL path, Staatic stores both values so the files can be resolved correctly during the build.

Staatic automatically incorporates any site-linked page it discovers during crawling into the static site. The additional path flags let you decide whether Staatic should follow links, save matched resources, or limit directory scans for URLs derived from additional paths.

Excluded URLs

Similar to how Additional URLs are included in your static site, Excluded URLs specify which pages or assets Staatic should ignore during the crawling process. This ensures that specified content is not included in the final static version of your site.

By default, Staatic excludes /wp-json/* so WordPress REST API endpoints are not included in the static build. Staatic also adds runtime exclusions for WordPress endpoints and patterns that should not become static files, including xmlrpc.php, wp-comments-post.php, wp-login.php, /wp-admin, common query URLs such as ?p=... or ?s=..., and .htaccess files.

Staatic supports the exclusion of URLs through three types of rules, allowing for precise control over what gets excluded:

• Simple rules: target a specific URL for exclusion with an exact match. For instance, specifying /some-page/ will exclude this specific page from being included.
• Wildcard rules: utilize wildcards to exclude a range of URLs that match a pattern. For example, /some-* can be used to exclude any URLs that start with /some-.
• Regular expression rules: utilize regular expressions for more complex matching criteria, such as ~^/excluded-page-[1-3]/?$~, to exclude URLs that match the specified regex pattern.

All rules are applied in a case-insensitive manner and match against normalized URL segments, including the path, query, and fragment, ensuring comprehensive coverage across your site’s structure.

Note: When using regular expression rules, ensure ~ is used as the delimiter. Please be aware that modifiers are not supported at this time.

Additional Redirects

Staatic effectively handles HTTP redirects encountered during its crawling phase, incorporating them into the static version of your site. For redirects that do not exist within the dynamic WordPress environment but are still needed, you have the option to specify them manually in this section.

Supported HTTP status codes for redirects are:

Configuring additional redirects can be crucial in several scenarios. A common example is when you’ve changed the slug of a post, rendering the original URL obsolete. In such cases, it’s important to ensure that the old URL redirects to the new one, preventing any 404 errors and preserving the user experience as well as SEO rankings.

In the raw setting, each line uses this format:

<origin-path> <redirect-url> [status]

The origin must be an absolute path without scheme or authority, for example /old-page/. The redirect target may be relative or absolute. If the status is omitted, Staatic uses 302.

Additional redirects do not override generated content. If the build already contains a result for the origin URL, the additional redirect for that origin is skipped.

Staatic supports integration with several widely-used WordPress redirection plugins, enabling the automatic import of basic redirects configured within these tools.

Compatible plugins include:

• RankMath
• Redirection
• Safe Redirect Manager
• Simple 301 Redirects
• Yoast Premium