How to publish a website: domain, hosting, DNS, and post-launch checks

DNS settings: A, AAAA, CNAME, and MX records

Although DNS settings look complicated at first, two or three records are generally enough to launch a website. The roles of the record types are as follows:

1. A record: Points the domain to the server’s IPv4 address. The root domain (örnek.com) is usually connected to hosting through this record.
2. AAAA record: Does the same job for an IPv6 address. Do not add it if the hosting company does not provide an IPv6 address; leaving an old, incorrect AAAA record may send some visitors to the wrong server.
3. CNAME record: Points a subdomain to another name; connecting www.örnek.com to örnek.com is a typical use.
4. MX record: Specifies which server receives email sent to the domain. There is no need to touch the MX record to publish the website.
5. TXT record: Used for verification and email security; Search Console verification can also be performed with this record.

The most common costly mistake is deleting or overwriting MX and TXT records when launching the website. If corporate email runs on another service, preserve these records as they are and change only the A, AAAA, and CNAME records related to the website.

How long does a DNS change take to propagate?

A DNS change does not appear everywhere instantly; propagation can take hours because old information may remain cached until the records’ TTL expires. Google’s Search Console site ownership verification page states that it may take a few minutes or even a few days for Google to see an added DNS record. During this period, some visitors may see the old server and others the new one; lowering the TTL before a major change can shorten the transition.

How can you tell whether the records were entered correctly?

After the change, compare the IP address provided by the hosting company with the IP address the domain points to. The nslookup tool, which runs from the computer’s command line, or online DNS lookup tools show the address to which the domain currently points. If results differ between servers, propagation is not yet complete; wait a while before changing the records again.

SSL and HTTPS: a free certificate with Let’s Encrypt

Opening a live website over HTTPS is now a basic expectation; browsers mark pages without certificates as not secure, and form data travels without encryption. Let’s Encrypt’s getting started page describes the organization as a free, automated, and open certificate authority operated by the nonprofit ISRG. Certificates are distributed automatically through the ACME protocol; the page presents two routes: automatic certificate management by the hosting provider, or running an ACME client such as Certbot if sufficient server privileges are available.

For most businesses using shared hosting, the certificate is enabled with a few clicks in the hosting control panel. After installation, two tasks remain: permanently redirecting all http addresses to https and loading the website’s images, scripts, and links over https. Google’s consolidating duplicate URLs page states that HTTPS pages are preferred over equivalent HTTP pages and recommends adding redirects from HTTP to HTTPS.

The certificate must cover both the www and non-www addresses; a certificate installed for only one shows a security warning to visitors arriving at the other address. After installation, clicking the lock icon in the address bar lets you see which address the certificate was issued for and its validity date. If the certificate does not renew automatically, record its expiration date in the calendar.

Moving a WordPress website from local or staging to live

If the website was prepared on a computer locally or in a staging environment, publication takes place by moving its files and database to the live server. For a business using WordPress, the answer to how to publish a website is usually this migration work. WordPress’s official migration documentation asks that the WordPress folder, images, plugins, and database be backed up before the procedure. Broadly, the migration steps follow this sequence:

1. Back up the source website’s files and database.
2. Upload the files to live hosting, transfer the database to the new server, and update the database information in wp-config.php.
3. Adjust “WordPress Address (URL)” and “Site Address (URL)” for the new domain; according to the documentation, the first indicates where the core files are located, and the second indicates the address visitors will enter in their browsers.
4. Replace old addresses in the database (localhost or the test domain) with the new one.
5. Save permalinks again, and test pages and forms at the live address.

The point requiring the most care in step four is serialized data. The WordPress documentation warns that a plain find-and-replace across the entire database can break some theme and widget settings, and recommends using plugins designed for this purpose or WP-CLI’s search-replace command instead. The same documentation also specifically emphasizes that the GUID column for posts must never be changed. How migration work is carried out is explained on the WordPress website migration page.

Website launch checklist

A website launch checklist closes the gap between “the website opens” and “the website does its job.” After the address change, perform the following checks on the live domain:

According to WordPress’s Reading Settings documentation, selecting “Discourage search engines from indexing this site” adds a noindex, nofollow tag to the page’s head section. The documentation also notes that this setting does not block access to the website and that honoring the request is up to the search engine. Because the content of KVKK and cookie notices varies with the business’s data processing practices, confirmation of the texts with a legal professional is recommended.

