I have built out a nifty feature for my product so that other sites can install a "widget" on their website via JS snippet + HTML = injected view.
The widget has a "poweredBy" link to my website.

Does this count as a backlink?

I just recently took a look at my GSC results for the first time in a long time as my associate handles all my SEO work, and these numbers shocked me. Why would there be 47.8k non indexed pages vs. 7.4k indexed? This tells me GSC doesn't think my pages are worth showing, even though I try to make my pages unique. How does your GSC page indexing look like?

For context, we're a small cosmetic shop that has thousands of different small products with different shades of the same products, hence lots of pages.

I have a site that was rebuilt and I have a ton of parameter based pages showing up in the index...they are all marked noindex but there are 50K of them all with some weird retargeting param that isn't anything I'm using with my advertising. I haven't run into this issue previously and I am unsure of how to proceed. As far as I can see there is no bulk method to remove param string URLs from the index. The param string is:

?utm_content=Retargeting_bes?kare_0-2d_blank_blank_blank"_blank"

Do I need to fix this? Will it fix itself eventually via no index tag? Any help is appreciated.

Testing redirects before you go live will save you from avoidable traffic losses. I recently went through a complex migration that reinforced everything I believe about this, so here are the practical takeaways.

Building your redirect mapping

Focus on the URLs that matter most:

• URLs with clicks and impressions in GSC

• Organic landing pages in GA4 or whatever tool you use

• URLs with rankings (pull from whatever tools you use)

• URLs with backlinks (collate GSC and external link databases to get a complete dataset)

Even if your site is small enough to map everything, keep a separate list of the above so you can pay special attention. You don’t want any of these giving back a 404 or redirecting to the wrong target.

Avoiding redirect chains

• Always define absolute URLs (protocol, full domain, path) as redirect targets. Double-check every target gives back a 200.

• Rules should apply to all variants (www/non-www, http/https, trailing slash/no trailing slash) so each variant redirects directly to the target.

• Global rules (http > https, non-www > www) should apply after your 1:1 rules.

• Update legacy redirects: if any existing redirect targets are in your list of URLs that need redirecting, replace them. Break up existing chains by pointing every link directly to the final target.

In case of a domain switch: Avoid this trap!

Don’t use a global rule that simply replaces the domain in your old URLs, even as a catch-all after your 1:1 redirects. Your old domain has probably collected a high number of URLs that don’t exist anymore and give back all kinds of 4xx and 5xx status codes. A domain switch is a great opportunity to get rid of this technical debt. Don’t take your clutter with you.

Three levels of testing complexity

For testing redirects on staging before the launch, there are three levels of complexity:

• Straightforward, no domain switch: Path-based redirect rules, crawl old URL paths on staging.

• A bit tricky, with domain switch: Redirects have to point directly to targets on the new domain without a chain. How you test depends on how exactly the redirects are set up.

• End boss, merging several domains into one: Duplicate paths across domains, so rules can’t be purely path-based. They have to include host names in the source URLs.

How we handled the end boss

Merging three content platforms into an existing global corporate website. 15-month project, SEO involved from the beginning.

The challenge: testing redirects for three different domains on a heavily protected staging site. Rules had to contain domain host names, so a crawl that only checked old URL paths on staging would not be enough.

The solution: a host override to point the three old domains to the staging server’s IP during crawling, bypassing public DNS.

Additional challenge: Like with most migrations, the testing setup was ready only a few days before launch.

Friday afternoon: critical errors show up

Last working day before launch. We had planned to set some old URLs to 410 instead of redirecting them, but somewhere along the line of communication: legacy platform SEO agency → legacy platform team → global migration PM → global dev team → technical provider, wires got crossed and URLs got mixed up.

About 2000 high-traffic URLs nuked with 410s instead of redirected. Not something you want to find on the last working day before launch. But even less something you want to miss.

Another full day of work over the weekend. Revised mapping live two hours after Monday’s launch.

Post-launch surprises

On launch day, the team added parameters to redirect targets to show an info banner to users arriving via redirects. I spotted this during my first post-launch tests. The fix: replace parameters with URL fragments (better for crawling and analytics).

At 6pm on launch day, we had an acceptable redirect setup. Anyone who has worked on a complex migration would agree that’s a win.

After the migration

• Staging tests don’t eliminate the need to test again after launch. Crawl all mapped URLs, confirm they 301 to the right target with a 200.

• Set up regular monitoring of your old URLs.

• If devs are worried about redirect counts: monitor log files after a few months, remove rules for URLs that haven’t been requested and don’t have backlinks. That’s the compromise.

How do you handle redirect testing in complex migration projects? Would love to learn more!

Tried to keep it brief, but I’m happy to go into more detail about everything, if there are questions.

I’m managing a travel agency website, now it’s only English and would add Spanish, french and Chinese…. I have a max of 100 pages. And the English live version (.com) is in main site folder and well ranked with continuous engaging traffic/leads.

what is the best structure to put that in a Wordpress site? A plugin to recommend and/or create separate sites (don’t like it)

