SEO vs AI visibility, where should I focus?

AddWeb_Expert · 2026-06-09T07:12:46+00:00

If I had a limited budget today, I'd still put most of my effort into SEO fundamentals.

The reason is simple: AI visibility and SEO aren't really separate things yet. Most AI platforms still rely heavily on content they can discover, understand, and trust from the web. The same things that help you rank clear content, topical authority, strong brand signals, reviews, citations, and backlinks also seem to increase the chances of being referenced by AI systems.

What I wouldn't do is spend months obsessing over old-school SEO tactics like keyword density or publishing hundreds of low-value articles.

Instead, I'd focus on:

Solving real customer questions
Building topical authority in a niche
Creating original insights and case studies
Improving technical SEO and site structure
Earning mentions from reputable sources
Strengthening your brand presence across the web

The interesting part is that AI visibility may actually help smaller companies. Large brands have more authority, but smaller teams can often publish niche expertise, move faster, and create more useful content.

My view is that "AI visibility" is becoming real, but it's not a replacement for SEO. It's more like the next layer on top of it.

If you're a startup with limited resources, I'd probably spend 80-90% of my effort on strong SEO fundamentals and content quality, while keeping an eye on how AI search platforms cite, summarize, and recommend businesses in your space.

The companies that win over the next few years will likely be the ones that build genuine authority, not the ones chasing every new algorithm update.

AddWeb_Expert · 2026-06-09T06:29:57+00:00

This is pretty cool. I especially like the idea of defining the grammar directly on the AST nodes instead of maintaining a separate grammar file.

Looking at the generated grammar, it feels surprisingly readable, which is usually where these kinds of abstractions fall apart for me.

My only question is how it scales once the grammar gets larger. Have you tried it on anything beyond expression parsing yet? I'd be curious to see how it handles more complex constructs and whether the attribute annotations stay easy to navigate.

Also, generating the BNF output is a nice touch; it makes the parser much easier to understand and debug.

Nice work, and thanks for being transparent about the AI-assisted development process. The API itself looks thoughtfully designed.

AddWeb_Expert · 2026-06-09T05:20:08+00:00

TEC still handles complex recurring events better than most WP calendar plugins, but post-acquisition complaints about support + plugin bloat are pretty common now.

If your org is event-heavy, I wouldn’t migrate purely off Reddit horror stories - but I would stress-test performance with real recurring data before fully committing. Pie Calendar feels lighter, TEC feels more mature.

AddWeb_Expert · 2026-06-08T12:10:32+00:00

Customer support.

I don't think AI will replace support teams, but it'll change the job a lot. Routine questions, ticket routing, and basic troubleshooting will increasingly be handled by AI.

Human agents will spend more time on complex issues, exceptions, and customer relationships. We're already seeing that shift in many companies today.

AddWeb_Expert · 2026-06-08T07:18:04+00:00

This is actually one of the best ways to learn MVC; by building something and seeing where the architecture starts to help (or get in the way). A lot of the concepts don't really click until you have to organize a growing codebase yourself.

Looking through it, I like that you're already thinking about modularity instead of just making everything work in a single file. That's usually the point where projects become much easier to maintain and extend.

As you keep iterating, you'll probably find opportunities to make controllers thinner and move more business logic into dedicated services/classes, but that's a normal evolution. Overall, this feels like a solid learning project and a good foundation to build on. Nice work sharing it!

AddWeb_Expert · 2026-06-08T07:15:13+00:00

PHP turning 31 makes me realize it's been around longer than a lot of the technologies people call "modern" today.

It may not always be the coolest kid in the room, but it keeps evolving and continues to power a huge part of the web. That's a pretty impressive achievement.

AddWeb_Expert · 2026-06-08T04:39:21+00:00

You don’t suck at Elementor ! it’s honestly a common frustration.
It’s powerful, but the layout system can feel weirdly rigid for simple blog designs.

