SEO does not begin after launch.

That is when the mistakes become public.

A website can look finished while canonical tags point to staging, Bangla pages reference missing English versions, structured data names the wrong person, and the sitemap changes every time it is requested.

My launch review is a reconciliation exercise.

Every layer should describe the same website.

1. Inventory public URLs

I list:

• home and language versions;
• service and product pages;
• blog indexes and articles;
• privacy and policy pages;
• feeds and discovery files;
• redirects;
• old URLs that must remain reachable;
• routes that should never be indexed.

Then I mark each URL:

• indexable;
• noindex;
• redirected;
• private;
• duplicate;
• canonical target.

If ownership is unclear in a spreadsheet, it will be unclear in code.

2. Verify meaningful rendering

Public pages should return useful content and links without depending on a post-load client request.

I trace:

• main heading;
• primary copy;
• navigation links;
• article content;
• author information;
• error and not-found behavior;
• assets required to understand the page.

Google can render JavaScript, but reliable server rendering reduces dependencies and helps other crawlers too.

3. Reconcile canonical signals

For each indexable page:

• internal links use the preferred URL;
• canonical points to that same URL;
• sitemap lists that URL;
• redirects land on it;
• language alternates reference it;
• no robots directive conflicts.

A canonical is a hint, not a repair tool for a confused architecture.

4. Keep robots simple

robots.txt controls crawler access.

It does not protect secrets or private data.

I avoid blocking framework assets required for rendering. I block public crawling only where there is a deliberate reason, and use authentication for private content.

For AI search visibility, I confirm the wildcard rule does not block search-specific crawlers such as OAI-SearchBot, Claude-SearchBot, or PerplexityBot.

Crawler access makes discovery possible.

It does not guarantee retrieval or citation.

5. Make the sitemap factual

The sitemap should contain indexable canonical pages only.

lastmod should reflect a real meaningful change—not the time the sitemap was requested.

For English and Bangla counterparts, the sitemap relationship should match the HTML hreflang relationship.

I do not add priority or changefreq as decoration.

6. Check every metadata template

Representative pages from each template need:

• specific title;
• useful description;
• canonical;
• language alternates;
• accurate Open Graph data;
• appropriate robots settings.

I check for brand duplication from title templates.

I also confirm missing content produces a real not-found state instead of a thin indexable page.

7. Validate structured data against visible truth

The homepage can describe the person and website.

Blog posts can describe the article and author.

Every field should match visible content:

• name;
• alternate names;
• role;
• image;
• headline;
• dates;
• language;
• section;
• URL.

I safely serialize JSON-LD and never place private customer data or secrets inside it.

Valid schema can help understanding and eligibility. Google still decides whether any enhanced appearance is shown.

8. Audit international pairs

For each English/Bangla pair:

• both exist;
• both are genuinely localized;
• each has a self-canonical;
• both reference each other;
• x-default points to the intentional fallback;
• language switch reaches the real counterpart;
• internal links stay coherent;
• titles and descriptions are localized.

Publishing one language without its promised counterpart is a content failure, not only an SEO failure.

9. Review content trust

I remove:

• unsupported metrics;
• invented outcomes;
• fake precision;
• guarantees;
• stale “latest” claims;
• decorative citations;
• claims that a file controls every AI system.

I add:

• clear authorship;
• firsthand reasoning;
• limitations;
• real revision dates;
• descriptive internal links;
• a next step that matches the article.

Google’s people-first content guidance is a better editorial standard than a keyword-density score.

10. Protect page experience

Before release, I inspect the code path for:

• primary image dimensions and priority;
• font loading;
• layout reservation;
• client JavaScript;
• third-party scripts;
• long interactions;
• loading and error states;
• mobile overflow;
• reduced motion;
• keyboard access.

Without authorized runtime testing and field data, I do not claim Core Web Vitals passed.

Code review can find risks.

Real users and measurement confirm outcomes.

11. Prepare measurement

The release needs:

• Google Search Console ownership;
• Bing Webmaster ownership;
• sitemap submission;
• analytics for qualified contact actions;
• error monitoring;
• server or platform logs;
• a release annotation;
• a baseline query and landing-page report.

No measurement, no responsible claim of improvement.

12. Verify after deployment

After an authorized deployment:

1. inspect representative live URLs;
2. confirm headers and initial HTML;
3. fetch robots and sitemap;
4. validate structured data;
5. inspect English/Bangla pairs;
6. submit the sitemap;
7. request indexing only for important changed URLs where appropriate;
8. monitor coverage, selected canonicals, performance, and inquiries.

The repository can be correct while the deployment is stale.

The deployment can be correct while a search engine has not processed it yet.

Report those states separately.

The launch rule

Do not chase an aggregate score.

Make the website fetchable, understandable, internally consistent, useful, and measurable.

Then publish evidence—not promises.

For Next.js implementation details, read Next.js SEO Without the Myths. For performance budgets, read the budget I set for client projects.

If a launch is close, send me the route families, production domain, and what changed.