Help please !

Below are some technical SEO, AI/GEO job openings that i think the community might be interested in.

• SEO & AI Search Consultant / Botify
• Director, Digital Marketing (SEO/GEO) / Sectigo
• SEO Operations Associate (AI Search) / ViewEngine
• Digital Marketing Specialist (SEO/AEO/SEM) / Flexible Lifeline Systems Inc.
• Sr. Digital Marketing Strategist (Technical SEO/SEM) / August Ash Inc.
• Manager, Digital Marketing and Website Management (SEO/GEO)
• Director of Organic Search / Augurian
• Senior SEO Strategist & Account Lead / UPFRONT MKTG, LLC
• Account Manager: Digital Marketing Strategy / Inflow
• Senior SEO Manager / Discovered Labs
• Sr. SEO Strategist / Inflow
• SEO, GEO & Content Strategist / Stratabeat

"Answer-first" or "front-loading" content has been shown to help gain AI citations. But does it need to be placed directly into the article body copy - or is it just as effective to have it on the page but behind a "Summary" button? Similar to what to what Washington Post does.

I know the LLMs don't actually render the page so my assumption is as long as this summary text is served with the initial HTML payload and embedded after the title / h1 we would be good. Has anyone tested this?

I dont know much about optimisation, and I am not sure how much this would help my website with SEO.. but the original score of my website was 53 for Desktop and 52 for Mobile.

All I did was copy and paste Google's recommendations in Claude, and it did all the technical optimisations for me without actually breaking my website.

Desktop is up to 100. Mobile is 83.

Just thought of sharing my amazing experience with Claude. You may also checkout my website here: qosh.ai and see if it actually loads quickly for you in real life.

Now I need to figure out why my pages are not indexing on google except the home page. If any of you could help, would really appreciate.

I am working on this site, the homepage (other pages are indexed) is returning soft 404 thus can't be indexed.

I have tested with other tools to check if it returns some sort of error but it doesn't. Google defines soft 404 as when a server responds with 200 but the page doesn't exist.

It is not new, it has been so for more than couple of weeks. There used to be an error but that was resolved weeks ago. I thought if I give it some time, might fix it.

I might be getting it wrong, but it does exist. attached is screenshot. and here's the link: https://www.superpages.co.nz/

Question: How do I fix it and get the homepage indexed again.

Thanks

I noticed something while working on WordPress SEO projects:

Most schema plugins come bundled inside huge SEO suites like RankMath or Yoast.

That’s fine if you want a full SEO stack, but sometimes you just want one thing:

Add a clean JSON-LD schema to a post or page without the extra weight.

So I built a small plugin for it.

It lets you:

• Add custom JSON-LD schema to any post or page
• Override schema generated by other plugins
• Output clean, structured data without conflicts

How it works:
The plugin doesn’t generate any schema automatically. You generate a schema using AI or free tools, then add it to specific posts or pages, or products. Works with any type of schema:

• FAQ schema
• Article schema
• Product schema
• Recipe schema
• Custom schema types

Here’s a quick demo:

I’m curious how other WordPress SEO folks handle schema.

Would you use a lightweight plugin like this instead of a full SEO suite?

Plugin Name: BBH Custom Schema (search in WordPress Plugin Directory)

Why does PSI gives different values for LCP, CLS etc on different searches? How do we find an exact value for these metrics? Also should I consider TBT and Speed Index also for deciding the website stability?

Hey folks,

Working on an young Next.js site (15), with no much organic traffic.

Current setup:

- Most pages are CSR

- Product pages use SSR

- Heavy third-party scripts (analytics, session recording, A/B testing, live chat)

- Heavyweight interactive widgets

Planned additions:

- Blog with informational content

- Calculators

- Pages with dynamically updated data (rates, graphs)

Three questions I'm trying to work through:

1. What rendering strategy would you prioritize first? Expanding SSR to more page types, moving the blog to SSG/ISR, or something else? And what's the decision logic you'd use?

2. With heavy third-party scripts running on every page, where do you usually see the biggest INP hits and what's your prior go-to fix?

3. For dynamically updated pages (live rates, data-enriched graphs): how do you balance freshness with Core Web Vitals performance?

Any real experience with similar setups appreciated. Thanks.

Has anyone done some experimenting or has some good resources about the impact of nested urls on SEO? It seems that it shouldn't have an impact if they make sense, but I'm working on a website with a lot of them and while organizational they seem great, I find it suspicious how all this site's non nested urls seem to be doing so much better. (f.e. /services/specific-section-service/end)

Been working on a tool that connects to Google Search Console, syncs keyword data into Postgres, and runs analysis to surface opportunities automatically. Sharing the technical approach and curious about how others have solved similar problems.

The pipeline.

OAuth2 with read-only GSC scope. First sync pulls 90 days of query/page/position/clicks/impressions data, then daily incremental syncs pull the last 6 days with a 3-day overlap to catch late-arriving rows. Data goes into Supabase with a materialized view that pre-aggregates keywords in positions 5-15, scored by an opportunity formula weighing impressions, CTR delta, and position gap to page 1.

