Introduction

A new WordPress installation can appear ready for publishing while several important configuration decisions remain unresolved. The website may load correctly, the administration dashboard may be accessible and the chosen theme may look satisfactory, yet settings affecting URLs, search engine visibility, user registration, comments and scheduled publishing may still be inappropriate for the intended website.

Some of these settings are difficult to change once substantial content has been published. Others create problems that remain unnoticed until the website receives traffic, changes hosting providers or starts using additional plugins.

The most useful initial configuration process is therefore not simply a matter of changing defaults. Each setting should be examined in relation to how the website will operate. A private membership website has different requirements from a public technical reference site, and a digital product store needs different controls from a personal blog.

The following 20 checks cover WordPress core settings, administration options and several important operational configurations that should be reviewed before a new website goes live.

General Settings

1. Site Title and Tagline

Location: Settings > General

WordPress stores a site title and tagline that can be used by themes, browser titles, feeds and other components. Their exact presentation depends on the active theme and installed SEO functionality.

The site title should accurately identify the website. It may be a business name, publication name or another recognisable title. Avoid inserting a long collection of keywords into this field.

The tagline provides a short description of the website’s purpose. Some themes display it prominently, while others do not display it at all.

For example, a WordPress reference website might use:

The tagline should not repeat the site title without adding information.

An SEO plugin may generate different page titles using its own templates, so changing the WordPress tagline does not guarantee that it will appear in search results.

After configuring these fields, inspect the homepage, browser title and any visible header text. The objective is consistency rather than forcing the same wording into every location.

2. WordPress Address and Site Address

Location: Settings > General

Two settings determine important aspects of how WordPress identifies its location:

WordPress Address (URL) identifies the address where the WordPress application files are located.

Site Address (URL) identifies the public address visitors use to access the website.

For a conventional installation where WordPress and the public website use the same location, the values are normally identical.

For example:

WordPress Address: https://example.com
Site Address:      https://example.com

Some installations deliberately use different addresses, such as WordPress installed in a subdirectory while the public website uses the domain root.

Incorrect values can cause login problems, broken resource URLs, unexpected redirects and difficulty accessing the administration interface.

If HTTPS is configured correctly, the public addresses should normally use https://.

Do not change these values casually on an established installation. Moving WordPress to another directory or changing domains may require corresponding web-server configuration, database updates and redirect handling.

The values may also be controlled through the WP_HOME and WP_SITEURL constants in wp-config.php. When those constants are defined, the corresponding administration fields may not be editable.

For a new website, confirm the final domain and HTTPS configuration before publishing substantial content.

3. Administration Email Address

Location: Settings > General

The administration email address is used for important site-level notifications, including certain update and recovery messages.

It is separate from the email addresses associated with individual WordPress user accounts.

The address should belong to someone responsible for maintaining the website and should be monitored regularly.

Using an email address that is rarely checked can delay the discovery of important technical problems.

For a business website, a dedicated administrative mailbox may be more appropriate than an individual employee’s personal address, provided access and responsibility are clearly managed.

WordPress may require confirmation when the administration email address is changed. The change should not be assumed complete until the necessary confirmation has occurred.

This setting does not determine every email address used by the website. Contact form plugins, ecommerce systems and other extensions may maintain their own sender and notification settings.

After changing the address, confirm that important administrative messages can be received. Reliable delivery also depends on the website’s email configuration and hosting environment.

4. Membership Registration and Default User Role

Location: Settings > General

The Anyone can register option controls whether public user registration is enabled through WordPress’s standard registration system.

For a conventional informational website, public registration is often unnecessary.

Leaving registration enabled without a specific requirement can introduce unwanted user accounts and additional administration work.

Websites offering memberships, community features or customer accounts may need registration, although an ecommerce or membership plugin may provide its own registration controls.

The New User Default Role setting determines the role assigned through WordPress’s normal registration mechanism.

For public registration, Subscriber is generally the appropriate low-privilege default.

