Start with the symptom, not the checklist.
A technical review should begin with something that changed or failed. Maybe an important service page disappeared after a redesign. Product pages are being treated as duplicates. Mobile visitors cannot complete an appointment request. A JavaScript application shows content to users but returns little useful HTML to some crawlers. Analytics stopped recording the form that the sales team uses.
| What you see | Evidence to check first | Likely owner |
|---|---|---|
| Important pages disappeared after a migration | Redirects, HTTP responses, canonicals and index status | SEO and developer |
| Google finds the wrong URL version | Canonical signals, internal links and sitemap entries | SEO and developer |
| Content is missing when crawlers render the page | Rendered HTML, JavaScript behavior and crawlable links | Developer |
| Mobile users cannot read or act | Mobile content, layout, performance and form behavior | Design and development |
| Reports stopped matching enquiries or orders | Analytics events, confirmation states and source records | Analytics and operations |
| Traffic is flat but pages are accessible and indexed | Demand, intent, content and authority evidence | SEO and content |
The last row matters. Technical work cannot repair weak demand, an unclear offer or a page that answers the wrong question.
Use six checks in the right order.
Technical SEO becomes easier to reason about when you stop treating it as one giant score.
- Can the server return the important page?
- Can a crawler discover and request it?
- Can the useful content be rendered?
- Can the intended URL be indexed as the canonical version?
- Can a person use the page without avoidable friction?
- Can the change be measured and validated?
Do not jump to experience because a performance tool produced a red number. Do not jump to structured data because a plugin found missing fields. Start where the path first breaks.
1. Can the server return the page?
Google’s technical requirements start with a small eligibility floor: Googlebot must not be blocked, the page must return a successful HTTP response and it must contain indexable content.
Check the exact URLs that matter. A homepage can return normally while service, location, practice-area, product or comparison pages fail.
Look for server errors, timeouts, important URLs returning 404 or soft-404 responses, redirect loops, staging protections left on a live section and firewall rules that block legitimate crawlers.
A successful response makes a page eligible for the next stage. It does not guarantee indexing, ranking or appearance in an AI-generated answer.
2. Can crawlers discover the right URLs?
Search engines often discover pages through links. Google recommends crawlable links with real href destinations in its JavaScript SEO guidance.
Important pages need a path from the site’s navigation, category structure or contextual links. A page that exists only in a database, internal search result or JavaScript click handler may be hard to discover.
A sitemap can help list canonical URLs. It is still a hint. Submitting a sitemap does not force a search engine to index every URL.
Check internal links, redirects, sitemap entries, robots.txt rules and filter or parameter URLs. Remember that robots.txt controls crawling. It is not the same as a page-level noindex instruction.
3. Can crawlers render the useful content?
JavaScript is not automatically an SEO problem. It becomes a problem when important content, links or page states are unavailable to the systems that need them.
Compare what a user sees with the rendered HTML available to a crawler. Check the page title, main heading, service or product information, internal links and content needed to understand the next action.
Server-side rendering or pre-rendering may help when a site depends on client-side JavaScript. That does not mean every JavaScript site needs to be rebuilt.
Google’s mobile-first indexing guidance says the mobile version should carry equivalent primary content, robots directives and structured data. If mobile hides the useful answer or breaks the action, that is both a discovery and conversion problem.
4. Is the intended URL indexed as the canonical page?
A search engine can crawl several versions of similar content and still choose one representative URL.
Google describes canonicalization as clustering duplicate or similar pages and selecting a representative. Redirects, canonical links, sitemap entries and internal links can signal the version you prefer. Google may still select another version.
Check for disagreement between those signals. A product page should not declare one canonical while the sitemap and internal links point elsewhere. A redesigned service page should not compete with an old URL that still returns the same content.
Google must be able to crawl a page to see its robots meta instructions. Blocking a URL in robots.txt while expecting Google to process noindex can create confusion.
5. Can a person use the page?
Technical SEO is not only crawler access. A page can be indexed and still fail the buyer.
Check the experience on the devices customers use. Can someone read the answer, compare the offer, use the navigation and complete the important action? Does the layout move while the visitor is trying to tap? Does a form accept input and return a clear confirmation?
Core Web Vitals measure parts of loading, responsiveness and visual stability. They are useful evidence, not a complete diagnosis of page quality or conversion.
Structured data has a similarly narrow job. It describes visible content in a supported format. It does not make a weak page useful, make a blocked page indexable or guarantee a rich result. Google’s structured-data policies require markup to represent the visible page accurately.
6. Can you measure and validate the change?
Use evidence from the layer you are testing.
- Server response: request the URL and record the status and redirect path.
- Crawl: use Search Console Crawl Stats and, when available, server logs.
- Render: compare source, rendered HTML and a tested browser view.
- Index: use Search Console URL Inspection and canonical reports.
- Experience: test real viewport sizes and review field data where available.
- Commercial action: verify the call, form, appointment, demo or order event against its source record.
Analytics cannot prove that Google crawled a page. A site: search cannot provide a complete index audit. A lab score cannot tell you whether a qualified buyer completed a consultation request.
Decide whether to fix, scope or stop.
| Evidence | Decision |
|---|---|
| No material technical constraint affects an important page | Stop. Work on the next proven constraint. |
| One contained issue affects a small set of pages | Make a targeted fix and validate it. |
| Several connected issues affect a template or section | Scope a focused technical project. |
| A migration, redesign or platform change creates broad risk | Build a test, release and rollback plan before changing production. |
| The pages are accessible and indexed but do not match buyer demand | Move to content, offer, authority or conversion work. |
For large changes, record the important URL set, current response and canonical state, intended change, approval owner, validation method and rollback condition. After release, preserve the before, change, after and rollback trigger. Completing a technical task is not the same as proving the original constraint changed.
The answer changes by business, not by checklist.
| Industry | Pages that may be commercially important | Action to protect |
|---|---|---|
| Home Services | Service and legitimate service-area pages | Qualified calls and booked work |
| Healthcare | Provider, service and location pages | Appropriate appointment requests |
| Legal | Practice-area and attorney pages | Prospective-client enquiries and consultations |
| B2B SaaS | Product, use-case, integration and comparison pages | Demos, trials and qualified pipeline actions |
| eCommerce | Category, product and policy pages | Orders and repeat purchase paths |
Technical eligibility is not the final result. It protects the path that lets the right buyer find, understand and use the page. Healthcare examples need clinical and privacy review. Legal examples need review for the relevant jurisdiction and advertising rules.
Find the first visible break.
If you know a technical problem is limiting organic discovery, review Mindflow’s Organic SEO service and methodology.
Use the Core Web Vitals guide when the suspected problem is page experience, the structured-data decision guide when the problem is markup for a visible page fact, and the planned-pages guide when the problem is unclear page ownership or publishing volume.
If you do not know where the path breaks, contact Mindflow with the affected URL and visible symptom. Mindflow can help identify the first public issue worth checking. That is not a full technical audit, and not every site needs a technical project.
You can also browse the Mindflow Learn hub for related technical questions.
Sources
- Google Search Central: Technical requirements
- Google Search Central: How Search works
- Google Search Central: JavaScript SEO basics
- Google Search Central: Build and submit a sitemap
- Google Search Central: Mobile-first indexing
- Google Search Central: Canonicalization troubleshooting
- Google Search Central: Robots meta tag
- Google Search Central: Core Web Vitals
- Google Search Central: Structured-data policies