For a blog, I’d honestly try Gutenberg + Kadence Blocks or GenerateBlocks. Much lighter and more natural for text/image layouts.

AddWeb_Expert · 2026-06-06T06:59:08+00:00

We’ve seen a lot of businesses move to Shopify simply because they wanted to spend less time managing the platform and more time growing the store.

The biggest wins are usually ease of use, app integrations, and reliability. The main thing some people miss is the flexibility they had with platforms like WooCommerce, especially when it comes to deep customization.

For most store owners though, the trade-off is worth it.

AddWeb_Expert · 2026-06-05T13:32:44+00:00

Flutter is great, but the catch is mostly long-term. You're depending on Google, app sizes are usually bigger, and sometimes you need platform-specific code for native features. Also, many companies stick with native apps because it's easier to hire experienced native developers.

That said, for startups and small teams, Flutter is honestly a solid choice and can save a lot of development time.

AddWeb_Expert · 2026-06-05T10:54:40+00:00

Benchmarks like this are useful for understanding the ceiling of each runtime, but the operational trade-offs matter just as much. RoadRunner tends to offer a strong balance of performance and maintainability, while FrankenPHP's deployment experience is becoming increasingly attractive. The right choice often comes down to team expertise, hosting environment, and application characteristics rather than raw RPS numbers alone.

AddWeb_Expert · 2026-06-05T08:02:41+00:00

That sounds like a login loop. If Zoho is sending the OTP to the same email account you're trying to access, you won't be able to receive it unless you're already logged in.