Do not select Administrator, Editor or another privileged role for ordinary public registrations.

WordPress roles correspond to sets of capabilities. A role name alone should not be treated as a complete security policy, especially when plugins alter capabilities.

A sensible configuration for an ordinary publishing website is:

The default role should still be reviewed even when registration is disabled, particularly if the website may introduce user accounts later.

5. Timezone, Date and Time Formats

Location: Settings > General

WordPress uses its configured timezone for date and time functions, publication scheduling and various time-dependent operations.

An incorrect timezone may cause posts to be scheduled at unexpected times or dates to appear differently from those intended.

The preferred approach is usually to select a named city representing the required timezone.

For a UK-based website, selecting London allows WordPress to account for changes between Greenwich Mean Time and British Summer Time.

A fixed UTC offset does not automatically provide the same daylight-saving behaviour.

The date and time formats can also be configured according to the site’s audience.

For example:

Date Format: j F Y
Time Format: H:i

These formats produce dates such as:

12 November 2026

And times such as:

19:30

The underlying formatting follows PHP-style date format characters used by WordPress.

The configured timezone should be checked before using scheduled publishing or time-sensitive plugins.

Individual plugins may handle time calculations differently, so a correctly configured WordPress timezone does not guarantee that every third-party integration uses identical conventions.

Writing and Reading Settings

6. Default Post Category

Location: Settings > Writing

WordPress assigns a default category to standard posts when another category has not been selected.

A new installation normally includes an initial category named Uncategorized.

Leaving that category unchanged can result in published articles appearing in an unhelpful archive.

For a technical publishing website, a more suitable default might be General WordPress Guides or another broad editorial category.

However, the default category should not become a substitute for proper classification.

If the website contains several distinct subjects, each article should be assigned to the most appropriate category during publication.

Before publishing, create the main categories that will form the website’s content structure.

For example:

• WordPress Development

• Troubleshooting

• Performance

• Security

• SEO

• WooCommerce

The default should be a reasonable fallback rather than a category into which most articles are automatically placed.

Changing the default category does not necessarily reorganise previously published posts.

7. Default Post Format

Location: Settings > Writing, where supported

WordPress supports post formats, which allow themes to distinguish certain kinds of posts.

Examples include Standard, Aside, Gallery, Image, Video and Quote.

Not every theme supports post formats, and the setting may not appear in every installation.

For most conventional article websites, Standard is the appropriate default.

Post formats should not be confused with categories or custom post types. They provide additional presentation information for standard posts rather than defining entirely separate content structures.

A theme may use a post format to alter how an article appears in an archive or template.

If the selected theme does not support the feature, there is little reason to build an editorial workflow around it.

For a website publishing technical tutorials, code snippets and troubleshooting articles, standard posts with suitable categories will generally be easier to maintain.

8. Homepage Display

Location: Settings > Reading

WordPress can display either the latest posts or a selected static page as the homepage.

The correct option depends on the website’s purpose.

A traditional blog may benefit from displaying its latest articles.

A business website, resource library or digital product website will usually benefit from a dedicated homepage containing navigation, featured resources and selected content.

When using a static homepage, choose an existing published page.

A separate page can also be assigned as the posts page.

For example:

When a page is assigned as the posts page, WordPress uses it to display the blog index. Its ordinary editor content is not generally displayed in the same way as a normal static page.

The posts listing is controlled by the active theme or block template.

Do not build a complete article layout inside a page and then assume it will remain visible after assigning that page as the posts index.

For a content and digital product website, a static homepage can provide a more useful entry point than a chronological article list.

9. Blog Pages Show at Most

Location: Settings > Reading

The Blog pages show at most setting determines how many posts WordPress displays on standard paginated post listings.

The default is commonly 10.

The ideal value depends on the website’s archive design, available content and whether the theme displays full articles, excerpts or compact cards.

