Better questions. Clearer decisions.
Technical SEO and migrations: ten implementation questions
Turn indexing, WordPress, performance and migration findings into checks a development team can implement.
Use these answers to prepare a decision, then open the linked detailed guide for implementation. The questions represent common buying situations; they are not a ranked search-demand list or a claim about actual Gavek customer interviews.
What should a technical SEO audit examine, and how do we make sure the findings turn into fixes that our business can actually implement?
Require a reproducible finding, affected URLs or templates, business consequence, proposed change and acceptance check. Separate a confirmed defect from an untested warning and name the developer or content owner needed to resolve it. An actionable audit produces a prioritised delivery backlog, not merely screenshots. Validate a representative fix before applying it across every template.
Important pages are missing from Google even though we have a sitemap. How can an SEO specialist investigate what is happening?
Inspect the exact URL and its intended status before requesting another crawl. Check response code, access restrictions, noindex, canonical choice, available content and internal discovery. A sitemap helps discovery but does not compel indexing. If the page is technically eligible, assess whether it adds distinct useful information. Record what was checked and what remains a hypothesis.
Our WordPress website has an SEO plugin but still performs poorly. What work might we need beyond changing the plugin settings?
A plugin can expose settings, but it cannot establish the accuracy of a service page, fix every template or approve a content strategy. Review indexing settings, navigation, rendered content, performance and forms alongside the plugin configuration. Assign ownership across editor, developer and SEO reviewer, and test important pages after theme, plugin or template changes.
We are redesigning our website. How do we preserve useful search visibility and avoid losing important pages, redirects or tracking?
Inventory important existing URLs and their purpose before building the replacement. Map each changed address to a relevant destination, preserve useful content and links, and test the production redirects. Coordinate indexing controls, measurement and launch ownership. Avoid sending unrelated removed pages to the homepage simply to eliminate errors; each destination should make sense to a returning customer.
Should we move to a new domain or website platform, and what SEO risks should be assessed before committing to the change?
Separate the business reason for a change from assumptions about SEO benefits. Compare keeping the current setup, fixing its constraint and migrating. Record URL changes, content, integrations, tracking, redirects and rollback dependencies. Avoid changing domain, design and content simultaneously when the changes can reasonably be staged. Budget for verification and monitoring rather than treating launch as the end.
Our website is slow on mobile and gets a poor speed score. How do we decide which performance fixes are worth doing first?
Use affected templates, real-user evidence where available and a reproducible mobile journey to prioritise. A slow hero image, blocking script and unstable layout require different fixes. Compare likely user impact with engineering effort and test the actual change. Core Web Vitals are useful diagnostics, but a laboratory score of 100 is neither a complete experience assessment nor a ranking guarantee.
Our website relies on JavaScript, a page builder or an app-like interface. How can we check whether search engines can access the important content and links?
Compare the initial response, rendered page and crawler inspection for an important template. Confirm that meaningful text, navigation and preferred URLs are discoverable, then test failure states and delayed data. A browser screenshot alone cannot prove crawlability. Give the developer an example URL, observed difference and acceptance check so the fix addresses an actual rendering or access problem.
We have broken links, old URLs and redirect chains. Which of these should an SEO company fix first, and how should it prove the fixes work?
Start with links on important customer journeys and destinations that previously held useful content. Repair the source link when possible, and choose a redirect only when a relevant replacement exists. A genuine 404 can be appropriate for permanently removed content. Record the old URL, intended destination and rationale, then verify status, final content and redirect chains.
Do we need structured data on our website, and which kinds are relevant without promising that markup will make us rank first or appear in AI answers?
Choose markup that truthfully describes visible content and an applicable supported type. Compare the information on the page with the structured fields, then validate syntax and eligibility separately. Do not mark fictional reviews or unsupported offers, or assume that an FAQ section makes an agency eligible for FAQ rich results. Correct markup supports interpretation without guaranteeing a particular presentation.
Our development team has little time. Can an SEO specialist work with them to prioritise a few technical changes and verify the work?
Write a ticket with one problem, affected template, reproducible evidence, business priority and a testable acceptance criterion. State dependencies and the rollback approach. Let the developer assess implementation effort and nominate an SEO reviewer for the deployed result. Batch related template changes when practical, but do not label every recommendation urgent or leave the expected behaviour undefined.
Put the decision into a brief
Copy this worksheet into your project notes. Add the evidence URL or document, a named owner and a review date for each applicable row. An empty field identifies work to investigate; it is not permission to invent a claim.
| Ticket field | What to write | Acceptance evidence |
|---|---|---|
| Problem | Exact URL, template and reproducible symptom | The observation can be repeated |
| Expected behaviour | Intended response, content or destination | Actual response matches the requirement |
| Dependencies | Access, reviewer and release constraints | Named owners can complete the change |
| Release and rollback | Representative tests and recovery route | Production verification recorded |
Relevant service and next step
Review the relevant Gavek service scope · Discuss a defined project
Describe the page or business decision, available evidence, internal implementation help and any deadline. Confirm specialist capacity, access, price and approval responsibilities before work starts.
Primary references
- Google: site moves with URL changes
- Google: Core Web Vitals and Search
- Google: asking for a recrawl
- Google: JavaScript SEO basics
- Google: structured data policies
Reviewed 1 November 2026. References support platform-specific principles; the decision frameworks and labelled examples are Gavek editorial guidance. Platform behaviour can change. No guaranteed rankings, citations or commercial outcomes.
Your next move starts here
Make search a more useful part of your growth.
Start with your website. Leave with a clearer picture of what to improve, what to measure and where to focus next.