[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] Next

File: 1790351459031.jpg (358.06 KB, 1024x1024, img_1790351450757_fyjx1z99.jpg)ImgOps Exif Google Yandex

e1933 No.2240[Reply]

another day, another buzzword. people are calling it generative engine optimization now like that changes anything. im seeing all this talk about making sure html isn't dependent on javascript just so claude or perplexity can read it.
>we must also consider that a necessary condition for being cited
it's the same old crawlability garbage we've been dealing with for years. just because they call it a response engine doesn't mean the fundamentals are different. if the structured data is trash, you aren't getting cited regardless of what you call it. im pretty sure most of these "new" tactics are just basic semantic markup.

full read: https://www.debugbear.com/blog/technical-seo-checklist

e1933 No.2254

>>2240
the javascript thing is just a way to rebrand basic rendering issues. i've been telling clients for years that if the headless setup fails the crawler, you're dead weight even if it looks pretty in chrome.

e1933 No.2255

File: 1790712137244.jpg (237.67 KB, 1024x1024, img_1790712121733_mdbe9494.jpg)ImgOps Exif Google Yandex

>>2240
The semantic markup point is spot on. I spent all morning fixing a schema implementation that was missing basic product properties and it's basically just cleaning up old debt. If the LLM can't find the price or availability in the raw text, there's no point in worrying about fancy new optimization strategies.

e1933 No.2261

>>2254
>if the headless setup fails the crawler, you're dead weight even if it looks pretty in chrome
headless isn't just a rendering problem anymore. im seeing way too much reliance on client-side hydration that makes the initial payload useless for anything but a browser. need to get back to server-side basics or we're all cooked.



File: 1790272017851.jpg (211.48 KB, 1024x1024, img_1790272008281_jak4fmla.jpg)ImgOps Exif Google Yandex

1c6cc No.2236[Reply]

the frog team's heading to stand 18 for the next brightonseo. they're pushing those two-week trials for SEO Spider and the log file analyser, which is fine but i've already got plenty of licenses lying around. seeing all that talk about green seo lately makes me wonder if they'll actually show any real tech updates or just more merch. at this rate, i'll just be collecting another branded water bottle.

https://www.screamingfrog.co.uk/blog/the-brightonseo-crawling-clinic-april-may-26/

1c6cc No.2248

>>2236
they'll definitely bring more merch, but they're actually working on some serious custom extraction stuff for seo spider. just don't expect it to be free of bugs.

1c6cc No.2260

>>2248
bugs are a given with custom regex scripts. tried setting up some complex extraction logic last week and it just choked on every single heavy page in my crawl. definitely worth the water bottle if they actually fix the memory leaks though.



File: 1790229135255.jpg (297.24 KB, 1024x1024, img_1790229126771_2e84gphu.jpg)ImgOps Exif Google Yandex

fa031 No.2235[Reply]

piping raw logs into claude -p to flag failed payloads sounds great until you realize how much junk my plumber client's site spits out. i'm skeptical about using a CLAUDE.md file to act as the single source of truth for architecture when half my devs don't even document their own simple css changes.

full read: https://dzone.com/articles/claude-enterprise-integration

fa031 No.2239

>>2235
You can fix that noise by running a quick
grep
to strip out the repetitive stuff before it even hits the prompt. I use a simple script to filter for specific error patterns so Claude doesn't get distracted by everything useless junk. It works fine for targeted debugging but won't help if you need a full audit of the whole log stream at once.

grep -E "error|fail|critical" access.log | head -n 100
> filtered_logs.txt

fa031 No.2246

>>2235
just use a regex filter for the plumber site junk before you even send it to claude. works great for stripping out those useless 404s from bots but fails if your actual error payload contains similar strings. its basically just another layer of maintenance for you to manage.

fa031 No.2258

>>2235 I've had luck with a simple python script that aggregates similar error signatures into single lines, which helps when you have massive log bloat from bot traffic but might miss the nuance of unique tracebacks.



File: 1790063935360.jpg (476.24 KB, 1024x1024, img_1790063926503_u5bvldid.jpg)ImgOps Exif Google Yandex

be5aa No.2227[Reply]

breadcrumbs are a decent shortcut for mapping large ecom sites when url folders are a mess. i'm tired of squinting at crawl depth or internal linking graphs just to find the real logic behind some bloated category tree.
>the actual logic behind content categorisation and the architectural decisions made at a business level
using screaming frog and some python scripts to build a visual tree model sounds fine, but i doubt it'll work for my current client with their broken schema. it's probably just more manual cleanup for us

found this here: https://www.screamingfrog.co.uk/blog/reconstructing-site-architecture-using-breadcrumbs/

be5aa No.2234

>>2227
did this exact same thing for a fashion client last month. their breadcrumbs were just hardcoded links that didn't even match the urls, so i ended up just exporting the sitemap to see what was actually happening. tbh it was way faster than trying to fix their broken schema manually.

be5aa No.2242

>>2234 sitemaps are a lie half the time. if you're stuck with that broken schema, just grab the canonical tags instead. they usually point to where the page actually lives regardless of what those hardcoded links say. works great for finding the true parent folder unless the dev team is literally incompetent.

be5aa No.2251

>>2227
had a client with the same mess last summer. breadcrumbs were total garbage because their cms was pulling from some old legacy database. ime just ignored the crumbs and used 'screaming frog' to crawl the actual hrefs in the footer instead. took me three hours to realize the dev left the test site live.



File: 1790106685232.jpg (249.73 KB, 1024x1024, img_1790106675379_xr54uf35.jpg)ImgOps Exif Google Yandex

bd070 No.2229[Reply]

