Once WordPress is installed, it is tempting to open every settings screen and start changing things. That is not necessary.
Some choices matter immediately because they affect your website’s name, URLs, search visibility and visitor interaction. Others can safely remain at their defaults. A few technical fields are worth recognising mainly so that you know not to experiment with them.
I had used WordPress for years before I even noticed the WordPress Address and Site Address settings. My websites worked because the hosting platform had configured them correctly, and I had no reason to interfere.
That experience captures the purpose of this guide: check what matters, recognise what should be left alone and then start publishing.
Before changing anything, record what is already there
Open Settings in the WordPress dashboard and look through the relevant screens before saving anything. If you are unsure about an existing value, take a screenshot or make a note of it. Change one group at a time so that an unexpected result is easier to trace.
You should also know:
- how to log into WordPress directly;
- where your hosting support is located;
- whether a current backup exists;
- how that backup could be restored.
Recording the starting point is a useful habit whenever you work on a website.
Set a clear site title and use a tagline only when it helps
Under Settings → General, the Site Title is the recognisable name of the website. The Tagline is an optional short description of what it does.
I always enter a site title. I sometimes use a tagline, but I do not believe every website needs one merely because WordPress provides the box.
On Action With AI, I currently have the complete phrase below in the Site Title field:
Action With AI — Build Helpful Websites Using AI and Real Human Experience
The separate Tagline field is blank.
Another valid arrangement would be:
- Site Title: Action With AI
- Tagline: Build Helpful Websites Using AI and Real Human Experience
Themes and SEO plugins can use or display these fields differently, so the visible result matters more than following one rigid format. Check how the title appears publicly and in the browser.
A tagline is useful when the name does not explain the subject. “Action With AI” could cover many uses of artificial intelligence, so the additional wording helps identify the website’s focus.
Remove any generic wording left by an installer. A default phrase such as “Just another WordPress site” makes the site look unfinished and tells the reader nothing useful.
Confirm both important email addresses belong to you
WordPress can hold two email settings that are easy to confuse.
The Administration Email Address under Settings → General receives site-level messages. These can include comment moderation, maintenance, update and critical-error notifications.
Your individual WordPress account also has an email address under Users → Profile. That address belongs to your user account and can be involved in account recovery.
On a one-person hobby website, using the same accessible email address for both is perfectly reasonable. That is what I do. The important point is that you control the inbox and expect to retain access to it.
I once tried to change my Administration Email Address, but the confirmation message never arrived. Because the change was not important, I did not investigate further.
WordPress does not activate a proposed new administration address until its confirmation link has been used. Until then, the existing address remains active. If your confirmation does not arrive, check the spelling and spam folder first. A continuing problem may indicate that WordPress email delivery needs investigating with your host. WordPress General Settings guidance
Do not leave either email under the control of a developer, former colleague or anybody else who originally helped build the site.
Choose your actual time zone
The time-zone setting affects scheduled publication, displayed post times, comment timestamps and some scheduled plugin activity.
I rarely schedule posts, so it has little effect on my normal publishing process. An incorrect setting can still make it look as though you regularly publish in the middle of the night.
Choose a named city in your time zone—London in my case—rather than an unfamiliar fixed UTC offset. A named location allows WordPress to account for seasonal clock changes.
There is no need to manufacture a regular publishing timetable to make the site appear legitimate. Publish useful work when it is ready.
Leave public registration disabled unless accounts have a purpose
The Membership option under Settings → General includes a box labelled Anyone can register.
For an ordinary one-owner hobby website, leave it unticked. Visitors do not need WordPress accounts simply to read posts or leave moderated comments.
I have always kept public registration disabled. I once considered a course website using an LMS—a Learning Management System—where students might need accounts. Even then, I would follow the chosen plugin’s registration instructions rather than enable open registration without understanding it.
If your site genuinely requires registration, check the default user role carefully. A new public user should not receive Administrator, Editor or Author permissions by accident. A restricted role such as Subscriber is the normal starting point unless the application has a specific requirement.
There is also no need to create fictional authors merely to make a personal website look like a large publication. Several genuine contributors are fine; an invented editorial team risks reader trust. Google’s people-first guidance encourages accurate information about who created the content and their relevant background. Google’s people-first content guidance
One identifiable enthusiast sharing genuine experience can be more credible than a list of artificial personas.
Decide whether the homepage should guide or update
Under Settings → Reading, WordPress can show either:
- your latest posts; or
- a static page selected as the homepage.
Neither choice is automatically better.
When latest posts may work well
A blogroll can suit a site where:
- new material is the main attraction;
- returning visitors may want to see what was published recently;
- posts can be read in different orders;
- the owner wants to show that the website is active.
Action With AI currently uses this arrangement. I wanted the homepage to show a growing body of work, while the Start Here page and main menus provide a more structured route through it.
When a static homepage may work better
A static homepage can suit a site where:
- beginners need an introduction;
- several different content paths must be explained;
- one starting route should receive special prominence;
- important guidance should not move down a chronological feed.
If you select a static homepage, WordPress also allows you to assign a separate page to display the posts archive. The homepage and posts page cannot be the same. WordPress Reading Settings guidance
I could reasonably have made Start Here the Action With AI homepage. Another option would combine a short introduction and links to the main pathways with a recent-posts section.
Choose the homepage for visitors, not crawlers
I wondered whether a blogroll gave crawlers one place to find every post. It exposes recent links, but older posts move through numbered archive pages; it is not normally one page containing everything.
An XML sitemap provides search engines with a more direct list of the URLs you consider important, although it does not guarantee that every page will be crawled or indexed. Topic hubs, categories and contextual internal links also help show how pages relate to one another. Google’s sitemap guidance
Choose the homepage for the reader. Use the sitemap and internal linking structure to support discovery and understanding.
Make sure search engines are not being discouraged
Also under Settings → Reading is:
Discourage search engines from indexing this site
When a public site is ready to be found, this box should be unticked.
WA installations leave it unticked in my experience, and I have never enabled it. Some people use it while constructing a site, but the danger is forgetting to change it at launch.
The setting does not make a website private. Visitors can still open it, and WordPress describes it as a request that search engines should honour rather than a form of access control. WordPress Reading Settings guidance
Unticking it does not guarantee that Google will crawl, index or rank every page. It simply removes one avoidable obstacle.
Use Post name permalinks and keep slugs descriptive
A permalink structure is the site-wide format WordPress uses for post addresses. A slug is the editable final part of one particular post or page URL.
For example:
The site may use the Post name permalink structure, while how-to-grow-tomatoes-in-pots is the individual slug.
I have always used Post name, which you can select under Settings → Permalinks. It produces readable addresses without adding publication dates or unexplained post numbers. WordPress Permalinks guidance
WordPress normally generates the slug from the post title. I usually keep it because a descriptive title should already communicate the subject. If it is unusually long, I shorten it while retaining the identifying words.
Descriptive slugs also help me manage the site. When adding an internal link, I search using relevant words. A recognisable title and slug help confirm that I have selected the correct page; heavy abbreviation can make that slower.
Finalise the slug before publishing
In my early days, I changed the slug of an indexed post without understanding why that created a problem.
Search engines, internal links, bookmarks and other websites may continue requesting the original URL. Without a redirect, those visits can reach a missing-page error.
It is safest to check the slug before publishing and then treat it as established. A page can be discovered quickly, so a post being live for only a few hours is not proof that changing its address is consequence-free.
If a published URL genuinely needs to change:
- Create a permanent redirect from the old address to the new one.
- Update your internal links so that they point directly to the new URL.
- Test that the old address forwards correctly.
- Check the replacement through your sitemap and Search Console.
A redirect plugin can make the basic mapping straightforward: provide the old URL and tell it which new URL should receive those visits.
Changing a slug may be justified when several pieces of evidence indicate that a page is being significantly misunderstood and the old address contributes. It should not be the first response to one surprising query or AI answer.
Redirects are a safety mechanism, not permission to keep rebuilding the website. Plan once, check with evidence and change only for a clear reason.
Replace “Uncategorized” with meaningful categories
WordPress assigns a default category when you publish without selecting one. “Uncategorized” rarely helps a reader understand where a post belongs.
Create a small set of meaningful categories based on the real divisions in your content. You can then change the default under Settings → Writing or make a habit of assigning the correct category before every publication.
Avoid creating a new category for every slightly different subject. Keep the structure simple, connect related posts and concentrate on creating content rather than continually reorganising everything.
Allow comments—but keep control of what appears
I normally allow comments because genuine questions and experiences can add to an article. I also require approval before any comment becomes public.
Some submissions contain meaningless praise and links to dubious websites. Spam has never become unmanageable on my sites, so manually approving genuine comments and deleting rubbish has been sufficient.
For a new hobby website, a sensible starting point under Settings → Discussion is:
- allow comments on new posts if you want engagement;
- require an administrator to approve comments;
- require the commenter to provide a name and email address;
- delete obvious spam and unrelated promotional links;
- consider disabling comments on functional pages where discussion adds little.
WordPress does not verify that a supplied commenter name and email address are genuine. Requiring them merely adds a small barrier. WordPress Discussion Settings guidance
Low traffic will often mean a manageable volume, but automated bots can still discover a quiet site. Receiving spam does not mean the website has suddenly become popular. If manual moderation later becomes burdensome, that is the time to consider an anti-spam service.
Delete demonstration content, but inspect the privacy-policy draft
A new WA site normally contains a “Welcome to your new website” post. Other installations may include WordPress’s “Hello world!” post, a sample page or a default comment.
Delete anything that exists only to demonstrate that WordPress works. I remove the WA welcome post and sample page because neither belongs to the website I intend to build.
After deleting them:
- check the posts and pages lists;
- remove any sample comment;
- make sure the menu does not still link to deleted material;
- empty the trash once you are certain nothing is needed.
A privacy-policy draft is different. Do not delete it automatically as though it were meaningless sample content.
WA provides a privacy-policy template, and an LLM can help draft or adapt one. Whichever starting point you use, the finished policy must reflect what the website actually does, including comments, analytics, contact forms, cookies, mailing lists and other services.
A quiet site presents less immediate exposure than a major commercial website, but its first visitor still has privacy rights. Laws differ between countries, and what applies can depend on where you operate, who you target or monitor and what information you process.
Check authoritative guidance for the relevant jurisdictions. For UK-based owners, the Information Commissioner’s Office provides a privacy-notice generator for small organisations.
A template or AI-generated policy is a starting point, not proof that the website complies with every law that may apply.
Check the backup before installing updates
WordPress, themes and plugins should be kept updated. I normally install updates manually when their dashboard notices appear.
I have relied on WA’s backup process, including when SiteSupport restored a site after I accidentally deleted important files. Writing this guide has made me realise that I should verify the backup before clicking Update rather than assume it is available.
Before an update:
- Confirm that a recent complete backup exists.
- Know where the restore option or support route is.
- Read any prominent compatibility warning.
Afterwards, open the public site, check an important page and confirm that the WordPress editor still works normally.
Updating plugins separately or in small groups can make it easier to identify the cause if something breaks. That is not a reason to leave security updates waiting indefinitely.
WordPress’s Tools → Export feature provides a useful additional copy of content such as posts, pages, comments, categories and tags. I use it myself. However, the WXR/XML export is not a complete restorable backup of the website’s database, uploaded files, themes, plugins and configuration. WordPress export guidance
Before clicking Update, make sure a current backup exists and that you know how it would be restored.
Confirm HTTPS—and leave the address fields alone
The two fields that I had overlooked for years appear under Settings → General:
- WordPress Address (URL)
- Site Address (URL)
The WordPress Address identifies where the WordPress software is installed. The Site Address is the public location visitors use to reach the website.
On a straightforward installation at the main domain, they are normally identical:
They can differ in a deliberate advanced setup, such as keeping the WordPress files in a subdirectory while displaying the site at the main domain.
Changing either value incorrectly can affect access to the whole website. This is much more serious than editing one post slug. A managed host may also define or control these values elsewhere.
Check that the public site loads at the intended https:// address without a browser security warning. If the host has configured both address fields correctly and the site works, leave them alone.
Do not change them merely to experiment, add or remove www, or make the address look tidier. Follow your host’s supported instructions or ask for help if a genuine site-wide URL change is required.
A final check before publishing
Before publishing your first real article, confirm that:
- The Site Title is correct and the Tagline is useful or intentionally blank.
- The Administration Email Address and your user email belong to you.
- The time zone is correct.
- Public registration is disabled unless accounts are deliberately required.
- The homepage display suits the intended visitor experience.
- Search engines are not being discouraged on the public site.
- Permalinks use Post name and the post slug has been checked.
- A meaningful category is selected.
- Comments require moderation if they are enabled.
- Demonstration content has been removed.
- The privacy notice reflects the site’s actual data use.
- A recent backup and restore route exist before updates.
- The public site loads over HTTPS.
- The WordPress Address and Site Address have not been casually altered.
My conclusion
The purpose of these settings is to create a stable base for publishing, not to begin an endless website-configuration project.
Make the few decisions that affect ownership, presentation, URLs, indexing and visitor interaction. Check that updates can be recovered from and that the public website works securely. Leave correctly configured technical fields alone.
The goal is not to perfect every WordPress option. It is to remove the avoidable problems that could interfere with publishing, access or discovery—and then begin building the website with genuinely useful content.