After launch: adding the website to Search Console and submitting a sitemap

The question of how to publish a website does not end when the website opens; Google Search Console is the official way to notify Google. Google’s adding a property page defines two property types. A Domain property covers all http, https, www, and subdomain versions and is verified only through a DNS record; a URL-prefix property covers only pages starting with the specified protocol and address and offers several verification methods.

According to Google’s verification page, the TXT record added for verification must not be deleted from DNS even after verification succeeds; deleting it may cause the property to become unverified. After verification, the next steps are as follows:

• Open the sitemap address generated by the SEO plugin or WordPress core in the browser to confirm that it works.
• Enter and submit this address in the Sitemaps report in Search Console.
• Use the URL Inspection tool to check that the homepage is accessible to Google.
• After a few days, check the page indexing report for “noindex” or “blocked by robots.txt” warnings.

Google’s sitemap management page explicitly states that submitting a sitemap does not mean every listed URL will be crawled or indexed. When ownership permissions are unavailable, the sitemap can also be specified in the robots.txt file.

Adding the website to Google Business Profile and Bing Webmaster Tools

For a business serving local customers, the final step on the how-to-publish-a-website list is entering the new address in Google Business Profile. Google’s editing a Business Profile page asks for the full URL, including “http://” or “https://”, to be entered in the website field. If the website has moved to HTTPS, updating the profile address to the version beginning with https eliminates an unnecessary redirect.

On Bing, use Bing Webmaster Tools. Bing’s import announcement explains that websites verified in Search Console can be imported directly into Bing Webmaster Tools and that imported websites are automatically verified. Once Search Console setup is complete, this route handles Bing verification without the need for a separate DNS record.

Common mistakes when publishing a website online and the correct approach

Most mistakes during website publication go unnoticed because the website opens; their effects appear weeks later in indexing reports or missing emails. The most common examples and their correct alternatives are as follows:

• Separate www and non-www versions: If both addresses open separately, choose one and connect the other to it through a permanent redirect. Google sees redirection as a strong signal about which URL should be considered canonical.
• Links left on http: If http addresses remain in menus, images, and text links, the browser may show a mixed content warning. Update old addresses in the database using a safe find-and-replace tool.
• The staging website being indexed: Protect the test environment with a password and mark it noindex. According to Google’s blocking indexing documentation, a noindex rule on a page blocked through robots.txt is never seen; do not use the two methods together on the same page.
• Test settings moving to the live site: The search engine block left enabled on staging moves to the live website with the copied database.
• Deleting MX records: Recreate the old email records in the new control panel when changing nameservers.
• Launching without a backup: Back up both the source and destination before migration.

Launching it yourself or getting support?

For a new domain with a single-page website and no email service, publishing a website is something business owners can do themselves using the hosting control panel’s wizards. Complexity begins when the domain already has working corporate email, an old website, or multiple DNS services. For a business owner researching how to publish a website, the real decision is who will manage these risks.

A common general practice is to upload the files to the server and consider the job finished when the website opens. Onur Freelance takes a different approach: launch begins with a backup of DNS records and is not considered complete until the indexing report in Search Console looks clean. Hosting’s impact on speed and search visibility is addressed separately in the hosting selection article.

The launch process and cost items at Onur Freelance

Onur Freelance is a studio providing web design and digital marketing services from Maltepe/Istanbul since 2019; launch is carried out as part of the website delivery process. The domain and hosting are opened in the business’s name, and administrator access remains with the business. Onur Freelance is not an official support channel for Google, domain registrars, or hosting providers; these organizations have their own separate control panels and support lines.

The fixed cost items on the publication side are as follows:

• Hosting: 2,000 TL per year; details are on the hosting prices page.
• Domain: 1,000 TL per year; when purchased with hosting, the two cost 3,000 TL.
• Maintenance: Post-launch updates, backups, and security monitoring range from 500–2,000 TL per month.

If the website itself has not yet been built, a single-page website starts at 12,000 TL, a corporate website at 15,000 TL, and an e-commerce website at 24,000 TL. If search visibility is a goal after launch, check whether the website’s technical infrastructure is SEO-friendly; ongoing SEO work starts at 9,000 TL per month. No promise is made about rankings or indexing time; these decisions belong to search engines.