A site displaying large featured images and extensive excerpts may become cumbersome if too many posts appear on one archive page.

A compact reference directory may accommodate more entries.

For example, an archive containing 12 article cards could provide a reasonable balance between navigation and page length.

This setting does not necessarily control every query on the website.

Custom Query Loop blocks, WP_Query calls and third-party plugins can specify their own post limits.

After changing the setting, inspect category archives, the main posts index and pagination behaviour.

Do not use an excessively large number merely to avoid pagination. Retrieving and rendering many posts can increase database work and page size.

10. Search Engine Visibility

Location: Settings > Reading

The search engine visibility option is one of the most important settings to check before launching a new WordPress website.

The setting is labelled:

Discourage search engines from indexing this site

It is commonly enabled during development when a website should not yet appear in public search results.

Before launch, a public website normally needs this option disabled.

When the option is enabled, WordPress asks search engines not to index the website through mechanisms such as robots directives. This is a request, not an access-control system or a guarantee of privacy.

Search engines may still discover URLs, and confidential content should never rely on this setting for protection.

A staging website should instead use appropriate authentication or access restrictions when private access is required.

After launch, verify the setting and inspect whether an SEO plugin, web-server configuration or other component is applying additional indexing restrictions.

Disabling the option does not guarantee immediate search engine indexing. Search engines independently decide whether and when to crawl and index content.

Discussion and Media Settings

11. Default Comment Settings

Location: Settings > Discussion

WordPress supports comments on posts and, where enabled, pages.

For websites that actively encourage discussion, comments can provide useful interaction.

For a technical reference website, comments may create ongoing moderation work, particularly when readers use them for questions that require detailed support.

The Allow people to submit comments on new posts option should reflect the intended publishing model.

Disabling comments for new posts does not automatically close every comment section on previously published content.

Comments can also be managed individually on posts where the relevant controls are enabled.

If comments are required, review the moderation and approval settings carefully.

A reasonable starting point may be to require manual approval, especially for a new website with no established moderation process.

Do not assume that disabling comments through a theme’s visual settings prevents all comment submissions. The underlying WordPress discussion configuration still matters.

12. Comment Moderation and Spam Controls

Location: Settings > Discussion

If comments are enabled, WordPress provides controls governing how submissions are handled.

These include settings for comment approval, moderation queues, author information and disallowed terms.

Requiring comment authors to provide a name and email address may discourage some automated submissions, but it does not establish that those details are genuine.

WordPress also provides options for holding comments containing multiple links or particular words.

These rules can reduce obvious spam, but overly broad filters may also prevent legitimate comments from appearing.

The setting requiring a comment author to have a previously approved comment can reduce moderation work for returning contributors. It is not a guarantee that future comments will be appropriate.

If comments are an important website feature, a dedicated anti-spam system may be justified.

If comments are not required, disabling them may be simpler than maintaining a complex moderation arrangement.

The correct approach depends on whether discussion is part of the website’s intended function.

13. Media Upload and Image Sizes

Location: Settings > Media

WordPress can generate different image sizes when files are uploaded.

The Media settings include dimensions for certain traditional image sizes, such as thumbnails, medium images and large images.

Modern themes and plugins may register additional image sizes independently.

This means that the settings page does not necessarily show every size generated by the website.

The appropriate dimensions depend on the content and layout.

A technical article website may use relatively small featured images and numerous screenshots. An image-heavy publication may require larger derivatives.

Changing the Media settings generally affects future image processing. Existing uploads are not automatically regenerated simply because the configured dimensions change.

For an established installation, changing image dimensions may therefore require a controlled thumbnail regeneration process.

It is also worth checking how the selected theme displays images.

A theme may crop featured images to particular aspect ratios even when the Media settings suggest different dimensions.

Do not assume that generating fewer image sizes is always beneficial. Responsive layouts may require several derivatives to avoid delivering unnecessarily large files.

14. Organise Uploads into Month- and Year-Based Folders