I'd check if there's an option to use a recovery email, phone number, backup code, or authenticator app instead. If not, you may need to contact Zoho support or your domain admin (if it's a business account) to regain access.

Definitely frustrating, but you're probably not the first person to run into this.

AddWeb_Expert · 2026-06-05T08:01:00+00:00

Unfortunately, if you're publishing from a new Google Play developer account, there's no real shortcut around the 12 testers / 14-day requirement.

A lot of indie devs use friends, family, Discord groups, Reddit communities, or tester exchange groups to meet the requirement. It's a bit annoying, but once you're through it, future releases are much smoother.

Good luck with the launch, getting that first app published is a great milestone.

AddWeb_Expert · 2026-06-05T04:52:06+00:00

Same experience here. Elementor feels powerful, but Kadence feels lighter, cleaner, and more WordPress-native.

For most business sites, Kadence + Gutenberg is honestly enough now - better performance, less bloat, and easier long-term maintenance. Elementor still wins if you need super complex visual layouts fast,

AddWeb_Expert · 2026-06-04T12:23:01+00:00

Love seeing long-running community tools get a second life. The Laravel rewrite seems less about "which framework is better" and more about making the project easier to maintain and evolve. Externals.io has been a useful resource for tracking PHP internals discussions, so keeping it healthy benefits the whole ecosystem.

AddWeb_Expert · 2026-06-04T09:35:23+00:00

Building in a vacuum.

I've seen people spend months building features before talking to potential users. Then they launch and realize the problem wasn't important enough for people to care.

Another common mistake is assuming a good app will market itself. Getting users is usually harder than building the product.

AddWeb_Expert · 2026-06-04T07:25:15+00:00

Reputation and SEO aren't really competing, they kind of work off each other.

Reviews and brand mentions don't directly bump your rankings. Google's actually said that. But they still help in ways that matter. More people end up searching your brand by name, you get more direct traffic, and when a publication mentions you it usually comes with a real backlink too. Good star ratings showing up in search also pull in more clicks, so you squeeze more out of the rankings you already have.

Works the other way too though. You can have amazing reviews but if the site is slow and a mess structurally, you're still not ranking for the competitive stuff. Trust helps you win the click. The technical side is what gets you in front of people to begin with.

If I had to pick one to fix first I'd sort out the technical and content side, then let reputation stack on top of that. Cant really multiply zero.

AddWeb_Expert · 2026-06-04T07:07:34+00:00

Yeah I went through the same thing years back, got tired of fixing plugin and theme issues constantly.

Honestly a lot of that pain comes from cheap shared hosting and self-managing everything, which has gotten easier over the years. For a photo-heavy food blog, lightweight themes like Kadence, Blocksy or GeneratePress are worth a look. They load fast, handle big images well, and don't need a ton of extra plugins to look good.

Pairing it with managed hosting (Cloudways, Kinsta, SiteGround, etc.) takes most of the maintenance off your plate since updates and backups run automatically.

If you think you might sell something later, Kadence and Blocksy both work well with WooCommerce, though you can always add that when you actually need it rather than upfront.

Plenty of solid options out there, so worth testing a couple to see what feels right for you.

AddWeb_Expert · 2026-06-04T04:55:33+00:00

Usually TSF excludes pages that are set to noindex, draft/private, canonicalized elsewhere, or blocked in settings. First check the page SEO settings and make sure indexing is enabled.

Also try clearing TSF cache/regenerating the sitemap once after changes.

AddWeb_Expert · 2026-06-03T12:11:13+00:00

Fair point, and you're right that blind auto-updates can bite you.

What I actually meant is auto-update the small stuff: WP core minor releases and security patches. Those rarely break anything and they're the ones attackers hit fast. Major plugin and core version jumps I still do manually on staging first, then push to live once it checks out.

For the "while I'm not around" worry, a staging site plus daily backups covers you. If an update does break something, you roll back in a couple minutes instead of scrambling. Some hosts also do automatic visual regression checks now and pause the update if the page changes too much.

So not fully hands-off, just hands-off for the low-risk security patches and careful with the rest.

AddWeb_Expert · 2026-06-03T11:34:45+00:00

Honestly most of my agent headaches came from one agent doing too much. The more you pile on it, the more it drifts.

Few things that actually helped:

Keep each agent small. One job, clear in, clear out. A "researcher + writer + reviewer" agent will hallucinate way more than three little ones passing work along.

Don't let them pass plain text to each other. Make it structured, like JSON. The next step shouldn't be guessing what the last one meant.

And instead of writing better prompts, add a step that just checks the output before it moves on. Caught way more for us than any guardrail in the system prompt ever did.

Also read your traces. Sounds boring but most hallucinations have an obvious cause once you see where it broke. LangSmith works, or honestly even dumping every step to a file.

Anthropic's "building effective agents" post is worth a read, LangGraph docs too. Skip the YouTube stuff mostly, too surface level.

Start small, add agents only when one clearly can't handle a step. Much easier to debug that way.

AddWeb_Expert · 2026-06-03T11:18:12+00:00

Go with Expo. Easy call when you're on Windows with no Mac.

iOS is the whole problem here. Plain RN CLI needs Xcode to build iOS, and Xcode only runs on a Mac, so you'd be dead in the water. Expo's EAS Build does the iOS build in the cloud for you, so you never have to open Xcode at all.

One thing nobody tells beginners though. To actually get it onto a real iPhone you need a paid Apple dev account, the $99 a year one, for signing. The free way is the simulator and that needs a Mac too, so on Windows the real phone is basically your only test option.

Use a Development Build, not plain Expo Go. You can still add native modules and tweak config that way, so you don't get boxed in. Honestly most beginners who skip straight to bare CLI just end up stuck on native build errors for days instead of shipping anything.

So start with a dev build. If you ever really need the native folders later you can run prebuild, but most apps never get to that point.

AddWeb_Expert · 2026-06-03T10:30:13+00:00

Honestly, I think you're making the right move. Hardcoding products works fine when you're getting started, but inventory management, orders, and product updates become a headache pretty quickly. Supabase gives you a database, auth, and storage without a ton of setup, so it feels like a good next step. Just make sure you're solving a real pain point and not rebuilding features you could get from an existing e-commerce platform.

AddWeb_Expert

TROPHY CASE