Editorial illustration; the checks are representative of a new site and are not a screenshot of a particular hosting panel.
Installing WordPress is the visible milestone. It is not the point at which the site is ready. A new dashboard can still have the wrong site address, an accidental public setting, an administrator account that nobody needs, broken permalinks or an untested theme.
This guide is for a new site owner or developer who wants a known-good baseline before adding pages, plugins and real content. The exact labels can vary by WordPress version and hosting setup, but the order matters: establish identity and access first, then test the path a visitor will use.
Summary
- Confirm the site identity, URLs, timezone and privacy settings before publishing.
- Keep administrator access narrow, test permalinks and update the small set of installed software.
- Create one test page and verify it as both an editor and an anonymous visitor.
1. Confirm the two site URLs
Open Settings > General and inspect the WordPress Address and Site Address. They are often the same, but a deliberate difference can exist in some deployments. Check the protocol, hostname, spelling and whether the site should use www.
Do not change the URL casually on a live site. A URL change affects links, media paths, redirects, cookies and sometimes serialized settings. For a new installation, fixing an obvious mistake early is easier than repairing a populated site later.
Write the intended public URL in the project notes. A future contributor should not have to infer it from a browser tab.
2. Set the site timezone and language
In Settings > General, choose the site language, timezone, date format and time format deliberately. Timezone affects scheduled publishing and the interpretation of logs. A server located elsewhere does not mean the site should use that server’s local time.
If the site serves Malaysian readers, choose the language and time convention that make editorial work clear to the people maintaining it. Then schedule a private test post and confirm the displayed time rather than assuming the setting worked.
3. Review the visibility and discussion defaults
Check the reading and discussion settings before you publish. Decide whether search engines should see the site while it is being built, whether comments are needed, and how unapproved comments are handled.
This is a decision, not a magic SEO switch. A private staging site should not accidentally become the public site, but a production site should not remain hidden because nobody revisited a temporary setting.
4. Remove accounts and content you do not need
List the users under Users. Keep one named administrator account for the person who needs that capability, then use lower-privilege roles for ordinary writing or editing. Do not share one administrator password across a team.
Remove sample posts, pages, comments and themes only after checking that the site does not rely on them. A blank installation is a good time to understand what exists. It is not a good reason to delete blindly on a migrated site.
For the same least-access principle, see WordPress Roles and Capabilities: Give Each User Only the Access They Need.
5. Check the permalink structure with one real test
Choose a readable permalink structure appropriate for the site. Save the setting, create a private test page, and open its public-looking URL in a new browser tab.
Check the response when you are logged out or use a private window. A page that works only for the administrator is not a successful test. If the URL returns a 404, inspect rewrite support, hosting configuration and caching before installing another plugin.
Do not change permalink structures repeatedly after publishing. Every change creates old URLs that need a redirect or a deliberate retirement plan.
6. Update core, themes and plugins before adding more
Open the updates screen and inspect what is installed. Apply updates according to the site’s risk and testing process, then remove software that has no role. Do not install a collection of plugins merely because a tutorial lists them.
Record the versions after the update. If something breaks, you need to know what changed. How to Evaluate a WordPress Plugin Before Installing It explains why fit and maintenance matter as much as the feature list.
If the site is already serving visitors, take a verified backup and test a recovery path before a large update. A backup that has never been restored is an assumption, not a recovery plan.
7. Check the administrator recovery path
Confirm that the administrator email address is monitored and that password recovery reaches the intended person. If two people maintain the site, both should have separate accounts and a documented handover path.
Avoid putting recovery codes, passwords or private keys in article notes. Store them in the organisation’s approved password manager. The point of this check is to make a lockout survivable, not to create another secret copied into a project chat.
8. Inspect the theme before customising it
Visit the site as a visitor. Check the header, navigation, typography, footer, mobile layout and the default 404 page. Look for placeholder text, links to the theme author, missing site identity or contrast problems.
Make a short list of changes that are actually required for the first release. A new site does not need every design option adjusted before its content model is understood. Excessive customisation early can make later changes harder to diagnose.
9. Test the first content path end to end
Create one representative page with a heading, paragraph, link and image. Publish it only if you are ready to inspect the public result; otherwise use a private or staging environment. Open the page as an anonymous visitor and test the navigation link, image, browser title and mobile layout.
Then edit the page, save the change and confirm the updated result appears. If a cache is present, identify the safe way to purge or bypass it. This small test reveals more than an empty dashboard because it exercises the path a real editor will use.
10. Write down the baseline
Record the public URL, WordPress version, active theme, installed plugins, administrator owner, timezone, permalink choice, backup location and the date of your visitor test. Add the first safe maintenance action: for example, update monthly in staging, review accounts quarterly, or test a restore before the next major change.
This document does not need to be elaborate. It only needs to tell the next person what “normal” looked like on the first day and where to start if the site behaves differently.
Common mistakes
- Treating the dashboard as proof that the public site works.
- Changing URLs after content has already been published without mapping redirects.
- Giving every contributor administrator access.
- Installing plugins to solve problems that have not been observed.
- Updating software without recording what changed or testing recovery.
My Take
The best first-day WordPress setup is deliberately boring. You want a site whose identity, access, URLs and visitor path are understood before creative work adds complexity. Ten minutes spent on a test page can save an afternoon of arguing about whether the problem is the theme, the cache or the editor.
Conclusion
Check the site identity, time, visibility, accounts, permalinks, updates, recovery path and theme before publishing real content. Finish with a visitor test and a short baseline note. You are ready when another person can understand the site and repeat the basic checks, not merely when the installer says “success”.