Location: Settings > Media

WordPress provides an option to organise uploaded files into month- and year-based directories.

When enabled, an uploaded file may be stored under a path such as:

wp-content/uploads/2026/11/example-image.jpg

When disabled, uploads are generally stored without that date-based subdirectory structure, subject to filters and plugin behaviour.

The setting affects filesystem organisation rather than the editorial categories assigned to the images.

For a conventional publishing website, date-based directories can make large collections easier to divide into smaller groups.

However, some website owners prefer a flatter structure for particular migration or asset-management workflows.

Neither approach is inherently superior for search engine optimisation.

The important consideration is consistency.

Changing the setting does not automatically reorganise previously uploaded files.

Manually moving media files in the filesystem can break stored attachment paths and URLs unless the database and related metadata are updated correctly.

For most new websites, leaving the date-based organisation enabled is reasonable.

Permalinks, Privacy and User Management

15. Permalink Structure

Location: Settings > Permalinks

The permalink structure determines the public URL format for standard WordPress posts.

For most evergreen content websites, the Post name structure provides a straightforward option.

For example:

https://example.com/wordpress-security-checklist/

It avoids including dates that may become misleading when an evergreen article is updated.

However, a date-based URL can be suitable for news publications or other websites where publication dates are important.

The choice should reflect the editorial model.

If the website will publish tutorials, code snippets and reference articles, a simple post-name structure is usually easy to maintain.

Establish the structure before publishing substantial content.

Changing it later can alter existing URLs and require redirects.

Custom post types may use their own rewrite settings, so changing the standard post permalink structure does not necessarily control every public URL.

After configuring permalinks, test a post, page, category archive and any custom post type URLs.

A correct administration setting does not guarantee successful routing if the web-server rewrite configuration is incorrect.

16. Privacy Policy Page

Location: Settings > Privacy

WordPress provides a setting for designating a privacy policy page.

The site owner can select an existing page or create a new one.

WordPress also provides guidance and suggested policy text that can help identify information relevant to the website.

However, the generated guidance is not a complete legal assessment.

A privacy policy must accurately reflect the personal information collected, how it is used, which services process it and the relevant legal requirements.

A website using analytics, contact forms, user accounts, payment processors or marketing services may have additional disclosure obligations.

The designated privacy policy page should be easy for visitors to find.

It is commonly included in the website footer.

For a digital product store, review the privacy practices of payment, email and download-delivery systems rather than assuming the standard WordPress policy covers them automatically.

17. User Accounts and Administrator Access

Location: Users > All Users

Although user management is not part of the Settings menu, it is an essential new-installation check.

Review every account created during installation or development.

Confirm that administrator accounts belong to authorised individuals and that their email addresses are correct.

Remove unnecessary accounts and assign suitable roles to users who do not require full administrative access.

WordPress provides several standard roles, including Administrator, Editor, Author, Contributor and Subscriber.

Their permissions differ, and plugins may introduce additional capabilities or roles.

For example, someone responsible only for writing articles may need an Author or Editor account rather than Administrator access.

Use individual accounts rather than sharing a single administrator login.

This makes access easier to audit and revoke.

Strong passwords and an appropriate additional authentication mechanism should be considered for privileged accounts.

Avoid using generic account names where they are unnecessary, but changing an administrator username alone should not be treated as a substantial security measure.

The important protections are account security, correct capabilities and reliable management of privileged access.

Technical Configuration and Maintenance

18. Automatic Updates for WordPress Core, Plugins and Themes

Location: Dashboard > Updates, Plugins and Appearance > Themes, depending on the component

WordPress supports automatic updating for core software and, where available, individual plugins and themes.

The appropriate policy depends on the website’s complexity and operational requirements.

A relatively simple informational website may benefit from automatic updates because it reduces the period during which known vulnerabilities remain unpatched.

A highly customised website or ecommerce store may need more controlled deployment for certain components.