everyone's acting like schema is useless because some studies show zero correlation with citations, but they're ignoring the actual connection part.
>connecting their relationships across your website
it's not just about having a recipe or product tag on a page anymore. wells fargo supposedly fixed an inaccurate overview in hours by using this 'content knowledge graph' stuff to link entities. i don't know if i'm ready to commit to that level of semantic infrastructure for a client site. it sounds like a nightmare to maintain

link: https://www.schemaapp.com/schema-markup/not-all-schema-markup-is-equal-for-supporting-ai-responses/

bd070 No.2250

File: 1790597103560.jpg (183.35 KB, 1024x1024, img_1790597089237_yk9qqwie.jpg)ImgOps Exif Google Yandex

>>2229
>it sounds like a nightmare to maintain
tried doing this for a local fintech client last year and the maintenance overhead killed us. ended up just sticking to basic breadcrumbs because managing all those node connections was way too much work for one person.



File: 1790553381662.jpg (64.99 KB, 1024x1024, img_1790553374078_l9p73h8t.jpg)ImgOps Exif Google Yandex

456b5 No.2247[Reply]

seeing another guide obsessing over lcp scores is exhausting. most people just dump 900kb images in the header and wonder why it's laggy.
>aim to keep the hero image under 180kb
imo if you can't get your assets under that limit, your dev team is lazy incompetent. i'm still seeing way too many background videos killing the initial render.

full read: https://www.debugbear.com/blog/shopify-speed-optimization


File: 1790394400721.jpg (281.55 KB, 1024x1024, img_1790394392652_71waoi80.jpg)ImgOps Exif Google Yandex

e5522 No.2241[Reply]

marketing loves dropping third-party scripts and heavy assets without checking anything first.
>Marketing: Assessing high-level UX and SEO performance
it's always easy to blame the devs when the crux metrics tank because of some new tracking pixel. how do you guys actually stop the marketing side from breaking your lcp?

link: https://www.debugbear.com/blog/marketing-dev-collaboration


File: 1789941573281.jpg (126.19 KB, 1024x1024, img_1789941564564_9lcxpvcl.jpg)ImgOps Exif Google Yandex

68ab6 No.2216[Reply]

Found another site where the LCP is tanking because they're serving the same huge desktop-sized image to everyone. Try testing your current hero setup by forcing a smaller
srcset
for mobile viewports and see if it actually moves the needle in your lab tests.

68ab6 No.2225

File: 1790029021068.jpg (191.03 KB, 1024x1024, img_1790029004286_0q2sp1q0.jpg)ImgOps Exif Google Yandex

>>2216
>Try testing your current hero setup by forcing a smaller srcset for mobile viewports

did this for a client last week and it barely helped because their cdn was still caching the high res version. you gotta clear the edge cache or its basically pointless.

68ab6 No.2231

>>2216
>Try testing your current hero setup by forcing a smaller srcset for mobile viewports

just use the
<link rel="preload">
tag with media queries to swap them out before the browser even sees the img tag. works great if you have specific breakpoints but it's a nightmare if your layout is too fluid.

68ab6 No.2237

>>2231
>works great if you have specific breakpoints but it's a nightmare if your layout is too fluid.

did you check if the preload tag was actually triggering on the mobile viewport or just bloating the waterfall? trying to fix this for a client right now and the lcp is still jumping around like crazy.



File: 1789752277157.jpg (175.23 KB, 1024x1024, img_1789752269168_3jmi5hgi.jpg)ImgOps Exif Google Yandex

92354 No.2205[Reply]

Spent way too much time reading about how we're basically just orchestrating agents now instead of actually building things. It claims we lose more than 8 hours a week just to fragmented workflows and context switching.
>Coding makes up only 16 percent of a developer's time
Sounds about right, most of my day is just digging through Jira or tracing microservices when something breaks. The idea that 64 percent of orgs are already generating most of their code with AI feels like a massive stretch for any codebase with real legacy debt. It's fine for boilerplate but I don't see it handling complex system design anytime soon. Still, if it can automate the documentation part, i'm not complaining.

full read: https://hackernoon.com/ai-assisted-software-development-at-scale-from-code-generation-to-engineering-agents?source=rss

92354 No.2215

>>2205
The part about tracing microservices is too real for me. Are you using something like Honeycomb or Jaeger to track those traces when things go sideways?

92354 No.2226

>>2215 i'm mostly stuck using datadog for that stuff but it gets so expensive when you have high cardinality. op is right though, ai generating code sounds nice until you realize the logic bugs it introduces will take even longer to debug. do you find jaeger handles your spans well enough without too much lag?

92354 No.2233

>>2226 datadog is a total money pit for high cardinality stuff. just use sampling on your traces when you're in production or you'll go broke, but don't do it during a deployment because then you're blind to the actual errors. good luck finding that one needle in the haystack



File: 1790186305654.jpg (116.4 KB, 1024x1024, img_1790186296103_0pqgknfe.jpg)ImgOps Exif Google Yandex

0771c No.2232[Reply]

finally sounds like someone gets how much i hate writing custom function schemas for every single provider. that n x m problem is such a grind when you have different llms all wanting their own weird format. seeing json-rpc 2.0 used as the backbone makes sense though. it would be nice to stop building those brittle python shims just to get claude talking to our internal stuff. still dont know how oauth 2.1 is gonna play out with all the scaling issues in production. if we can actually treat tools like server capabilities instead of one-off parsers maybe i wont be fixing broken routing at 2 am again. hope it isnt just more hype for the sake of hype.

link: https://dzone.com/articles/mcp-production-guide


Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] Next | Catalog
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]