The Pre-Launch SEO Checklist for a New Website

Most SEO damage at launch isn't clever. It's one checkbox. A developer ticks "discourage search engines from indexing this site" on the staging copy, the site goes live a month later, nobody unticks it, and three months on the owner is asking why Google shows nothing.

Short answer: A pre-launch SEO checklist is a short set of checks you run before a new website goes public. Search engines must be able to reach every page you want found, each page needs its own title and purpose, redirects from the old site must work, the site must be fast on a phone, and Google Search Console should be watching from day one. Do these and a new site starts indexing the week it launches. Skip them and you pay in lost weeks.

Run these checks before launch, not after, because some problems are cheap to fix on day minus ten and expensive on day plus sixty. Changing a URL pattern on a site with twelve pages takes an afternoon. Changing it on a site that already ranks means redirects, monitoring, and a dip in traffic while search engines catch up.

There's also a first impression effect. The first crawl of a new domain is when a search engine learns what your pages are called and how they connect. A blocked page can be fixed in minutes, but the days it spent invisible don't come back.

So treat the list below as a gate. The site doesn't go live until it passes.

Can search engines actually reach your pages?

Start here, because nothing else matters if the answer is no. Check three things.

First, open yourdomain.com/robots.txt. Staging sites often contain a rule that says "Disallow: /" to keep crawlers out. That line must not survive into production. Second, look for a noindex instruction, either as a meta robots tag in the page head or as an X-Robots-Tag header sent by the server. View the source of the live page and search for the word "noindex". Third, decide on one address for the site (with or without www, always over HTTPS) and make every other version redirect to it with a permanent 301 redirect.

One detail catches people out. robots.txt and noindex do different jobs. robots.txt controls whether a crawler may fetch a page. Noindex controls whether the page may appear in results. If you block a page in robots.txt, the crawler never fetches it, so it never sees the noindex tag on it. When you want a page kept out of search, use noindex and leave it crawlable.

Does every page have its own job?

A page that tries to rank for everything ranks for nothing. Before launch, write down, for each important page, the one question it answers or the one thing it helps a visitor do. "Custom Laravel websites in Cairo" is a page with a job. "Welcome to our company" is not.

Then give each page the basics:

• A title that says what the page is, with the main phrase near the front. Around 50 to 60 characters usually displays in full, and longer titles tend to get cut.
• A meta description of roughly 120 to 155 characters, written for a person deciding whether to click. Google sometimes rewrites it, but a clear one still shapes how your result looks.
• One H1 that matches the page's purpose, followed by H2 headings that break the page into the questions a visitor would ask.
• A readable URL: lowercase, words separated by hyphens, no database IDs. /services/web-development tells everyone what it is. /page.php?id=47 tells no one.

Watch for duplicates. Two pages with the same title confuse visitors and search engines alike. The same goes for a staging copy left open to the public next to the live site, which is duplicate content on a grand scale.

What happens to the old website's URLs?

If you're replacing an existing site, this is the step most likely to cost you traffic. List every old URL that gets visits or has links pointing at it. Search Console and your analytics will show you which ones. Each of those needs a 301 redirect to its closest equivalent on the new site.

Closest equivalent matters. If an old page about logo design redirects to the new homepage, the search engine sees that the old page has no real match and treats it much like a deleted page. Send it to the new page that covers the same topic.

Prepare a proper 404 page too. Visitors will hit dead links no matter how careful you are, and a 404 that offers your main sections and a way to contact you keeps some of them.

Is it fast and comfortable on a phone?

A large share of visitors will open your site on a phone, often on mobile data. A site that feels instant on a developer's laptop can feel sluggish there. Run your main pages through PageSpeed Insights, then do the more honest test: pick up an actual phone and use the site as a stranger would.

The causes of slow pages are usually boring. Oversized images. Too many third-party scripts. Fonts loaded from several places. Page-builder templates that ship far more code than the page uses. It's one reason we write sites by hand in Laravel, so each page sends only what it needs. If you're still choosing a platform, our comparison of Laravel and WordPress covers where that trade-off matters and where it doesn't.

Beyond speed, check that text is readable without zooming, buttons are big enough to tap, and nothing forces sideways scrolling.

Content, images and internal links

Give every meaningful image a short, descriptive alt text. Decorative images should have an empty alt attribute so screen readers skip them.

Make sure every important page is linked from somewhere visible. A page that no other page links to is hard for crawlers to find, and it sends no signal about how much it matters. Link your main pages from the navigation, and link related pages from the body text using descriptive wording, such as "our e-commerce development service", rather than "click here".

Then read the site once as a stranger. Does the first screen of each page say who you are, where you are and what you do? Place names and service names that real customers type should appear in plain words. If you serve clients in Egypt, the Gulf and Europe, say so on the page rather than hoping search engines infer it.

Finally, hunt down leftovers. Placeholder paragraphs, "lorem ipsum", test pages and the sample blog post all get indexed if they're public.

Sitemap, structured data and language versions

Generate an XML sitemap that lists the pages you want indexed and only those. No redirected URLs, no noindex pages, no 404s. One sitemap file can hold up to 50,000 URLs or 50 MB uncompressed, which is far more than a business site needs. Reference it in robots.txt with a Sitemap line that uses the full https address.

Structured data is optional, but it's worth an hour. At minimum, mark up your organization (name, logo, address, links to your profiles) and, for articles, the Article type with headline, author and dates. Validate it with Google's Rich Results Test. Only mark up what is actually visible on the page, because describing content that isn't there goes against Google's guidelines.

If the site has Arabic and English versions, each page needs hreflang annotations that point to its twin, and each version should also reference itself. Get this wrong and the wrong language can show up in the wrong country, or one version can be treated as a duplicate of the other.

Set up measurement before the first visitor, and keep watching after

Verify your domain in Google Search Console and submit the sitemap on launch day. Add Bing Webmaster Tools as well, which takes five minutes. Install analytics and decide in advance which actions count: contact form submissions, WhatsApp taps, phone calls. Without those, you'll know that people visited but not whether the site did its job.

Check security basics while you're there. HTTPS on every page, a valid certificate, and no mixed-content warnings from images or scripts still loading over plain HTTP. If your analytics sets cookies, the consent banner and privacy page need to be live before the first visit, not after.

Launch isn't the end of the list. In the first two weeks:

• Open the Pages report in Search Console every day for the first week and read the reasons it gives for any excluded page.
• Use URL Inspection on the homepage and your two or three most important pages, and request indexing.
• Crawl your own site with a desktop crawler to catch broken links, missing titles and accidental redirect chains.
• Check the 404 report and add redirects for old URLs that still get visits.

Then leave the titles alone for a while. Rewriting every page title each day gives search engines nothing stable to evaluate. Rankings take weeks to settle, and the first few days of data are noisy.

Frequently asked questions

How long does a new website take to appear on Google?

A crawlable site that's linked and submitted in Search Console can have pages indexed within days. Ranking well for competitive phrases takes longer, usually weeks to months, depending on competition and content quality. Nobody can honestly promise a position.

Do I need paid tools before launching?

No. Google Search Console, PageSpeed Insights and the Rich Results Test are free and cover everything above. Paid tools become useful later, for keyword research and ongoing monitoring.

Should I add a blog before launch?

Not necessarily. Launch with strong core pages first, because those are what turn visitors into inquiries. A blog helps when you can publish specific, useful articles on a steady schedule, not as a box to tick.

Before you press publish

If you want a second pair of eyes on a site before it goes public, or you're planning a build where these checks are part of the handover, talk to us. A technical SEO foundation is part of every web development project we deliver.