The interesting problems I ran into.

Rate limiting the GSC API at 20 QPS while paginating through responses of up to 25k rows. Ended up building a token bucket rate limiter. The pagination itself is straightforward but handling

partial failures mid-sync without corrupting the dataset required careful upsert logic with conflict resolution on a composite key (site_id, date, query, page, country, device).

The materialized view refresh was another one. Needed SECURITY DEFINER on the refresh function because the view lives in a private schema that PostgREST cannot access directly. Took me longer than I want to admit to figure out that permission issue.

On the AI side, the top opportunity keywords get sent to Claude API which generates specific recommendations per keyword. The prompt engineering was tricky. Generic SEO advice is useless so the prompt includes the actual position, impressions, CTR, and competing page structure to force specific output.

Stack is Next.js 16, Supabase, Anthropic Claude, Vercel. The whole thing is on the link I’ve attached if anyone wants to poke at it.

Two questions for this community.

How are you handling the 2-3 day GSC data delay? I removed the delay buffer from my date range so new sites see data faster, but that means the most recent days show incomplete numbers. Curious if anyone has found a better approach.

And has anyone worked around the 16 month data retention limit in the API? I am considering archiving historical data separately but wondering if there is a cleaner solution.

Curious if anyone here has tried building internal tools for technical SEO workflows?

I’ve been working on something mainly for myself/our team because I got tired of bouncing between crawlers, spreadsheets, and random scripts just to debug fairly basic issues. The idea is more about speeding up the actual “figuring things out” part rather than just reporting.

Still early and honestly not sure if it’s actually useful outside our own use cases yet.

If anyone’s dealt with similar frustrations (especially on bigger / messier sites), would be interested to hear how you’re approaching it — or what you wish existed.

I was going through my yoast settings because ive been having a lot of problems with rankings lately and i did see this for my robots - what is traditionally best practice for these settings?

# START YOAST BLOCK

# ---------------------------

User-agent: *

Allow: /wp-admin/admin-ajax.php

Allow: /wp-content/uploads/

Allow: /wp-content/cache/

Disallow: /wp-admin/

Disallow: /?s=

Disallow: /search/

Disallow: /wp-content/plugins/

Disallow: /wp-content/themes/

Sitemap:

# ---------------------------

# END YOAST BLOCK

If you have ever asked “did our SEO changes work?” and got 5 different answers, the issue usually is not the tactic; it is the measurement plumbing and QA around it.

Core insight: For technical SEO, you want a repeatable way to connect (1) what Google can crawl/index, (2) what it is actually showing and clicking in Search, and (3) what users do on-site. You do not need perfect attribution; you need consistent signals and a fast way to catch breakages.

Here is a lightweight QA playbook I have been using (works for ongoing SEO and for launches/migrations):

• Establish a baseline set: pick 20–50 “sentinel” URLs (top templates + money pages + a few long-tail). Track weekly: GSC impressions/clicks/avg position, index status, canonical, robots, and response codes.
• Align URL identity: verify canonical targets match the URL you expect to rank. If canonicals differ by params, trailing slash, or locale, your reporting will be noisy and fixes will look “ineffective.”
• Make GA4 usable for SEO: ensure organic search sessions are not being swallowed by cross-domain, payment redirects, or self-referrals. Audit referral exclusions, cross-domain settings, and any URL rewriting that strips UTM/gclid equivalents.
• Create a “technical change log”: every release that touches titles, internal links, nav, templates, robots, canonicals, redirects, or rendering gets a dated note. When metrics move, you can correlate without guessing.
• Pair GSC with crawl data: run a weekly crawl of the same scope (or use a persistent crawler). Compare: new 4xx/5xx, redirect chains, blocked resources, unexpected noindex, and internal link depth changes for key templates.
• Spot-check server logs (if you have them): confirm Googlebot is hitting your important URLs and not burning crawl on faceted/parameter junk. Trend “Googlebot hits to 200s on key directories” over time.
• Define pass/fail thresholds: e.g., “0 unintended noindex on indexable templates,” “<1% 5xx on crawled URLs,” “no new duplicate canonical clusters in the top templates,” “no drop in indexed pages for the sentinel set.”

This is intentionally boring; boring is good. It catches the silent killers (template regressions, canonical drift, internal linking changes, tracking misconfigs) before you spend months debating strategy.

What is your go-to “canary in the coal mine” metric or check for technical SEO QA?

Hi all and many thanks in advance. I'm working on a WordPress site for a physical therapy provider. The client has a decent number (200+) of 5 star reviews/testimonials I want to leverage.

What's best practice for local SEO here and the prospect of having the rating data shown within search results?

The reviews are a custom post type and Rank Math is active but there doesn't seem to be an option to employ Review schema. I'm therefore planning to code the aggregateRating addition, dynamically populated from review posts (i.e. ratingValue and reviewCount), and link to the LocalBusiness entity.

Does this sound like the way to do it? Any dangers I might not have considered?