Published by SEO Company Philippines · Page updated
Questions about our services or a result shown here? Contact our team. Client results retain their original reporting periods.
Technical SEO
Important pages are not indexed. A release has cost you traffic. Your developers have an audit full of warnings but no clear starting point. We investigate the cause, prioritise the affected pages and help you check that the fixes work.
Managed support starts at US$3,000/month; focused projects are scoped separately. Compare pricing and what is included.
A warning from a crawler is a starting point, not a diagnosis. We compare crawl findings with rendered pages, Search Console and the way your website is built. The handoff identifies the affected template, a reproducible example, the recommended change and how to test it. Development outside the agreed scope is estimated separately.
Google states that requesting a recrawl does not guarantee indexing. That is why we investigate the affected pages before resubmitting them, and check indexing separately from whether the technical change was deployed.
The intended page loads successfully, yet Search Console reports a different canonical.
| Step | What your team should expect |
|---|---|
| Investigate | Inspect the declared and selected canonicals, response codes, internal links, sitemap entry and differences between the two pages. |
| Decide | Resolve conflicting signals if both URLs serve the same purpose. If the pages serve different needs, clarify their distinct content and navigation instead of blindly changing canonical tags. |
| Check | The chosen destination returns the intended response, has consistent links and canonical signals, and is inspected again after recrawling. Index selection remains Google’s decision. |
| Avoid | Do not migrate to a new slug solely because a page is not indexed. That may move the same unresolved problem. |
You have a specific search problem and need a diagnosis that your developers can use.
Important pages are excluded from search.
Traffic changed after a release or migration.
Crawlers report thousands of issues with no clear business priority.
We check the affected URLs against robots rules, indexing directives, canonicals, rendered content and internal links. Search Console helps distinguish a discovery problem from a page Google has crawled but not selected. A new URL alone is not a reliable fix.
A problem with filters, pagination or JavaScript can affect many pages. We identify the shared cause and provide representative URLs, reproduction steps and acceptance checks. That gives your developers a change they can test without guessing what the audit meant.
For a migration, the scope can include a URL inventory, redirect mapping, internal-link updates and pre-launch checks. We distinguish what must be ready before launch from what can follow. Redirects should lead to a relevant replacement, not send every old page to the homepage.
A ticket marked done is not the final check. We review the published response, rendered content and affected links. Indexing and search performance can take longer to change; the report separates a verified technical fix from a ranking outcome.
The exact audit depends on the platform and the failure being investigated. We work from affected templates and search evidence rather than running the same checklist against every website.
Robots rules, sitemaps, navigation, pagination, faceted URLs, parameters, orphan pages, redirect chains, and server responses are checked together. The objective is to show search engines the useful inventory without spending crawl activity on endless low-value combinations.
We compare source HTML, rendered output, canonical declarations, duplicate clusters, JavaScript dependencies, and Search Console evidence. This distinguishes a crawling problem from a rendering, quality, canonicalization, or indexing decision.
Titles, headings, internal links, schema, media, language signals, and index controls are reviewed at template level. One template correction can be more valuable than editing hundreds of individual URLs.
Core Web Vitals, resource loading, mobile behaviour, redirects, staging controls, analytics continuity, and rollback plans are assessed when speed or a platform move creates search risk.
A useful technical review connects the affected template, search evidence, business risk, recommended behaviour, owner, and live-site test. It does not leave the team with a severity label and no path to implementation.
We reproduce the issue across the templates it affects and record the response code, source HTML, rendered output, canonical, index directive, internal path, and Search Console evidence that matter. A sampled product problem is labelled as a template hypothesis until the wider pattern is checked.
For example, a filtered collection may be linked throughout the store, canonicalized to a parent, included in a sitemap, and still return unique products. The recommendation has to resolve those conflicting signals rather than telling a developer to ‘fix canonicals’.
The SEO requirement describes the outcome: which version should be indexable, discoverable, canonical, internally linked, and present in the sitemap. Engineering can then choose the safest platform-specific implementation with those checks for completed work intact.
When several options exist, we document the trade-off. A server-side redirect, template rule, navigation change, or rendering change can solve different parts of the same symptom. The final ticket names the dependency and the person who can approve it.
Staging is checked for the rendered fix, regressions, and representative templates. The live site still needs its own checks because robots rules, CDN behaviour, environment settings, analytics, internal links, and live data may differ.
The release check records what shipped, when, which URLs were tested, and which metrics should move if the diagnosis was correct. That becomes the baseline for Search Console and crawl monitoring.
One problem affecting a high-value category template can matter more than hundreds of low-value warnings. We combine page importance, query demand, current visibility, template reach, implementation effort, and risk when setting priority.
The technical roadmap also shows what should wait. Fixing every crawl-tool warning at once hides the constraints that are actually preventing useful pages from being discovered or understood.
Affected examples, expected behaviour and a way to test the proposed fix.
Issues grouped by the pages and customer journeys they affect, not by tool severity alone.
A record of what was verified on the live site and what still needs attention.
Review the affected pages and when the change began.
Discuss the recommendation with the people responsible for the platform.
Check the response and content, then monitor the relevant indexing and search reports.
The work covered a Medium-to-owned-domain migration and technical SEO across Thailand, Japan, Taiwan, and Hong Kong.
Source and context: Goodnotes: client feedback on the migration.
Ahrefs AI-search visibility, September 2026. This snapshot is separate from the results described in the case study.Publication migration and multi-market technical SEO
Architecture, content and commercial measurement.
Programmatic templates, internal links, and indexation
First-party Google Search Console comparison. The screenshot preserves the original selected periods and values.Search-first data platform and crawl controls
We agree the reporting with your team and distinguish completed work from business results. Missing data and other changes affecting performance stay visible.
Direct answers to the questions teams ask before deciding whether this work fits.
We can implement changes where the agreed scope and access allow it. Where your engineering team owns the code, we provide specific tickets and review the release. The proposal distinguishes diagnosis, implementation and verification rather than assuming they are all included.
The scope depends on the site, but normally covers crawling, indexation, rendering, architecture, canonicals, duplication, sitemaps, structured data, performance, internal links, and migration risk.
A fix can be validated immediately, but search impact depends on recrawling, the size of the affected area, site authority, and the original constraint. We set an expected observation window for each change.
No. We can find and fix technical barriers, but search engines also assess the page and may not index it. We explain whether the available information points to access, duplication, content usefulness or another issue.
Tell us about your website, customers and the problem you want to solve. We will discuss fit, responsibilities and a realistic scope before you commit.
Book a meeting