SEO helps search engines discover, process, and correctly present useful public pages. QA checks technical conditions and product agreements: content accessibility, metadata, addresses, and navigation. This is especially important after CMS, routing, or rendering changes.
A green SEO audit cannot guarantee indexing, rankings, or traffic; search engines make their own decisions. QA provides evidence that a release introduces no known technical barriers and follows agreed page rules.
How a page reaches search
Distinguish URL discovery, crawling, content processing, and indexing. A page may exist without reachable internal links. A crawler may know the address but receive an error. An accessible document may be excluded from indexing or treated as a duplicate.
Checking one meta tag cannot explain why an article is absent from search. Identify the questionable stage, then collect evidence from HTTP, page contents, and search-engine tools.
Title and description
The title names a document and communicates its purpose in tabs and search. Check relevance, language, template placeholders, and unwanted duplication across articles. Client-side navigation should update the title with the page.
Meta description briefly describes content. Google may use it in a snippet or generate different text. Avoid a universal exact-character-count criterion; display depends on the search engine and context. Check meaning, incomplete templates, HTML debris, and descriptions belonging to other pages.
What robots rules actually do
Meta robots and the X-Robots-Tag HTTP header can control indexing. An unexpected noindex on a public article after release is a serious warning. Check HTML and headers together: infrastructure may add a restriction despite correct CMS settings.
Robots.txt controls crawling and does not reliably protect private data. A blocked URL can still appear in search without content. A crawler prevented from accessing a page may also miss its noindex. Private content requires access controls.
Canonical URLs and duplicates
Canonical identifies a preferred address for identical or very similar pages. It is a search-engine signal, rather than a binding command. A template pointing every article's canonical URL to the homepage can hinder recognition of separate articles.
Check domain, protocol, path, and consistency with redirects, sitemap, and internal links. Agree language-version rules with an SEO specialist; translations should not automatically be treated as duplicates of originals. Accidentally retaining a staging address is a common release defect.
HTTP responses and redirects
Existing public pages should return their intended success response. A nonexistent article should not masquerade as useful content with status 200 and “nothing found.” This soft 404 makes resource state harder to interpret.
Check permanent redirects after address changes, loops, long chains, and deleted pages incorrectly redirected to the homepage. Status and destination must follow the migration plan. A browser rendering the final page does not reveal how many intermediate responses occurred.
Content, rendering, and links
Compare source HTML, final DOM, and visible content. If text appears only after JavaScript, verify that rendering does not depend on authentication, blocked resources, or actions a crawler need not perform.
Check the article heading, main content, reachable related-page links, and suitable image text alternatives. Test direct URLs as well as navigation within an already loaded application; client routing can hide server-routing failures.
Practical example: a knowledge-base release
Suppose articles are moving to a new domain. Each selected article has known old and new URLs and is intended for public indexing.
- 1.Open the new URL unauthenticated and inspect its HTTP response. Expect an accessible article, correct status, and no accidental noindex in HTML or headers.
- 2.Compare title, description, and canonical with the CMS entry. Expect that article's metadata and a working new-domain address.
- 3.Open the old URL. Expect the specified permanent redirect directly to the corresponding new article.
- 4.Check robots.txt, sitemap, and an internal section link. Expect consistent policy without accidental staging rules excluding public content.
- 5.After publication, use the team's available URL Inspection in Search Console. It should support assessing the specific address; appearance in results is not promised by a particular minute.
Diagnosing issues with tools
Network shows statuses, redirects, and X-Robots-Tag; source-response inspection shows server HTML; Elements shows the DOM after scripts run. Crawlers help find duplicate metadata and bad links at scale, but reproduce individual URLs manually too.
Report the exact URL, page type, environment, actual value, and agreed expectation. “Canonical points to staging” is actionable and verifiable; “bad SEO” is not.
Common mistakes and lessons
Mistakes include treating robots.txt as protection, demanding immediate indexing, and checking only the homepage. Another is carrying staging settings into production without inspecting final responses.
A minimal QA SEO suite covers HTTP, link discovery, metadata, restrictions, and addresses. It prevents technical loss of public pages and provides useful evidence for further SEO diagnosis.