Build Settings

• Destination URL
• Preview URL
• Additional URLs
• Additional Paths
• Excluded URLs
• Additional Redirects

The Build Settings define the scope and structure of your WordPress site’s static version. They let you 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 can 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, so you can deploy your site in a subdirectory.

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

If you need to access your site offline, such as for local browsing without a web server, choose the Offline URL setting. It makes all site URLs path-relative, so they resolve without a web server. This is 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 starts at your WordPress site’s front page and follows the links it finds, crawling your site to process every accessible page and asset. Pages or assets that are not linked from anywhere on your site are left out of the static version unless you add them to this 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. When robots.txt is included, Staatic also follows the sitemaps it lists, and the sitemaps inside a sitemap index.

Note: If your site has an XML sitemap, include it in this list. It makes sure all content is included in the static version of your site, and gives a better indication of progress while the publication 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 leaves out folders in your uploads directory that other plugins use for logs, backups and temporary files, such as those of Sucuri, Solid Security (ithemes-security), WP Activity Log, File Manager, WP All Import and WooCommerce logs. They are never published.

Staatic automatically adds any linked page it discovers during crawling to 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 (see WordPress REST API below). 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: use 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: use 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 case-insensitive and match against normalized URL segments, including the path, query, and fragment.

Note: When using regular expression rules, ensure ~ is used as the delimiter. Modifiers are not supported at this time.

WordPress REST API

WordPress links to its REST API from every page: a discovery link to /wp-json/, a JSON link for each post, page and term, and oEmbed links. Staatic does not follow these links (since 1.15.1), whatever your Excluded URLs contain, including language-prefixed copies such as /nl/wp-json/ and ?rest_route= URLs. Published REST API responses would show the address of your WordPress site and list the routes of every plugin you use, and a static copy cannot answer queries anyway.

If your site reads the REST API in the browser, keep it dynamic instead: on Staatic Cloud, forward /wp-json/* to WordPress with an origin rule.

To publish specific REST API responses as static files on purpose, add them to Additional URLs, for example /wp-json/wp/v2/posts, and remove /wp-json/* from Excluded URLs. Their JSON is published as WordPress returns it, so it still contains your WordPress site address. Developers can restore the old behavior with the staatic_exclude_discovered_rest_api_urls filter (return false).

Additional Redirects

Staatic includes the HTTP redirects it finds while crawling in the static version of your site. If you need redirects that do not exist in your dynamic WordPress site, add them manually in this section.

Supported HTTP status codes for redirects are:

A common reason to add a redirect is a changed post slug, which makes the original URL obsolete. Redirect the old URL to the new one to prevent 404 errors and preserve 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 take precedence over generated content. If the crawl also produced a page or a redirect for the same origin, Staatic keeps the additional redirect, drops the generated result and records what it replaced in the publication log. When two additional redirects claim the same origin, the earlier line wins. An additional redirect that points at its own origin never replaces a page.

Staatic can automatically import basic redirects from several widely used WordPress redirection plugins.

Compatible plugins include:

• Rank Math
• Redirection
• Safe Redirect Manager
• Simple 301 Redirects
• Yoast Premium