WordPress core has its own automatic update behaviour, while plugin and theme updates can be managed through their respective administration interfaces or through hosting management tools.

The settings displayed may vary according to hosting configuration, WordPress installation method and update-management plugins.

Do not disable all updates merely because an earlier update caused a problem.

Instead, establish a process that includes reliable backups, compatibility checks and post-update verification.

A useful approach is to distinguish between routine security maintenance and changes that require more extensive testing.

Whatever policy is chosen, someone must remain responsible for checking whether updates succeed.

19. WordPress Site Health

Location: Tools > Site Health

WordPress includes a Site Health screen that checks aspects of the installation and server environment.

It can identify certain configuration and maintenance issues, including problems involving software versions, background processing, HTTPS and other technical requirements.

The interface includes a Status section and an Info section.

The Status section reports findings categorised according to their significance.

The Info section provides information about the WordPress installation, server environment and configuration.

A new website should be checked before launch.

However, Site Health is not a comprehensive security scanner or performance profiler.

A website can receive a satisfactory status while still containing inefficient plugins, broken front-end functionality or poorly configured caching.

Likewise, an individual recommendation does not necessarily indicate an urgent fault.

Review findings in context and investigate their causes before making changes.

The Site Health information can be useful when diagnosing hosting limitations or communicating with technical support, but review it before sharing because it may contain configuration details.

20. Backup and Recovery Configuration

Location: Hosting control panel or backup plugin; WordPress core has no general scheduled full-site backup settings screen

A new WordPress website should have a defined backup system before substantial content or transactions are added.

This is an operational configuration rather than a standard WordPress Settings screen.

A complete backup ordinarily needs to account for the database and relevant website files.

The database contains posts, pages, users, settings and other stored information.

The filesystem contains uploads, plugins, themes and potentially custom application files.

Some managed hosting providers supply automatic backups. Other installations require a separate backup solution.

Do not assume that the hosting provider’s backup service covers every relevant file or offers the retention period needed.

A backup strategy should specify:

• What is backed up.

• How frequently backups are created.

• Where copies are stored.

• How long they are retained.

• How restoration is performed.

• How backup completion and failures are monitored.

Keep at least some protected backups independently of the live hosting environment.

A backup that has never been restored is an unverified recovery mechanism.

Before launching the website, perform a restoration test where practical, preferably in an isolated staging environment.

For an active WooCommerce store, backup timing requires additional consideration because new orders and customer information may be created continuously.

Recommended Initial WordPress Configuration

The following table provides a practical starting point for a public WordPress website focused on articles, technical resources and downloadable products.

These are recommendations rather than settings that apply universally.

The precise configuration should be reviewed whenever the website’s purpose changes.

For example, introducing a membership system may require public registration, while adding WooCommerce may introduce account settings and transactional email requirements that did not exist when the site was first created.

Checking Settings Before the Website Goes Live

A configuration review is most useful when followed by actual functional checks.

After completing the initial settings, open the website in a browser session that is not logged into WordPress.

Confirm that the public homepage displays correctly and that the main navigation works.

Open several posts and pages to verify that their permalinks resolve.

Check whether the website is requesting search engines not to index it.

Inspect the administration email address and confirm that important notifications can be received.

If comments are enabled, check the intended approval process. If registration is enabled, verify the default user role and account creation process.

For a site using scheduled publication, create a test draft and confirm that the scheduling interface uses the expected timezone.

Check the website’s mobile layout and confirm that important images, stylesheets and scripts load over HTTPS without mixed-content problems.

Where a caching system is active, repeat relevant checks using a logged-out browser. Administrator sessions often bypass caching, which means a website may appear correct while logged in but serve outdated or broken pages to visitors.

Finally, confirm that a current backup exists and that recovery procedures are understood.

The value of an initial settings review is that it establishes a known, documented configuration. Once the website begins accumulating articles, plugins, custom code and digital products, problems become easier to diagnose when the original setup decisions are clear.